From pce-bounces@lists.ietf.org Thu Jun 01 15:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsQ6-0005oz-2N; Thu, 01 Jun 2006 15:01:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsQ3-0005ot-VH for pce@ietf.org; Thu, 01 Jun 2006 15:01:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsQ2-0005H6-Mh for pce@ietf.org; Thu, 01 Jun 2006 15:01:19 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2006 12:01:17 -0700 X-IronPort-AV: i="4.05,199,1146466800"; d="scan'208"; a="287175602:sNHT1507471960" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k51J1Huo029231 for ; Thu, 1 Jun 2006 12:01:17 -0700 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 k51J1Gku017735 for ; Thu, 1 Jun 2006 15:01:17 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 15:01:16 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 1 Jun 2006 15:01:16 -0400 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Thu, 1 Jun 2006 15:01:14 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 01 Jun 2006 19:01:16.0404 (UTC) FILETIME=[C2678B40:01C685AD] DKIM-Signature: a=rsa-sha1; q=dns; l=123; t=1149188477; x=1150052477; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Agenda=20for=20IETF-66=20WG=20meeting; X=v=3Dcisco.com=3B=20h=3DNAIQviOUZw4SkbpLvJ4vOIOLwlk=3D; b=KlB9Ql6TSk1fnV+u1aTiPkhcOIitDZ4jmJ2GizceWDXHfL6TSF/DJuX5l6qDnWWH1yIjYGyk oR3jms82mUqpYBiMxQ6U0xc+ipo4q6C9Ezsr2nNELcFPhi8vZth3s0Lm; Authentication-Results: sj-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] Agenda for IETF-66 WG meeting 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, If you'd like to have a slot for the coming PCE WG meeting, thanks to let us know. Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jun 02 08:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Wh-0005p5-AN; Fri, 02 Jun 2006 08:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Wf-0005ou-Rm for pce@ietf.org; Fri, 02 Jun 2006 08:13:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8We-00057a-7q for pce@ietf.org; Fri, 02 Jun 2006 08:13:13 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2006 05:13:12 -0700 X-IronPort-AV: i="4.05,203,1146466800"; d="scan'208,217"; a="1817979717:sNHT52667584" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k52CD9cm004241 for ; Fri, 2 Jun 2006 05:13:09 -0700 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 k52CD9ku017418 for ; Fri, 2 Jun 2006 08:13:09 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 08:13:09 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 2 Jun 2006 08:13:08 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: pce@ietf.org Message-Id: <2CD884CE-1C3C-4EC1-8546-3D1AFBC9D074@cisco.com> References: From: JP Vasseur Date: Fri, 2 Jun 2006 08:13:06 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 02 Jun 2006 12:13:08.0438 (UTC) FILETIME=[E8DA3760:01C6863D] DKIM-Signature: a=rsa-sha1; q=dns; l=11073; t=1149250390; x=1150114390; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Fwd=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for=20the=2066t h=20IETF=20Meeting=20in=20Montreal,=20Quebec,=20Canada=20; X=v=3Dcisco.com=3B=20h=3DvxLsbpyv1KiqSdjFD71+ftKR+wQ=3D; b=eYrQsg0J+UYNtHRVo/gJPPf60/OG5LDMXrC0b3dPPXl8XRzZi5YomRN4CcTtKgQzoCs5SRWd nYgUbW2xQS74eycFx83rhSooHFYnVkdNeftW6YHvjnl8OSNtLq2gaB88; Authentication-Results: sj-dkim-4.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 31 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.7 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0857160384==" Errors-To: pce-bounces@lists.ietf.org --===============0857160384== Content-Type: multipart/alternative; boundary=Apple-Mail-168--855505407 --Apple-Mail-168--855505407 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed as a reminder ... Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: June 2, 2006 12:00:01 AM EDT > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF > Meeting in Montreal, Quebec, Canada > > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 66th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-168--855505407 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 as a reminder = ...

Begin forwarded message:

Date: June 2, 2006 12:00:01 AM = EDT
To: ietf-announce@ietf.org
Subject: Internet-Drafts Submission Cutoff = Dates for the 66th IETF Meeting in Montreal, Quebec, Canada=A0


There are two = (2) Internet-Draft cutoff dates for the 66th=A0
IETF = Meeting in Montreal, Quebec, Canada:

June 19th: Cutoff Date for = Initial (i.e., version -00)=A0
=A0

All initial = Internet-Drafts (version -00) must be submitted by Monday,=A0
June = 19th at 9:00 AM ET. As always, all initial submissions with a=A0
filename = beginning with "draft-ietf" must be approved by the=A0
=A0 The=A0
=A0
June 12th at 9:00 AM ET.

June = 26th: Cutoff Date for Revised (i.e., version -01 and higher)=A0
=A0

All revised = Internet-Drafts (version -01 and higher) must be submitted=A0
by = Monday, June 26th at 9:00 AM ET.

Initial and revised = Internet-Drafts received after their respective=A0
cutoff = dates will not be made available in the Internet-Drafts=A0
=A0
AM ET, when Internet-Draft posting resumes.=A0 Please do not wait until=A0
the last = minute to submit.

Thank you for your understanding and cooperation. If = you have any=A0
questions or concerns, then please send a message = to=A0
internet-drafts@ietf.org.

The IETF = Secretariat

FYI: The Internet-Draft cutoff dates as well as = other significant dates
for the 66th = IETF Meeting can be found at http://www.ietf= .org/meetings/cutoff_dates_66.html.

IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

= --Apple-Mail-168--855505407-- --===============0857160384== 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 --===============0857160384==-- From pce-bounces@lists.ietf.org Sat Jun 03 07:21:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmUBz-0003a7-7K; Sat, 03 Jun 2006 07:21:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmUBy-0003a2-GT for pce@ietf.org; Sat, 03 Jun 2006 07:21:18 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmUBx-0005Ab-3r for pce@ietf.org; Sat, 03 Jun 2006 07:21:18 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Jun 2006 13:21:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 3 Jun 2006 13:21:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-pce-discovery-reqs-04 Thread-Index: AcaGXiSIxyntg/oAS267Yxvrq9y3LAAobEDg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 03 Jun 2006 11:21:14.0851 (UTC) FILETIME=[D36C4B30:01C686FF] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Subject: [Pce] IESG comments on draft-ietf-pce-discovery-reqs-04 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="===============0465526086==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0465526086== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C686FF.D377FA39" This is a multi-part message in MIME format. ------_=_NextPart_001_01C686FF.D377FA39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Hi all, >=20 > During the IESG review of the PCE discovery Requirements draft, > we received a set of comments, which can be found at=20 > = https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTa > g=3D13336&rfc_flag=3D0 >=20 > We are currently working together with the WG chairs to address these > comments. > In particular we have significantly detailed the manageability > section, we added > requirements on the configuration of PCE Discovery parameters, on the > PCE > Discovery MIB modules and on the control of protocol operations. >=20 > We will submit a new revision soon. >=20 > Best Regards, >=20 > JL et al.=20 > =20 ------_=_NextPart_001_01C686FF.D377FA39 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IESG comments on draft-ietf-pce-discovery-reqs-04

    Hi all,

    During the IESG review of the PCE = discovery Requirements draft,
    we received a set of comments, which can = be found at
    https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id= &dTag=3D13336&rfc_flag=3D0

    We are currently working together with the = WG chairs to address these comments.
    In particular we have significantly = detailed the manageability section, we added
    requirements on the = configuration of PCE Discovery parameters, on the PCE
    Discovery MIB = modules and on the control of protocol operations.

    We will submit a new = revision soon.

    Best = Regards,

    JL et al.
     

------_=_NextPart_001_01C686FF.D377FA39-- --===============0465526086== 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 --===============0465526086==-- From pce-bounces@lists.ietf.org Sat Jun 03 08:03:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmUqp-0003Tw-GN; Sat, 03 Jun 2006 08:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmC7h-00043I-EX for pce@ietf.org; Fri, 02 Jun 2006 12:03:41 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmC7g-0005dt-1m for pce@ietf.org; Fri, 02 Jun 2006 12:03:41 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 18:03:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Jun 2006 18:03:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG comments on draft-ietf-pce-discovery-reqs-04 Thread-Index: AcaGXiSIxyntg/oAS267Yxvrq9y3LA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 02 Jun 2006 16:03:38.0053 (UTC) FILETIME=[1BF1FF50:01C6865E] X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Sat, 03 Jun 2006 08:03:30 -0400 Cc: Subject: [Pce] IESG comments on draft-ietf-pce-discovery-reqs-04 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="===============1470006206==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1470006206== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6865E.1BC95925" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6865E.1BC95925 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, During the IESG review of the PCE discovery Requirements draft, we received a set of comments, which can be found at=20 https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 13336&rfc_flag=3D0 We are currently working together with the WG chairs to address these comments. In particular we have significantly detailed the manageability section, we added requirements on the configuration of PCE Discovery parameters, on the PCE Discovery MIB modules and on the control of protocol operations. We will submit a new revision soon. Best Regards, JL et al.=20 =20 ------_=_NextPart_001_01C6865E.1BC95925 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IESG comments on draft-ietf-pce-discovery-reqs-04

Hi all,

During the IESG review of the PCE = discovery Requirements draft,
we received a set of comments, which can = be found at
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id= &dTag=3D13336&rfc_flag=3D0

We are currently working together with the = WG chairs to address these comments.
In particular we have significantly = detailed the manageability section, we added
requirements on the = configuration of PCE Discovery parameters, on the PCE
Discovery MIB = modules and on the control of protocol operations.

We will submit a new = revision soon.

Best = Regards,

JL et al.
 

------_=_NextPart_001_01C6865E.1BC95925-- --===============1470006206== 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 --===============1470006206==-- From pce-bounces@lists.ietf.org Sat Jun 03 08:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmV29-0000Zp-Mt; Sat, 03 Jun 2006 08:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmV27-0000Sf-Ql for pce@ietf.org; Sat, 03 Jun 2006 08:15:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmV25-00021L-Co for pce@ietf.org; Sat, 03 Jun 2006 08:15:11 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Jun 2006 05:15:09 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k53CF8U9031939; Sat, 3 Jun 2006 05:15:08 -0700 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 k53CF8ku000267; Sat, 3 Jun 2006 08:15:08 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 08:15:07 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 3 Jun 2006 08:15:07 -0400 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Message-Id: <8E7DF6B3-36C9-442E-B9D9-CD9C03BAF6CB@cisco.com> From: JP Vasseur Subject: Re: [Pce] IESG comments on draft-ietf-pce-discovery-reqs-04 Date: Sat, 3 Jun 2006 08:15:04 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN , pce@ietf.org X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 03 Jun 2006 12:15:07.0173 (UTC) FILETIME=[5A097D50:01C68707] DKIM-Signature: a=rsa-sha1; q=dns; l=4085; t=1149336908; x=1150200908; c=relaxed/simple; s=sjdkim3001; 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]=20IESG=20comments=20on=20draft-ietf-pce-discovery-reqs-04; X=v=3Dcisco.com=3B=20h=3DEyJMD59LRkk8T2TeYjg/NLhBqqA=3D; b=WHRao1DKzhu4Mkss+KRV3yP6LqVjdxIxpbRM+hm3EQdcxHlXu67ysRH5iHhjyt8dvUKbWLMb 4nj2XrNq2pQ5T6YvNRozV1SuEAl3nYU+0vkgSNyL3MP+xYLKPeYq80wi; Authentication-Results: sj-dkim-3.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 31 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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="===============0046229723==" Errors-To: pce-bounces@lists.ietf.org --===============0046229723== Content-Type: multipart/alternative; boundary=Apple-Mail-181--768987426 --Apple-Mail-181--768987426 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Considering the amount of change on the manageability section, we'll issue a short incremental WG LC on the new revision. Thanks. JP. On Jun 2, 2006, at 12:03 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi all, > > During the IESG review of the PCE discovery Requirements draft, > we received a set of comments, which can be found at > https://datatracker.ietf.org/public/pidtracker.cgi? > command=view_id&dTag=13336&rfc_flag=0 > > We are currently working together with the WG chairs to address > these comments. > In particular we have significantly detailed the manageability > section, we added > requirements on the configuration of PCE Discovery parameters, on > the PCE > Discovery MIB modules and on the control of protocol operations. > > We will submit a new revision soon. > > Best Regards, > > JL et al. > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-181--768987426 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear WG,

Considering the amount of = change on the manageability section, we'll issue a short incremental WG = LC on the new revision.

Thanks.

JP.

On Jun 2, 2006, at = 12:03 PM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

Hi all,

During the IESG review of the PCE discovery Requirements = draft,
we received a set of = comments, which can be found at
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&= amp;dTag=3D13336&rfc_flag=3D0

We are currently working together with the WG = chairs to address these comments.
In particular we have significantly detailed the manageability = section, we added
requirements on = the configuration of PCE Discovery parameters, = on the PCE
Discovery MIB modules and on = the control of protocol operations.

We will submit a new revision = soon.

Best Regards,

JL et al.
=A0

Pce mailing list
=

= --Apple-Mail-181--768987426-- --===============0046229723== 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 --===============0046229723==-- From pce-bounces@lists.ietf.org Mon Jun 05 12:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHls-0002DP-Jf; Mon, 05 Jun 2006 12:17:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnHlr-0002DI-9Y for pce@ietf.org; Mon, 05 Jun 2006 12:17:39 -0400 Received: from pro.abac.com ([66.226.64.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnHlp-00007Z-T8 for pce@ietf.org; Mon, 05 Jun 2006 12:17:39 -0400 Received: from [192.168.0.100] (c-67-188-134-148.hsd1.ca.comcast.net [67.188.134.148]) (authenticated bits=0) by pro.abac.com (8.13.6/8.13.6) with ESMTP id k55GHN6F017389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jun 2006 09:17:34 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <44845914.3090207@grotto-networking.com> Date: Mon, 05 Jun 2006 09:17:24 -0700 From: Greg Bernstein User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ccamp@ops.ietf.org, pce@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Pce] Virtual Network Topology (VNT) changes and IP layer routing loops 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 folks, in drafts draft-ietf-ccamp-gmpls-mln-reqs-00.txt and draft-ietf-pce-inter-layer-frwk-00.txt the concepts of multi-layer and multi-region networking are defined and discussed. An important case is when the IP layer rests directly upon a "virtual network topology" layer that we will desire to change via GMPLS signaling. Changes to the IP layer VNT can produce "transient IP layer routing loops" also known as "micro loops" which can last 100's of mili seconds or more. Hence any time we change a connection between IP layer routers via GMPLS we can cause significant outages compared to the recovery times that we set out to achieve with GMPLS fast reroute and other mechanisms such as SDH APS (rings and linear). At the Routing working group, Alex's draft draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis and a method to reduce the impact (duration too) of the transient loops. More recently the drafts: (1) draft-bryant-shand-lf-applicability-01.txt (2) draft-bryant-shand-lf-conv-frmwk-02.txt (3) draft-francois-ordered-fib-01.txt Address this problem more generally including in (3) a method that guarantee loop free convergence. The problem is that these have generated very little interest at the RTG WG and may not move forward. This area is not within PCE or CCAMPs charter but can have an impact on the adoption of GMPLS in multi-layer/region networking. If you're interested please take a look and comment to the RTG WG. Note I wasn't involved with writing these, but came across them when considering the effects of GMPLS changes on the IP layer VNT. Thanks Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 05 14:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJyc-0000P7-LZ; Mon, 05 Jun 2006 14:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJyc-0000P2-6K for pce@ietf.org; Mon, 05 Jun 2006 14:38:58 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnJya-0007KU-Sd for pce@ietf.org; Mon, 05 Jun 2006 14:38:58 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k55Icmh25468; Mon, 5 Jun 2006 14:38:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops Date: Mon, 5 Jun 2006 14:38:34 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com> In-Reply-To: <44845914.3090207@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops Thread-Index: AcaIu5iEb+JIM5PjSJeSLES9IYXNVwAERA9w From: "Don Fedyk" To: "Greg Bernstein" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Greg Whoa....=20 > -----Original Message----- > From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 > Sent: Monday, June 05, 2006 12:17 PM > To: ccamp@ops.ietf.org; pce@ietf.org > Subject: [Pce] Virtual Network Topology (VNT) changes and IP=20 > layer routingloops >=20 > Hi folks, in drafts draft-ietf-ccamp-gmpls-mln-reqs-00.txt=20 > and draft-ietf-pce-inter-layer-frwk-00.txt the concepts of=20 > multi-layer and multi-region networking are defined and discussed.=20 >=20 > An important case is when the IP layer rests directly upon a=20 > "virtual network topology" layer that we will desire to=20 > change via GMPLS signaling. Changes to the IP layer VNT can=20 > produce "transient IP layer routing loops" also known as=20 > "micro loops" which can last 100's of mili seconds or more. =20 > Hence any time we change a connection between IP layer=20 > routers via GMPLS we can cause significant outages compared=20 > to the recovery times that we set out to achieve with GMPLS=20 > fast reroute and other mechanisms such as SDH APS (rings and linear). 1) These virtual topologies are for control traffic and they are solid most of the time. 2) The existing data traffic is not disrupted when the control traffic has microloops.=20 3) There may be a delay in signaling of new or rerouted connections when the control traffic has microloops. This is analogous to Graceful recovery of the control plane where the data plane is momentarily unable to adapt to new changes. 4) Many of the optical technologies we have do not need response to signaling in less than 100s of milliseconds so the delay is not critical. 5) We need a clear separation of protection which can be locally driven and fast (50 msec) and routing and rerouting which are slower restoration mechanisms. As long as protection mechanisms are independent of the control plane primary protection is safe IMHO. >=20 > At the Routing working group, Alex's draft=20 > draft-ietf-rtgwg-microloop-analysis-01.txt provides some=20 > analysis and a method to reduce the impact (duration too) of=20 > the transient loops. More recently the drafts: > (1) draft-bryant-shand-lf-applicability-01.txt > (2) draft-bryant-shand-lf-conv-frmwk-02.txt > (3) draft-francois-ordered-fib-01.txt > Address this problem more generally including in (3) a method=20 > that guarantee loop free convergence. >=20 Loop Free Alternates are a good thing. But with more advanced mechanisms it is very hard to determine if the cure is worse than the symptoms. > The problem is that these have generated very little interest=20 > at the RTG WG and may not move forward. This area is not=20 > within PCE or CCAMPs charter but can have an impact on the=20 > adoption of GMPLS in multi-layer/region networking. If you're=20 > interested please take a look and comment to the RTG WG. =20 > Note I wasn't involved with writing these, but came across=20 > them when considering the effects of GMPLS changes on the IP=20 > layer VNT. There was a lot of interest and a genuine amount of push back. Personally I would be very concerned about tight coupling of a control plane convergence to impacts on a GMPLS control data plane.=20 Regards, Don=20 >=20 > Thanks >=20 > Greg B. >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 05 16:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLPc-0003qT-G3; Mon, 05 Jun 2006 16:10:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnLPb-0003qO-1v for pce@ietf.org; Mon, 05 Jun 2006 16:10:55 -0400 Received: from pro.abac.com ([66.226.64.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnLPZ-0000lE-LH for pce@ietf.org; Mon, 05 Jun 2006 16:10:55 -0400 Received: from [192.168.0.100] (c-67-188-134-148.hsd1.ca.comcast.net [67.188.134.148]) (authenticated bits=0) by pro.abac.com (8.13.6/8.13.6) with ESMTP id k55KAkid076396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jun 2006 13:10:51 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <44848FC5.7000902@grotto-networking.com> Date: Mon, 05 Jun 2006 13:10:45 -0700 From: Greg Bernstein User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Don Fedyk Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops References: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ccamp@ops.ietf.org, 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 Don, I'm using the term "Virtual Network Topology" related to the data plane not the control plane. For example, when I interconnect IP routers via a WDM or SDH switching layer the resulting IP layer topology is termed a "virtual network topology" since the connectivity amongst the IP routers is not necessarily the same as the fiber topology. It is these changes to the IP layer topology that can cause the traffic disrupting micro loops. Note that other ways that micro loops occur are: (1) during IGP link weight adjustments and (2) maintenance operations. The connection to GMPLS/PCE is we are trying to make setting up these virtual topologies quicker and potential for traffic engineering purposes. There have been some good papers in the literature on using GMPLS and advanced algorithms for the VNT design problem. Greg B. Don Fedyk wrote: > Hi Greg > > Whoa.... > > > [Snip] > 1) These virtual topologies are for control traffic and they are solid > most of the time. > 2) The existing data traffic is not disrupted when the control traffic > has microloops. > 3) There may be a delay in signaling of new or rerouted connections when > the control traffic has microloops. This is analogous to Graceful > recovery of the control plane where the data plane is momentarily unable > to adapt to new changes. > 4) Many of the optical technologies we have do not need response to > signaling in less than 100s of milliseconds so the delay is not > critical. > 5) We need a clear separation of protection which can be locally driven > and fast (50 msec) and routing and rerouting which are slower > restoration mechanisms. As long as protection mechanisms are independent > of the control plane primary protection is safe IMHO. > > > >> At the Routing working group, Alex's draft >> draft-ietf-rtgwg-microloop-analysis-01.txt provides some >> analysis and a method to reduce the impact (duration too) of >> the transient loops. More recently the drafts: >> (1) draft-bryant-shand-lf-applicability-01.txt >> (2) draft-bryant-shand-lf-conv-frmwk-02.txt >> (3) draft-francois-ordered-fib-01.txt >> Address this problem more generally including in (3) a method >> that guarantee loop free convergence. >> >> > > Loop Free Alternates are a good thing. But with more advanced > mechanisms it is very hard to determine if the cure is worse than the > symptoms. > > > >> The problem is that these have generated very little interest >> at the RTG WG and may not move forward. This area is not >> within PCE or CCAMPs charter but can have an impact on the >> adoption of GMPLS in multi-layer/region networking. If you're >> interested please take a look and comment to the RTG WG. >> Note I wasn't involved with writing these, but came across >> them when considering the effects of GMPLS changes on the IP >> layer VNT. >> > > There was a lot of interest and a genuine amount of push back. > Personally I would be very concerned about tight coupling of a control > plane convergence to impacts on a GMPLS control data plane. > > Regards, > Don > > > >> Thanks >> >> Greg B. >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jun 06 19:12:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkiO-0002N5-Ac; Tue, 06 Jun 2006 19:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkiM-0002Fs-TH for pce@ietf.org; Tue, 06 Jun 2006 19:11:58 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnkiK-0000UC-Nv for pce@ietf.org; Tue, 06 Jun 2006 19:11:58 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k56NBoYp008121; Wed, 7 Jun 2006 08:11:50 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k56NBnWf021495; Wed, 7 Jun 2006 08:11:49 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k56NBmmv024588; Wed, 7 Jun 2006 08:11:48 +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.6/8.13.6) with ESMTP id k56NBmgP020595; Wed, 7 Jun 2006 08:11:48 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k56NBmWc001179; Wed, 7 Jun 2006 08:11:48 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k56NBlq2001176; Wed, 7 Jun 2006 08:11:47 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.125]) by imc.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k56NBamF004857; Wed, 7 Jun 2006 08:11:47 +0900 (JST) Message-ID: <44860BA7.2090301@lab.ntt.co.jp> Date: Wed, 07 Jun 2006 08:11:35 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Greg Bernstein Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops References: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com> <44848FC5.7000902@grotto-networking.com> In-Reply-To: <44848FC5.7000902@grotto-networking.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ccamp@ops.ietf.org, 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 Greg Thank you for your kind notice. I think that the avoiding micro-loop is an important work. Micro-loop could unnecessarily amplify traffic load as much as 128 times, which should be a serious problem for today's wire-speed packet forwarding at high-speed link. So far micro-loop avoidance has been discussed in the context of maintenance operations including link install/removal, IGP link cost change, etc. As you pointed out, micro-loop may form in the process of VNT reconfiguration if IP datagram is forwarded directly on top of VNT (if we use explicit-routed LSP, we could avoid micro-loop). Micro-loop avoidance should also be considered in the context of VNT reconfiguration. Thank you again for your pointer. -- Kohei Greg Bernstein wrote: > Hi Don, I'm using the term "Virtual Network Topology" related to the > data plane not the control plane. For example, when I interconnect IP > routers via a WDM or SDH switching layer the resulting IP layer topology > is termed a "virtual network topology" since the connectivity amongst > the IP routers is not necessarily the same as the fiber topology. It is > these changes to the IP layer topology that can cause the traffic > disrupting micro loops. Note that other ways that micro loops occur > are: (1) during IGP link weight adjustments and (2) maintenance operations. > > The connection to GMPLS/PCE is we are trying to make setting up these > virtual topologies quicker and potential for traffic engineering > purposes. There have been some good papers in the literature on using > GMPLS and advanced algorithms for the VNT design problem. > > Greg B. > > Don Fedyk wrote: > >> Hi Greg >> >> Whoa.... >> [Snip] >> 1) These virtual topologies are for control traffic and they are solid >> most of the time. >> 2) The existing data traffic is not disrupted when the control traffic >> has microloops. 3) There may be a delay in signaling of new or >> rerouted connections when >> the control traffic has microloops. This is analogous to Graceful >> recovery of the control plane where the data plane is momentarily unable >> to adapt to new changes. >> 4) Many of the optical technologies we have do not need response to >> signaling in less than 100s of milliseconds so the delay is not >> critical. >> 5) We need a clear separation of protection which can be locally driven >> and fast (50 msec) and routing and rerouting which are slower >> restoration mechanisms. As long as protection mechanisms are independent >> of the control plane primary protection is safe IMHO. >> >> >> >> >>> At the Routing working group, Alex's draft >>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis and >>> a method to reduce the impact (duration too) of the transient loops. >>> More recently the drafts: >>> (1) draft-bryant-shand-lf-applicability-01.txt >>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt >>> (3) draft-francois-ordered-fib-01.txt >>> Address this problem more generally including in (3) a method that >>> guarantee loop free convergence. >>> >>> >> >> >> Loop Free Alternates are a good thing. But with more advanced >> mechanisms it is very hard to determine if the cure is worse than the >> symptoms. >> >> >> >> >>> The problem is that these have generated very little interest at the >>> RTG WG and may not move forward. This area is not within PCE or >>> CCAMPs charter but can have an impact on the adoption of GMPLS in >>> multi-layer/region networking. If you're interested please take a >>> look and comment to the RTG WG. Note I wasn't involved with writing >>> these, but came across them when considering the effects of GMPLS >>> changes on the IP layer VNT. >>> >> >> >> There was a lot of interest and a genuine amount of push back. >> Personally I would be very concerned about tight coupling of a control >> plane convergence to impacts on a GMPLS control data plane. >> Regards, >> Don >> >> >> >>> Thanks >>> >>> Greg B. >>> >>> -- >>> =================================================== >>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>> >> >> >> >> > > -- Kohei Shiomoto NTT Network Service Systems Laboratories _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jun 06 20:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmKE-00059m-QU; Tue, 06 Jun 2006 20:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmKC-00059h-QT for pce@ietf.org; Tue, 06 Jun 2006 20:55:08 -0400 Received: from pro.abac.com ([66.226.64.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnmKB-0006Sh-D3 for pce@ietf.org; Tue, 06 Jun 2006 20:55:08 -0400 Received: from [192.168.0.103] (c-67-188-134-148.hsd1.ca.comcast.net [67.188.134.148]) (authenticated bits=0) by pro.abac.com (8.13.6/8.13.6) with ESMTP id k570swPW065715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jun 2006 17:55:04 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <448623E2.5090204@grotto-networking.com> Date: Tue, 06 Jun 2006 17:54:58 -0700 From: Greg Bernstein User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kohei Shiomoto Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops References: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com> <44848FC5.7000902@grotto-networking.com> <44860BA7.2090301@lab.ntt.co.jp> In-Reply-To: <44860BA7.2090301@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: ccamp@ops.ietf.org, 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 Kohei, For the folks who haven't read the "micro-loop" drafts. These describe transient loops that can occur at the IP layer or in MPLS with LDP. In the GMPLS world we may also use the term LSP somewhat loosely to apply to SDH, WDM, G.709 connections. Since these are all explicitly routed (and due to their circuit switched nature too) we won't get loops at these layers. However, when we use GMPLS to set up a new SDH, WDM, G.709, etc... connection (or tear down a connection) between IP routers (modifying the IP layer VNT) this looks like a link up or down "maintenance" action to the IP layer and hence the issue with micro-loops so well described in the drafts. Regards Greg B. Kohei Shiomoto wrote: > Hi Greg > > Thank you for your kind notice. > > I think that the avoiding micro-loop is an important work. Micro-loop > could unnecessarily amplify traffic load as much as 128 times, which > should be a serious problem for today's wire-speed packet forwarding at > high-speed link. > > So far micro-loop avoidance has been discussed in the context of > maintenance operations including link install/removal, IGP link cost > change, etc. As you pointed out, micro-loop may form in the process of > VNT reconfiguration if IP datagram is forwarded directly on top of VNT > (if we use explicit-routed LSP, we could avoid micro-loop). Micro-loop > avoidance should also be considered in the context of VNT reconfiguration. > > Thank you again for your pointer. > -- > Kohei > > > Greg Bernstein wrote: > > >> Hi Don, I'm using the term "Virtual Network Topology" related to the >> data plane not the control plane. For example, when I interconnect IP >> routers via a WDM or SDH switching layer the resulting IP layer topology >> is termed a "virtual network topology" since the connectivity amongst >> the IP routers is not necessarily the same as the fiber topology. It is >> these changes to the IP layer topology that can cause the traffic >> disrupting micro loops. Note that other ways that micro loops occur >> are: (1) during IGP link weight adjustments and (2) maintenance operations. >> >> The connection to GMPLS/PCE is we are trying to make setting up these >> virtual topologies quicker and potential for traffic engineering >> purposes. There have been some good papers in the literature on using >> GMPLS and advanced algorithms for the VNT design problem. >> >> Greg B. >> >> Don Fedyk wrote: >> >> >>> Hi Greg >>> >>> Whoa.... >>> [Snip] >>> 1) These virtual topologies are for control traffic and they are solid >>> most of the time. >>> 2) The existing data traffic is not disrupted when the control traffic >>> has microloops. 3) There may be a delay in signaling of new or >>> rerouted connections when >>> the control traffic has microloops. This is analogous to Graceful >>> recovery of the control plane where the data plane is momentarily unable >>> to adapt to new changes. >>> 4) Many of the optical technologies we have do not need response to >>> signaling in less than 100s of milliseconds so the delay is not >>> critical. >>> 5) We need a clear separation of protection which can be locally driven >>> and fast (50 msec) and routing and rerouting which are slower >>> restoration mechanisms. As long as protection mechanisms are independent >>> of the control plane primary protection is safe IMHO. >>> >>> >>> >>> >>> >>>> At the Routing working group, Alex's draft >>>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis and >>>> a method to reduce the impact (duration too) of the transient loops. >>>> More recently the drafts: >>>> (1) draft-bryant-shand-lf-applicability-01.txt >>>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt >>>> (3) draft-francois-ordered-fib-01.txt >>>> Address this problem more generally including in (3) a method that >>>> guarantee loop free convergence. >>>> >>>> >>>> >>> Loop Free Alternates are a good thing. But with more advanced >>> mechanisms it is very hard to determine if the cure is worse than the >>> symptoms. >>> >>> >>> >>> >>> >>>> The problem is that these have generated very little interest at the >>>> RTG WG and may not move forward. This area is not within PCE or >>>> CCAMPs charter but can have an impact on the adoption of GMPLS in >>>> multi-layer/region networking. If you're interested please take a >>>> look and comment to the RTG WG. Note I wasn't involved with writing >>>> these, but came across them when considering the effects of GMPLS >>>> changes on the IP layer VNT. >>>> >>>> >>> There was a lot of interest and a genuine amount of push back. >>> Personally I would be very concerned about tight coupling of a control >>> plane convergence to impacts on a GMPLS control data plane. >>> Regards, >>> Don >>> >>> >>> >>> >>>> Thanks >>>> >>>> Greg B. >>>> >>>> -- >>>> =================================================== >>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>>> >>>> >>> >>> >>> >> > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jun 06 22:31:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnpt-0002Gx-8e; Tue, 06 Jun 2006 22:31:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnnpr-0002GW-ST for pce@ietf.org; Tue, 06 Jun 2006 22:31:55 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnnpp-0006xR-TM for pce@ietf.org; Tue, 06 Jun 2006 22:31:55 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572Vb5T020862; Wed, 7 Jun 2006 11:31:37 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572VYR1026484; Wed, 7 Jun 2006 11:31:34 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572VVBx026275; Wed, 7 Jun 2006 11:31:31 +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.6/8.13.6) with ESMTP id k572VVf7021287; Wed, 7 Jun 2006 11:31:31 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k572VUuT017346; Wed, 7 Jun 2006 11:31:30 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k572VUNl017341; Wed, 7 Jun 2006 11:31:30 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.125]) by imc.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k572VMEI020774; Wed, 7 Jun 2006 11:31:30 +0900 (JST) Message-ID: <44863A78.2030601@lab.ntt.co.jp> Date: Wed, 07 Jun 2006 11:31:20 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Greg Bernstein Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops References: <34B3EAA5B3066A42914D28C5ECF5FEA408BEAF1C@zrtphxm2.corp.nortel.com> <44848FC5.7000902@grotto-networking.com> <44860BA7.2090301@lab.ntt.co.jp> <448623E2.5090204@grotto-networking.com> In-Reply-To: <448623E2.5090204@grotto-networking.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: ccamp@ops.ietf.org, 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 Greg Thank you for your reply. > Hi Kohei, For the folks who haven't read the "micro-loop" drafts. These > describe transient loops that can occur at the IP layer or in MPLS with > LDP. In the GMPLS world we may also use the term LSP somewhat loosely to > apply to SDH, WDM, G.709 connections. Since these are all explicitly > routed (and due to their circuit switched nature too) we won't get loops > at these layers. I just meant to explicit-routed LSP in MPLS domain over VNT in the previous email. > > However, when we use GMPLS to set up a new SDH, WDM, G.709, etc... > connection (or tear down a connection) between IP routers (modifying the > IP layer VNT) this looks like a link up or down "maintenance" action to > the IP layer and hence the issue with micro-loops so well described in > the drafts. Yes. I called it VNT reconfiguration in the previous email. Either IP datagram or MPLS labeled packet can be forwarded over the VNT. If we use the explicit routed LSP to forward the MPLS labeled packet, we can control the route to avoid micro-loop before the VNT changes. Of course we need a micro-loop avoidance mechanism when we carry IP datagram packet directly over the VNT. Such issue need to be addressed in the future revision in the MLN docs and the Inter-layer PCE/VNT manager docs. Thanks, -- Kohei > > Regards > > Greg B. > > Kohei Shiomoto wrote: > >> Hi Greg >> >> Thank you for your kind notice. >> >> I think that the avoiding micro-loop is an important work. Micro-loop >> could unnecessarily amplify traffic load as much as 128 times, which >> should be a serious problem for today's wire-speed packet forwarding at >> high-speed link. >> >> So far micro-loop avoidance has been discussed in the context of >> maintenance operations including link install/removal, IGP link cost >> change, etc. As you pointed out, micro-loop may form in the process of >> VNT reconfiguration if IP datagram is forwarded directly on top of VNT >> (if we use explicit-routed LSP, we could avoid micro-loop). Micro-loop >> avoidance should also be considered in the context of VNT >> reconfiguration. >> >> Thank you again for your pointer. >> -- >> Kohei >> >> >> Greg Bernstein wrote: >> >> >> >>> Hi Don, I'm using the term "Virtual Network Topology" related to the >>> data plane not the control plane. For example, when I interconnect >>> IP routers via a WDM or SDH switching layer the resulting IP layer >>> topology is termed a "virtual network topology" since the >>> connectivity amongst the IP routers is not necessarily the same as >>> the fiber topology. It is these changes to the IP layer topology that >>> can cause the traffic disrupting micro loops. Note that other ways >>> that micro loops occur are: (1) during IGP link weight adjustments >>> and (2) maintenance operations. >>> >>> The connection to GMPLS/PCE is we are trying to make setting up these >>> virtual topologies quicker and potential for traffic engineering >>> purposes. There have been some good papers in the literature on using >>> GMPLS and advanced algorithms for the VNT design problem. >>> >>> Greg B. >>> >>> Don Fedyk wrote: >>> >>> >>> >>>> Hi Greg >>>> >>>> Whoa.... >>>> [Snip] >>>> 1) These virtual topologies are for control traffic and they are solid >>>> most of the time. >>>> 2) The existing data traffic is not disrupted when the control traffic >>>> has microloops. 3) There may be a delay in signaling of new or >>>> rerouted connections when >>>> the control traffic has microloops. This is analogous to Graceful >>>> recovery of the control plane where the data plane is momentarily >>>> unable >>>> to adapt to new changes. >>>> 4) Many of the optical technologies we have do not need response to >>>> signaling in less than 100s of milliseconds so the delay is not >>>> critical. >>>> 5) We need a clear separation of protection which can be locally driven >>>> and fast (50 msec) and routing and rerouting which are slower >>>> restoration mechanisms. As long as protection mechanisms are >>>> independent >>>> of the control plane primary protection is safe IMHO. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At the Routing working group, Alex's draft >>>>> draft-ietf-rtgwg-microloop-analysis-01.txt provides some analysis >>>>> and a method to reduce the impact (duration too) of the transient >>>>> loops. More recently the drafts: >>>>> (1) draft-bryant-shand-lf-applicability-01.txt >>>>> (2) draft-bryant-shand-lf-conv-frmwk-02.txt >>>>> (3) draft-francois-ordered-fib-01.txt >>>>> Address this problem more generally including in (3) a method that >>>>> guarantee loop free convergence. >>>>> >>>>> >>>> >>>> Loop Free Alternates are a good thing. But with more advanced >>>> mechanisms it is very hard to determine if the cure is worse than the >>>> symptoms. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> The problem is that these have generated very little interest at >>>>> the RTG WG and may not move forward. This area is not within PCE >>>>> or CCAMPs charter but can have an impact on the adoption of GMPLS >>>>> in multi-layer/region networking. If you're interested please take >>>>> a look and comment to the RTG WG. Note I wasn't involved with >>>>> writing these, but came across them when considering the effects of >>>>> GMPLS changes on the IP layer VNT. >>>>> >>>> >>>> There was a lot of interest and a genuine amount of push back. >>>> Personally I would be very concerned about tight coupling of a control >>>> plane convergence to impacts on a GMPLS control data plane. >>>> Regards, >>>> Don >>>> >>>> >>>> >>>> >>>> >>>>> Thanks >>>>> >>>>> Greg B. >>>>> >>>>> -- >>>>> =================================================== >>>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jun 07 10:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyta-0002MV-JY; Wed, 07 Jun 2006 10:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnyta-0002ME-2s for pce@ietf.org; Wed, 07 Jun 2006 10:20:30 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnytY-0007no-NK for pce@ietf.org; Wed, 07 Jun 2006 10:20:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 07 Jun 2006 07:20:28 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="1821146865:sNHT37595082" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k57EKRa9021686; Wed, 7 Jun 2006 07:20:28 -0700 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 k57EKRIs021666; Wed, 7 Jun 2006 10:20:27 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 10:20:27 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 10:20:26 -0400 In-Reply-To: <44845914.3090207@grotto-networking.com> References: <44845914.3090207@grotto-networking.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97684F9F-453A-435C-95FA-96778779D9C6@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routing loops Date: Wed, 7 Jun 2006 10:20:22 -0400 To: Greg Bernstein X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 07 Jun 2006 14:20:26.0675 (UTC) FILETIME=[85A97030:01C68A3D] DKIM-Signature: a=rsa-sha1; q=dns; l=2413; t=1149690028; x=1150554028; c=relaxed/simple; s=sjdkim2001; 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]=20Virtual=20Network=20Topology=20(VNT)=20changes=20and=20I P=20layer=20routing=20loops; X=v=3Dcisco.com=3B=20h=3D4WLiFWjDUNLvTOSsgm7b6ade6MA=3D; b=Pf843R8r0aQsi9LZR4oqi8AhT+1SmubLcC1hLrc5B9WXNUe6kFtAiuWy/nwzKWnjArB33m2L bLO7CQIXX5dCGuuUrUDZdEAHlbEuWnDFTrhoGiCDQRsyRaSpDx89MePZ; Authentication-Results: sj-dkim-2.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ccamp@ops.ietf.org, 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 Greg, Thanks for your note. I just wanted to add that this is no different from IGP Link weight tuning and off-line algorithms/heuristics computing link costs already take such constraint into account. One can expect an PCE implementation for VNT computation to also take such constraint into account. Cheers, JP. On Jun 5, 2006, at 12:17 PM, Greg Bernstein wrote: > Hi folks, in drafts draft-ietf-ccamp-gmpls-mln-reqs-00.txt and > draft-ietf-pce-inter-layer-frwk-00.txt the concepts of multi-layer > and multi-region networking are defined and discussed. > An important case is when the IP layer rests directly upon a > "virtual network topology" layer that we will desire to change via > GMPLS signaling. Changes to the IP layer VNT can produce "transient > IP layer routing loops" also known as "micro loops" which can last > 100's of mili seconds or more. Hence any time we change a > connection between IP layer routers via GMPLS we can cause > significant outages compared to the recovery times that we set out > to achieve with GMPLS fast reroute and other mechanisms such as SDH > APS (rings and linear). > > At the Routing working group, Alex's draft draft-ietf-rtgwg- > microloop-analysis-01.txt provides some analysis and a method to > reduce the impact (duration too) of the transient loops. More > recently the drafts: > (1) draft-bryant-shand-lf-applicability-01.txt > (2) draft-bryant-shand-lf-conv-frmwk-02.txt > (3) draft-francois-ordered-fib-01.txt > Address this problem more generally including in (3) a method that > guarantee loop free convergence. > > The problem is that these have generated very little interest at > the RTG WG and may not move forward. This area is not within PCE > or CCAMPs charter but can have an impact on the adoption of GMPLS > in multi-layer/region networking. If you're interested please take > a look and comment to the RTG WG. Note I wasn't involved with > writing these, but came across them when considering the effects of > GMPLS changes on the IP layer VNT. > > Thanks > > Greg B. > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jun 09 15:48:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomyC-0002q7-MZ; Fri, 09 Jun 2006 15:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomyB-0002pV-LK for pce@ietf.org; Fri, 09 Jun 2006 15:48:35 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FomyA-00036G-C6 for pce@ietf.org; Fri, 09 Jun 2006 15:48:35 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k59JmPE17425; Fri, 9 Jun 2006 15:48:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops Date: Fri, 9 Jun 2006 15:48:22 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA408D95FD1@zrtphxm2.corp.nortel.com> In-Reply-To: <44848FC5.7000902@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops Thread-Index: AcaI3HZkq2MkWZY0Rdu+IWPkF1TLuAAAIdnA From: "Don Fedyk" To: "Greg Bernstein" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ccamp@ops.ietf.org, 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 Greg Sorry for the delay on this.=20 > -----Original Message----- > From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 >=20 > Hi Don, I'm using the term "Virtual Network Topology" related=20 > to the data plane not the control plane. For example, when I=20 > interconnect IP routers via a WDM or SDH switching layer the=20 > resulting IP layer topology is termed a "virtual network=20 > topology" since the connectivity amongst the IP routers is=20 > not necessarily the same as the fiber topology. It is these=20 > changes to the IP layer topology that can cause the traffic=20 > disrupting micro loops. Note that other ways that micro loops occur > are: (1) during IGP link weight adjustments and (2)=20 > maintenance operations. >=20 > The connection to GMPLS/PCE is we are trying to make setting=20 > up these virtual topologies quicker and potential for traffic=20 > engineering purposes. There have been some good papers in the=20 > literature on using GMPLS and advanced algorithms for the VNT=20 > design problem. OK In as much as these topologies represent nodes and links, some how distributed, I would agree that:=20 1) Proactive topology changes should be dealt with in a graceful manner. One way is to have loop free alternates activated then make the topology changes. This may result in slowly stepwise shifting the topology when turning on/off resources.=20 More elaborate schemes can add coverage in this case. But you can just as well design mechanisms for this particular case that explicit versus algorithmic.=20 2) When it comes to reactive topology changes that is where it gets a bit trickier. You should have have loop free and perhaps a few more advanced IPFRR techniques. But most of IPFRR can only protect single failure protection, node or links. There are provisions for shared resource correlation to maximize picking independent alternates still biased by a single failure.=20 While the simple IPFRR techniques are a no brainer I'm not convinced that Virutal network topology is an agrument for more complex IPFRR.=20 Regards, Don=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jun 10 12:56:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp6lT-0002Jp-27; Sat, 10 Jun 2006 12:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp6lS-0002He-4S for pce@ietf.org; Sat, 10 Jun 2006 12:56:46 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp6lR-0007H5-9a for pce@ietf.org; Sat, 10 Jun 2006 12:56:46 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fp6lh-0004Sy-00 for pce@ietf.org; Sat, 10 Jun 2006 17:57:01 +0100 Received: from your029b8cecfe ([217.158.132.206] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Jun 2006 17:56:38 +0100 Message-ID: <02e001c68cae$d1f154d0$c2849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Sat, 10 Jun 2006 13:49:06 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 10 Jun 2006 16:56:39.0300 (UTC) FILETIME=[D76BC440:01C68CAE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com Subject: [Pce] Comments on draft-vasseur-pce-brpc-00.txt 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, Thanks for keeping these ideas alive. Here are some picky thoughts that you may want to include in the next revision to make it more robust as a document. I don't have any issues with the basic process. Thanks, Adrian == Is this I-D likely to be Informational or Standards Track? From Appendix A, this looks like Standards Track. Can you remove Appendix A and put the status in the usual place in the header? == It would be nice if the Abstract contained a pithy summary of brpc and/or gave the motivation for the draft. For example, what is the method trying to achieve that isn't achievable by other methods? Or, what is the fundamental element of brpc that is not in other methods? == I'm assuming that section 1 is for short term information only and will be deleted (in the next revision?) == Section 2. Terminology s/ABR Router/ABR/ s/ASBR Router/ASBR/ Inter-area TE LSP: A TE LSP that crosses an IGP area. ... s/IGP area/IGP area boundary/ LSR ...please get this right! == Section 2 Boundary LSR ... the text seems to use 'boundary LSR', 'border node', 'boundary router'. Can you find some consistency? == Section 2 I think draft-ietf-ccamp-inter-domain-framework would be a better reference for definitions of stitching, contiguous and nesting == Section 3 para 3 s/proposes/defines/ == Section 3 I think that the point about pd-path-comp is that it does not just provide a mechanism for computing the paths, but it provides a mechanism for computing and signaling the paths at the same time (although it could be adapted to be just a computation technique, this is not what the pd-path-comp I-D is describing). This is worth highlighting, because this draft is describing a process for cooperation between PCEs in the absence of signaling (i.e. it is truly a computation technique). == Section 3 Although one model consists of making the boundary routers act as PCE, I recommend removing this sentence. You could equally have said "although one model consists of making every router with the lowest router ID in the domain acting as a PCE". The sentence adds no value at this point in the document since it is well-known that PCEs are just PCEs. If a later example places the PCE function on the boundary routers then that is where you should explain that it is only an example. == Section 3 The mechanisms proposed in this document are also applicable to (G)MPLS TE domains other than areas and ASs. s/proposed/defined/ I can smell an assertion! I suggest you add a section near the end of the document to explain this statement, or remove it. == Section 4 Be careful to show that you mean MPLS TE, not simply TE. == Section 4 - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple domains. You should clarify what you are saying here, because many would argue that reachability information (i.e. external routes) constitutes topology and resource information. But also, what has the fact that the TE LSP spans multiple domains got to do with preserving routing protocol scalability? Probably just delete from "in the case..." to the end of the sentence. == Section 4 - While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. Why does the policy agreement need to be offline? == Section 5 No assumption is made on the actual path computation algorithm in use by the PCE (it can be any variant of CSPF, algorithm based on linear- programming to solve multi-constraints optimization problems and so on). Suggest that you delete the text in parenthesis because it is making suggestions that border on assumptions! == Section 5 Some good work on clarifying things here since the previous version of the I-D (sent to CCAMP). Thanks. == Section 5.1 and throughout "BRPC path computation" seems to be tautologous == Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. == Section 5.2 This is the second terminology section in the I-D, and there is some duplication/overlap. Jumping ahead of ourselves a bit, I can hear the IESG demanding that there be only one terminology section per RFC. == Section 5.2 The introduction of the term Virtual Shortest Path Tree is hard to parse and to my mind the definition is arse about tit. I think you could usefully add some textual definition of what the VSPT is trying to achieve, before presenting it in pictorial or abstract form. Even more important (I think) is the fact that the tree as presented "represents the shortest path between the destination and BR-en(j,i)..." Frankly, we are building directional paths in exactly the oposite direction! So the VSPT is still a tree, but it is an MP2P tree, not a P2MP tree as described. I suspect that this is just a textual descriptive issue rather than anything broken in the process. Lastly, I suggest you make it clearer that, as the tree is relayed back along the PCE sequence, the VSPT is pruned so that it only ever (assuming no support of node-congruent diverse paths) contains one path from and BR-en(i,j) to the destination. == Section 5.2 Please be careful with the use of "BR(s)" as it looks like the notation for a BR of domain s! You are allowed to use "BRs" in the sense of "one or more BR" == Section 5.2 Note that PCE(i) would only consider BRs having connectivity with BR(s) of domain(i-1) in the VSPT(i). I think this can be re-written as Note that PCE(i) only considers the entry BRs that provide connectivity from domain(i-1). That is, the set BR-en(j,i) is only those BRs that provide connectivity from domain (i-1) to domain(i). == Section 5.2 I found your step 1 and step 2 to be accurate but very hard to parse as steps. can you break them down into atomic actions? For example: Step 1 a. The PCC selects a PCE(1) to serve its computation request b. The PCC sends the request to PCE(1) c. PCE(1) forwards the request to PCE(2), and each PCE(n) forwards the request to PCE(n+1). At each stage: i. PCE(n) determines the next domain or domains to be considered on the route. This may be achieved by static information configured at PCE(n) or by information encoded in the computation request, or through a combination of the two pieces of information through the application of policy. ii. PCE(n) determines PCE(n+1) through the knowledge of the next domain (domain(n+1)) and by configuration or discovery of the PCEs that compute paths for domain(n+1). Where more than one PCE is available for domain(n+1) PCE(n) makes the selection using local configuration, information carried on the path computation request, PCE capabilities, and policy. iii. If, at any stage, PCE(n+1) cannot be determined or reached, an error is returned to PCE(n-1) (see Section 7). Do the same for Step 2 and the whole thing will be massively clearer. == Section 5.2 I suggest that you pull the note (Note: in term of computation...) out into a separate section. It doesn't belong in the middle of section 5.2. You will probably want to re-write the text as well since the unidirectional limit is not necessary. Also to explain 'flood' - flood to where, and how, and by whom? And you will want to add to pieces of information: - the link to the I-D that defines how to do this - a description of what happens if this process is not used. == Section 5.2 The paragraph that begins "BRPC guarantees to find the optimal..." is a nascent Applicability Statement. I suggest moving this to another Section and significantly beefing it up. You need to describe more fully: - how ECMP works (the PCC has to request the return of more than one path) - how diversity works (i.e. section 9 fits in here) - how some freedom of selection of domains can be offered - how to mix the method with other mechanisms == Section 6 I'm afraid that this is back on the process of providing reverse paths. Not helpful in a TE environment where link properties may be unidirectional. The requirements, therefore, is to supply paths from multiple entry points towards a common destination (not the reverse). == Section 6 What is the VSPT object? It seems to be mentioned, but not defined. Over time, I hope this section will be fleshed out to state exactly which PCEP fields are used to carry what information on PCC-PCE(1) and PCE(n)-PCE(n+1) requests, and PCE(1)-PCC, and PCE(n)-PCE(n-1) responses. == Section 7 If the BRPC procedure cannot be completed because a PCE along the domain path does not support the procedure, a PCErr message is returned by the upstream PCE with a Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. Not clear to me whether PCE(n) is supposed to know that PCE(n+1) does not support brpc, presumably through capabilities configuration/advertisement/negotiation, or whether PCE(n+1) is supposed to respond to the path computation request saying that it does not support bit-V of the RP object. If the latter, presumably the PCErr comes from PCE(n+1) and not from PCE(n) as documented. == Section 7 Error-value 1: BRPC procedure not supported by one or PCEs along the domain path I think you want to work on this text a bit. In fact, the problem is that no PCE that supports the brpc procedure can be found for a domain in the list of required domains along the path. == Section 8 Metric normalisation is a great potential solution, but how does it fit with AS topology confidentiality? What is the solution to providing discretion about what TE connectivity is available within an AS, and operating brpc? == Section 9 As well as needing to fold this into a more general applicability section, I would suggest throwing out the marketing text (if you need to say why this is good, put it in the intro as part of the problem to be solved) and introducing some description of how to achieve the function. Does it allow domain diversity? Does it allow shared border routers? == Section 10 Some of this text has been seen before in this I-D Why do you single out LSP stitching as possibly breaking end-to-end optimality. There is functionally no difference between stitching and nesting in this respect. But further, your statement about stitching is pejorative! If you say that "In the case where a domain has more than one BR-en or more than one BR-ex, optimality after some network change within the domain can only be guaranteed by re-executing the full brpc computation" then I would agree with you. But as phrased, it implies that making a per-domain re-optimisation could make the path *less* optimal. This (of course) is not the case - per-domain optimisation will always improve or leave the same end-to-end optimality (in the case where new resources are made available this is obvious; in the case of a network failure, *any* path is better than no path!) And, lastly, the text about re-optimisation belongs in the next section, not in this section. == Section 13 I would like you to discuss the issues of confidentiality of topology information at greater length. It seems that you would possibly use this technique in conjunction with path cookies, which is fine. But, are there two things you cannot escape from? - indicating which BR-en provides best connectivity - indicating the metric for multiple BR-ens Maybe there are some things that can be done here based on policy, including not reporting all of the BR-ens, ranking rather than giving absolute metrics, etc. But these would compromise optimality. Maybe the PCE(n+1) should carefully monitor and limit (statistically and by policy) brpc requests so that excessive information is not divulged? == I wouldn't mind seeing a Management Considerations section. Do we need to be able to examine the pruned pieces of VSPT at transit PCEs? What are the implications of reporting multiple VSPT branches in PCEP to the MIB modules? Is brpc support something that needs to be configured: per PCE?; per PCE-neighbor? What are the implications on existing protocols (IGPs? PCEP?) of using brpc? etc. == I think Jean-Louis' email address needs updating == The document would benefit from a little care in the formatting, and you could usefully re-read it for missing words, etc. == _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jun 10 14:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp89w-0000h2-0N; Sat, 10 Jun 2006 14:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp89u-0000TZ-Dt for pce@ietf.org; Sat, 10 Jun 2006 14:26:06 -0400 Received: from astrolabe.info.ucl.ac.be ([130.104.229.109] helo=info.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp89r-0007Pq-Tu for pce@ietf.org; Sat, 10 Jun 2006 14:26:06 -0400 Received: from [127.0.0.1] (bismarck [130.104.229.58]) by info.ucl.ac.be (8.12.11/8.12.11) with ESMTP id k5AIPkAL009441; Sat, 10 Jun 2006 20:25:47 +0200 (MET DST) Message-ID: <448B0EAA.6070200@info.ucl.ac.be> Date: Sat, 10 Jun 2006 20:25:46 +0200 From: Olivier Bonaventure User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fedyk Subject: Re: [Pce] Virtual Network Topology (VNT) changes and IP layer routingloops References: <34B3EAA5B3066A42914D28C5ECF5FEA408D95FD1@zrtphxm2.corp.nortel.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA408D95FD1@zrtphxm2.corp.nortel.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ccamp@ops.ietf.org, pce@ietf.org, Pierre Francois X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Don, >>-----Original Message----- >>From: Greg Bernstein [mailto:gregb@grotto-networking.com] >> >>Hi Don, I'm using the term "Virtual Network Topology" related >>to the data plane not the control plane. For example, when I >>interconnect IP routers via a WDM or SDH switching layer the >>resulting IP layer topology is termed a "virtual network >>topology" since the connectivity amongst the IP routers is >>not necessarily the same as the fiber topology. It is these >>changes to the IP layer topology that can cause the traffic >>disrupting micro loops. Note that other ways that micro loops occur >>are: (1) during IGP link weight adjustments and (2) >>maintenance operations. >> >>The connection to GMPLS/PCE is we are trying to make setting >>up these virtual topologies quicker and potential for traffic >>engineering purposes. There have been some good papers in the >>literature on using GMPLS and advanced algorithms for the VNT >>design problem. > > > OK In as much as these topologies represent nodes and links, some how > distributed, I would agree that: > > 1) Proactive topology changes should be dealt with in a graceful manner. I think that everyone agrees on this. Some operators have procedures to deal with planned link shutdowns by first setting the OSPF/ISIS weight of those links to the maximum metric value. This is a good way to move traffic before shutting down the link, but this technique may lead to transient loops during the OSPF/ISIS convergence. > One way is to have loop free alternates activated then make the topology > changes. Loop free alternates have one drawback. Only about 80% of the links in common ISP topologies are protected by loop-free alternates. How should the operator deal with links without LFA ? I'm not convinced that operators would like solution like the following ; - check whether the link is protected by LFA - if the link is protected by LFA, do something - otherwise do another check and do something else I guess operators will prefer a solution where the router recognise proactive changes and deal with them automatically. > This may result in slowly stepwise shifting the topology when turning on/off resources. > More elaborate schemes can add coverage in this case. But you can just > as well design mechanisms for this particular case that explicit versus > algorithmic. There is one simple solution to deal with proactive topology changes : order the FIB updates on the routers. This ordering guarantees that the network will converge without any transient loop and thyus without packet losses. This ordering can be easily added to link state protocols as shown in the following drafts : http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-01.txt http://www.ietf.org/internet-drafts/draft-bonaventure-isis-ordered-00.txt Furthermore, we recently did simulations to evaluate the convergence time of IS-IS with the proposed extension. For these simulations, we used as parameters the measured time to perform SPF, FIB updates, etc. on Cisco 12k as discussed in http://www.info.ucl.ac.be/people/OBO/papers/ccr403.pdf The simulations were performed by considering a European network and a Tier-1 ISP with presence in Europe, USA and Asia. In the Tier-1 ISP, the paper mentionned above showed that sub-second convergence with regular IS-IS can be achieved. Our recent simulations with the ordering of FIB updates indicate that sub-second *ordered* convergence is also achieved in this Tier-1 ISP. Basically, in this Tier-1 ISP, our simulations indicate that for a single link shutdown, regular IS-IS converges within 200- 300 milliseconds depending on the link being shutdown. During this regular IS-IS convergence, there are transient loops that lead to packet losses. With the ordered-ISIS, the convergence time is not larger than 750 milliseconds. During this convergence, there are *NO* packet losses in contrast to regular IS-IS. Thus, in contrast to popular belief, ordered FIB updates do not lead to slow network convergence... Olivier _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 12 05:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpj6Z-0006TS-3w; Mon, 12 Jun 2006 05:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpj6Y-0006TN-Gw for pce@ietf.org; Mon, 12 Jun 2006 05:53:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpj6U-0003Z9-8S for pce@ietf.org; Mon, 12 Jun 2006 05:53:06 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2006 05:53:00 -0400 X-IronPort-AV: i="4.05,228,1146456000"; d="scan'208,217"; a="89802808:sNHT38589368" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5C9r0no022540 for ; Mon, 12 Jun 2006 05:53:00 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 05:52:59 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Jun 2006 05:52:59 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Mon, 12 Jun 2006 05:52:58 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 12 Jun 2006 09:52:59.0845 (UTC) FILETIME=[FD123F50:01C68E05] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Pce] Preliminary agenda for IETF-66 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="===============0505025050==" Errors-To: pce-bounces@lists.ietf.org --===============0505025050== Content-Type: multipart/alternative; boundary=Apple-Mail-1-86807 --Apple-Mail-1-86807 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here is a preliminary agenda: https://datatracker.ietf.org/public/ meeting_agenda_html.cgi?meeting_num=66 Thanks. JP. --Apple-Mail-1-86807 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Here is a preliminary = agenda:=A0https://datatracker.ietf.org/public/meeting_agenda_html.cgi?me= eting_num=3D66

Thanks.

JP.
= --Apple-Mail-1-86807-- --===============0505025050== 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 --===============0505025050==-- From pce-bounces@lists.ietf.org Tue Jun 13 03:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3ST-0002OO-Vg; Tue, 13 Jun 2006 03:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3SS-0002OJ-Fj for pce@ietf.org; Tue, 13 Jun 2006 03:37:04 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3SP-0001jM-UX for pce@ietf.org; Tue, 13 Jun 2006 03:37:04 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S00BH4FUQ6C@szxga01-in.huawei.com> for pce@ietf.org; Tue, 13 Jun 2006 15:37:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0S008T6FUPC3@szxga01-in.huawei.com> for pce@ietf.org; Tue, 13 Jun 2006 15:37:37 +0800 (CST) Received: from z18605 ([10.110.115.154]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0S00IKAG9W9M@szxml04-in.huawei.com> for pce@ietf.org; Tue, 13 Jun 2006 15:46:44 +0800 (CST) Date: Tue, 13 Jun 2006 15:06:36 +0800 From: Zhang Renhai To: pce@ietf.org Message-id: <014c01c68eb7$e9805960$9a736e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Pce] Comments on draft-ietf-pce-disco-proto-igp 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="===============1701811098==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1701811098== Content-type: multipart/alternative; boundary="Boundary_(ID_fRJ+LEiiIaIaQMx7M1wOew)" This is a multi-part message in MIME format. --Boundary_(ID_fRJ+LEiiIaIaQMx7M1wOew) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGksIGFsbA0KDQpJIHJlY2VudGx5IHJlYWQgdGhlIGRyYWZ0IGRyYWZ0LWlldGYtcGNlLWRpc2Nv LXByb3RvLWlncCBhZ2FpbiwgaGVyZSBhcmUgc29tZSBjb21tZW50c6GjDQoNCldoZW4gSUdQIGlz IHVzZWQgYXMgYSBQQ0VEIHByb3RvY29sLCB0aGUgY2FwYWJpbGl0aWVzIG9mIHBjZSB3aWxsIGJl IGFkdmVydGlzZWQgcGVyaW9kaWNseSBhbG9uZyB3aXRoIG90aGVyIGxzYS9sc3AgaW5mb3JtYXRp b24uIEluIG15IG9waW5pb24sIHVubGVzcyB0aGUgUENFJ3MgY2FwYWJpbGl0aWVzIGNoYW5nZSwg IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBQQ0MgdG8gcmVjZWl2ZSBhbmQgaGFuZGxlIHRoZSBp bmZvcm1hdGlvbiBhZ2Fpbi4gRnVydGhlcm1vcmUsIGlmIG1vc3Qgb2YgdGhlIHJvdXRlcnMgaW4g YSBkb21haW4gd2lsbCBhbHdheXMgaGF2ZSBubyByZXF1ZXN0IHRvIGEgUENFLCB0aGVyZSBpcyBh bHNvIG5vIG5lZWQgZm9yIHRoZW0gdG8gbWFpbnRhaW4gdGhlIGluZm9ybWF0aW9uLiANCg0KTXkg Y29uY2VybiB0byBQQ0UtREVTVC1ET01BSU5TIHN1Yi1UTFYgaXMgdGhhdCB3ZSBjYW4ndCBhbnRp Y2lwYXRlIGhvdyBtYW55IGRlc3RpbmF0aW9uIGRvbWFpbnMgYSBQQ0UgY2FuICBjb21wdXRhdGUg cGF0aCB0b3dhcmRzLCBhcyBhIHJlc3VsdCx0aGUgbGVuZ3RoIG9mIHNwYWNlIHRha2VuIGJ5IHRo aXMgY2FwYWxpdHkgaW4gdGhlIG1lc3NhZ2UgY2FuJ3QgYmUgY29udHJvbGxlZC4gU28gSSB0aGlu ayBpZiB0aGUgUENDIHNlbmQgYSByZXF1ZXN0IHRvIGEgUENFIHdoaWNoIGNhbid0IGNvbXB1dGUg dGhlIHBhdGggZm9yIHRoZSByZWFzb24gb2YgdGhlIGRlc3RpbmF0aW9uIGRvbWFpbiwgdGhlIFBD RSBjYW4gdGVsbCB0aGUgUENDIGluIHRoZSBQQ3JlcCBtZXNzYWdlIHRoZSByaWdodCBQQ0UuIE9u ZSBhZGRpdGlvbmFsIHF1ZXNpb246IGlzIGl0IHN1aXRhYmxlIGZvciB0aGUgUENFIHRvIGhhdmUg c3VjaCBhYmlsaXR5IHRvIGtub3cgZXhhY3RseSB0aGUgZGVzdGluYXRpb24gZG9tYWluIGl0IGNh biBjb21wdXRlIHRvd2FyZHM/DQoNClNvbWUgZnVuY3Rpb25zIHNwZWNpZmllZCBpbiB0aGUgUEFU SC1DQU1QLUNBUCBzdWItVExWIGFyZSBhbHNvIGRlZmluZWQgaW4gdGhlIFBDRVAsICBhIGNsZWFy IGRpdmlzaW9uIHNob3VsZCBiZSBtYWRlLiANCg0KQ2hlZXJzLA0KDQpaaGFuZyBSZW5oYWkNCg== --Boundary_(ID_fRJ+LEiiIaIaQMx7M1wOew) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40ODA3LjIzMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+SGks IGFsbDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllcj5JIHJlY2VudGx5IHJlYWQgdGhl IGRyYWZ0IGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncCANCmFnYWluLCBoZXJlIGFyZSBz b21lIGNvbW1lbnRzoaM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllcj48L0ZP TlQ+PEZPTlQgZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1Db3VyaWVyPldoZW4gSUdQIGlzIHVzZWQmbmJzcDthcyBhIFBDRUQgcHJvdG9jb2wsIHRoZSAN CmNhcGFiaWxpdGllcyBvZiBwY2Ugd2lsbCBiZSBhZHZlcnRpc2VkIHBlcmlvZGljbHkgYWxvbmcg d2l0aCBvdGhlciBsc2EvbHNwIA0KaW5mb3JtYXRpb24uIEluIG15IG9waW5pb24sIHVubGVzcyB0 aGUgUENFJ3MgY2FwYWJpbGl0aWVzIGNoYW5nZSwmbmJzcDsgdGhlcmUgaXMgDQpubyBuZWVkIGZv ciB0aGUgUENDIHRvIHJlY2VpdmUgYW5kJm5ic3A7aGFuZGxlIHRoZSBpbmZvcm1hdGlvbiBhZ2Fp bi4gDQpGdXJ0aGVybW9yZSwgaWYgbW9zdCBvZiB0aGUgcm91dGVycyBpbiBhIGRvbWFpbiB3aWxs IGFsd2F5cyBoYXZlIG5vIHJlcXVlc3QgdG8gYSANClBDRSwgdGhlcmUgaXMgYWxzbyBubyBuZWVk IGZvciB0aGVtIHRvIG1haW50YWluIHRoZSBpbmZvcm1hdGlvbi4gPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUNvdXJpZXI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUNvdXJpZXI+TXkgY29uY2VybiB0byBQQ0UtREVTVC1ET01BSU5TIHN1Yi1UTFYmbmJzcDtpcyB0 aGF0IHdlIA0KY2FuJ3QgYW50aWNpcGF0ZSBob3cgbWFueSBkZXN0aW5hdGlvbiBkb21haW5zIGEg UENFIGNhbiAmbmJzcDtjb21wdXRhdGUgcGF0aCANCnRvd2FyZHMsJm5ic3A7YXMgYSByZXN1bHQs dGhlIGxlbmd0aCBvZiBzcGFjZSB0YWtlbiBieSB0aGlzIGNhcGFsaXR5IGluIHRoZSANCm1lc3Nh Z2UgY2FuJ3QgYmUgY29udHJvbGxlZC4gU28gSSB0aGluayBpZiB0aGUgUENDIHNlbmQgYSByZXF1 ZXN0IHRvIGEgUENFIHdoaWNoIA0KY2FuJ3QgY29tcHV0ZSB0aGUgcGF0aCBmb3IgdGhlIHJlYXNv biBvZiB0aGUgZGVzdGluYXRpb24gZG9tYWluLCB0aGUgUENFIGNhbiANCnRlbGwgdGhlIFBDQyBp biB0aGUgUENyZXAgbWVzc2FnZSZuYnNwO3RoZSByaWdodCBQQ0UuIE9uZSBhZGRpdGlvbmFsIHF1 ZXNpb246IGlzIA0KaXQgc3VpdGFibGUgZm9yIHRoZSBQQ0UgdG8gaGF2ZSBzdWNoIGFiaWxpdHkg dG8ga25vdyBleGFjdGx5IHRoZSBkZXN0aW5hdGlvbiANCmRvbWFpbiBpdCBjYW4gY29tcHV0ZSB0 b3dhcmRzPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPlNvbWUgZnVuY3Rpb25zIHNwZWNpZmll ZCBpbiB0aGUgUEFUSC1DQU1QLUNBUCBzdWItVExWIA0KYXJlIGFsc28mbmJzcDtkZWZpbmVkJm5i c3A7aW4gdGhlIFBDRVAsJm5ic3A7IGEgY2xlYXIgZGl2aXNpb24gc2hvdWxkIGJlIG1hZGUuIA0K PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+Q2hlZXJzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Db3Vy aWVyPlpoYW5nIFJlbmhhaTwvRk9OVD48L0RJVj48L0RJVj48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_fRJ+LEiiIaIaQMx7M1wOew)-- --===============1701811098== 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 --===============1701811098==-- From pce-bounces@lists.ietf.org Tue Jun 13 20:06:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIuP-0002fA-1L; Tue, 13 Jun 2006 20:06:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIu3-0002RX-Nj; Tue, 13 Jun 2006 20:06:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHxm-0005cW-J6; Tue, 13 Jun 2006 19:06:22 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqHiw-0005a0-3f; Tue, 13 Jun 2006 18:51:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5DMo1mU014133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqHhx-0006db-L2; Tue, 13 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-discovery-reqs-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Requirements for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux Filename : draft-ietf-pce-discovery-reqs-05.txt Pages : 18 Date : 2006-6-13 This document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-discovery-reqs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-discovery-reqs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-13154915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-discovery-reqs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-discovery-reqs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-13154915.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 Jun 14 08:57:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUvh-0001gx-0w; Wed, 14 Jun 2006 08:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUvZ-0001QU-S1 for pce@ietf.org; Wed, 14 Jun 2006 08:56:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUr6-0006Zr-Tt for pce@ietf.org; Wed, 14 Jun 2006 08:52:22 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2006 08:52:21 -0400 X-IronPort-AV: i="4.06,131,1149480000"; d="scan'208,217"; a="90007402:sNHT40922256" 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 k5ECqKYN021362; Wed, 14 Jun 2006 08:52:20 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 08:52:20 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Jun 2006 08:52:19 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: pce@ietf.org Message-Id: <222AD85A-13E3-42F5-A5A6-3F895F20C4EF@cisco.com> From: JP Vasseur Date: Wed, 14 Jun 2006 08:52:20 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 14 Jun 2006 12:52:19.0872 (UTC) FILETIME=[5F5F9200:01C68FB1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Pce] Incremental limited WG LC on draft-ietf-pce-discovery-reqs-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0814077380==" Errors-To: pce-bounces@lists.ietf.org --===============0814077380== Content-Type: multipart/alternative; boundary=Apple-Mail-43-183648383 --Apple-Mail-43-183648383 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, We received several comments about draft-ietf-pce-discovery-reqs during IESG review that have been addressed in the new revision -05 (http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery- reqs-05.txt). Some of them are editorial (clarifications, minor corrections, ...). The most significant change relates to section "6.10 Manageability considerations ". Thus this email initiates an incremental WG LC on this particular section 6.10 that will end on June the 21 9:00 EST time. Thanks. JP. --Apple-Mail-43-183648383 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear WG,

We received several = comments about draft-ietf-pce-discovery-reqs=A0during IESG review = that have been addressed in the new revision -05 (http://www.ietf.org/internet-drafts/draft-ietf-pce-discovery-reqs-= 05.txt). Some of them are editorial (clarifications, minor = corrections, ...). The most significant change relates to section "6.10 = Manageability considerations ". Thus this email initiates an incremental = WG LC on this particular section 6.10 that will end on June the 21 9:00 = EST time.

Thanks.

JP.
= --Apple-Mail-43-183648383-- --===============0814077380== 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 --===============0814077380==-- From pce-bounces@lists.ietf.org Sat Jun 17 08:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrZVl-0000XW-Pv; Sat, 17 Jun 2006 08:02:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrZVj-0000XR-VD for pce@ietf.org; Sat, 17 Jun 2006 08:02:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrZVi-0001HQ-M0 for pce@ietf.org; Sat, 17 Jun 2006 08:02:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Jun 2006 08:02:43 -0400 X-IronPort-AV: i="4.06,144,1149480000"; d="scan'208,217"; a="90292045:sNHT44347936" 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 k5HC2gYL008223 for ; Sat, 17 Jun 2006 08:02:42 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 08:02:42 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Jun 2006 08:02:41 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: pce@ietf.org Message-Id: <10948BDD-23B1-438D-90A5-6DFA2FECF437@cisco.com> References: From: JP Vasseur Date: Sat, 17 Jun 2006 08:02:39 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 17 Jun 2006 12:02:41.0968 (UTC) FILETIME=[EFA4BB00:01C69205] X-Spam-Score: 0.2 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: [Pce] Reminder: WG slot for IETF-66 ? 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="===============0442559795==" Errors-To: pce-bounces@lists.ietf.org --===============0442559795== Content-Type: multipart/alternative; boundary=Apple-Mail-108-439867361 --Apple-Mail-108-439867361 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, We'll publish early next week a draft of the WG meeting agenda, if you need a slot thanks to let us know. Thanks. JP and Adrian. Begin forwarded message: > From: JP Vasseur > Date: June 1, 2006 3:01:14 PM EDT > To: pce@ietf.org > Subject: [Pce] Agenda for IETF-66 WG meeting > > Hi, > > If you'd like to have a slot for the coming PCE WG meeting, thanks > to let us know. > > Thanks. > > JP and Adrian. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-108-439867361 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Hi,

We'll publish early next = week a draft of the WG meeting agenda, if you need a slot thanks to let = us know.

Thanks.

JP and = Adrian.

Begin forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = June 1, 2006 3:01:14 PM EDT
Subject: = [Pce] Agenda for IETF-66 WG meeting


If you'd like to have a slot for the coming PCE WG = meeting, thanks to let us know.

Thanks.

JP and = Adrian.

Pce mailing list
=

= --Apple-Mail-108-439867361-- --===============0442559795== 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 --===============0442559795==-- From pce-bounces@lists.ietf.org Mon Jun 19 04:24:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsF3F-0001xn-J9; Mon, 19 Jun 2006 04:24:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsF3E-0001xf-Io for pce@ietf.org; Mon, 19 Jun 2006 04:24:04 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsF3D-0001rk-SM for pce@ietf.org; Mon, 19 Jun 2006 04:24:04 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 10:24:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp Date: Mon, 19 Jun 2006 10:23:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-igp Thread-Index: AcaOvE5uArqm9hSJQZ2wEd4qPxr+EwEtaGtg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" , X-OriginalArrivalTime: 19 Jun 2006 08:24:02.0132 (UTC) FILETIME=[B8702140:01C69379] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 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="===============1510691689==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1510691689== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69379.B50DDE8E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69379.B50DDE8E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgWmhhbmcNCiANClRoYW5rcyBmb3IgeW91ciBjb21tZW50cw0KIA0KUGxlYXNlIHNlZSBpbmxp bmUsDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCURlIDogWmhhbmcg UmVuaGFpIFttYWlsdG86emhhbmdyZW5oYWlAaHVhd2VpLmNvbV0gDQoJRW52b3nDqSA6IG1hcmRp IDEzIGp1aW4gMjAwNiAwOTowNw0KCcOAIDogcGNlQGlldGYub3JnDQoJT2JqZXQgOiBbUGNlXSBD b21tZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3ANCgkNCgkNCglIaSwgYWxs DQoJIA0KCUkgcmVjZW50bHkgcmVhZCB0aGUgZHJhZnQgZHJhZnQtaWV0Zi1wY2UtZGlzY28tcHJv dG8taWdwIGFnYWluLCBoZXJlIGFyZSBzb21lIGNvbW1lbnRz44CCDQoJIA0KCVdoZW4gSUdQIGlz IHVzZWQgYXMgYSBQQ0VEIHByb3RvY29sLCB0aGUgY2FwYWJpbGl0aWVzIG9mIHBjZSB3aWxsIGJl IGFkdmVydGlzZWQgcGVyaW9kaWNseSBhbG9uZyB3aXRoIG90aGVyIGxzYS9sc3AgaW5mb3JtYXRp b24uIEluIG15IG9waW5pb24sIHVubGVzcyB0aGUgUENFJ3MgY2FwYWJpbGl0aWVzIGNoYW5nZSwg IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBQQ0MgdG8gcmVjZWl2ZSBhbmQgaGFuZGxlIHRoZSBp bmZvcm1hdGlvbiBhZ2Fpbi4gIA0KCSANCglKTExSOiBCdXQgdGhlc2UgYXJlIHN0YW5kYXJkIElH UCBwcm9jZWR1cmVzLiBUaGlzIGlzIHRoZSBzYW1lIGZvciBsaW5rIHN0YXRlcywgdGhleSBhcmUg cmVmcmVzaGVkIGV2ZW4gaWYgdGhlcmUgaXMgbm90IGNoYW5nZS4gQnkgdGhlIHdheSB0aGUgcmVm cmVzaCBpbnRlcnZhbCBjYW4gYmUgcXVpdGUgbGFyZ2UgKGUuZy4gMTggaG91cnMgZm9yIElTLUlT KS4NCgkgDQoJIA0KCSBGdXJ0aGVybW9yZSwgaWYgbW9zdCBvZiB0aGUgcm91dGVycyBpbiBhIGRv bWFpbiB3aWxsIGFsd2F5cyBoYXZlIG5vIHJlcXVlc3QgdG8gYSBQQ0UsIHRoZXJlIGlzIGFsc28g bm8gbmVlZCBmb3IgdGhlbSB0byBtYWludGFpbiB0aGUgaW5mb3JtYXRpb24uICANCgkgDQoJDQoJ SkxMUjogSW4gdGhpcyBjYXNlIFBDRSBkaXNjb3ZlcnkgaXMgZGVhY3RpdmF0ZWQgb24gdGhlc2Ug cm91dGVycyBhbmQgdGhleSB3aWxsIG5vdCBwcm9jZXNzIHRoZSBQQ0VEIGFuZCBQQ0VTIFRMVnMu Li4NCgkgDQoJIA0KCU15IGNvbmNlcm4gdG8gUENFLURFU1QtRE9NQUlOUyBzdWItVExWIGlzIHRo YXQgd2UgY2FuJ3QgYW50aWNpcGF0ZSBob3cgbWFueSBkZXN0aW5hdGlvbiBkb21haW5zIGEgUENF IGNhbiAgY29tcHV0YXRlIHBhdGggdG93YXJkcywgYXMgYSByZXN1bHQsdGhlIGxlbmd0aCBvZiBz cGFjZSB0YWtlbiBieSB0aGlzIGNhcGFsaXR5IGluIHRoZSBtZXNzYWdlIGNhbid0IGJlIGNvbnRy b2xsZWQuICANCgkgDQoJSkxMUjogQWN0dWFsbHkgeW91IGhhdmUgdGhlIHNhbWUgcHJvYmxlbSB3 aXRoIHRoZSBudW1iZXIgb2YgVEUtbGlua3MgYWR2ZXJ0aXNlZCBieSBhbiBMU1Igb3IgdGhlIG51 bWJlciBvZiByZWFjaGVhYmxlIHByZWZpeGVzIGFkdmVydGlzZWQgYnkgYW4gQUJSLiANCglPbmUg bWF5IGxpbWl0IGJ5IGNvbmZpZ3VyYXRpb24gdGhlIG51bWJlciBvZiBkZXN0IGRvbWFpbnMgYWR2 ZXJ0aXNlZC4NCgkgDQoJIA0KCSBTbyBJIHRoaW5rIGlmIHRoZSBQQ0Mgc2VuZCBhIHJlcXVlc3Qg dG8gYSBQQ0Ugd2hpY2ggY2FuJ3QgY29tcHV0ZSB0aGUgcGF0aCBmb3IgdGhlIHJlYXNvbiBvZiB0 aGUgZGVzdGluYXRpb24gZG9tYWluLCB0aGUgUENFIGNhbiB0ZWxsIHRoZSBQQ0MgaW4gdGhlIFBD cmVwIG1lc3NhZ2UgdGhlIHJpZ2h0IFBDRS4gIA0KCSANCglKTExSOiBCdXQgaG93IHRoZSBQQ0Ug d2lsbCBoYXZlIHRoZSBpbmZvcm1hdGlvbj8NCgkgDQoJIE9uZSBhZGRpdGlvbmFsIHF1ZXNpb246 IGlzIGl0IHN1aXRhYmxlIGZvciB0aGUgUENFIHRvIGhhdmUgc3VjaCBhYmlsaXR5IHRvIGtub3cg ZXhhY3RseSB0aGUgZGVzdGluYXRpb24gZG9tYWluIGl0IGNhbiBjb21wdXRlIHRvd2FyZHM/IA0K CSANCglKTExSOiBUaGlzIGlzIGFjdHVhbGx5IHJlcXVpcmVkLiBGb3IgaW5zdGFuY2UgaW4gYW4g aW50ZXItQVMgY2FzZSwgYW4gQVMgbWF5IGJlIGNvbm5lY3RlZCB0byBtdWx0aXBsZSBBU3MsIGFu ZCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgUENFcyBpbiB0aGlzIEFTIChlLmcuIEFTQlJzKSwgZWFj aCByZXNwb25zaWJsZSBmb3IgY29tcHV0aW5nIHBhdGggdG93YXJkcyBhIGdpdmVuIG5laWdoYm9y ZCBBUy4NCgkgDQoJU29tZSBmdW5jdGlvbnMgc3BlY2lmaWVkIGluIHRoZSBQQVRILUNBTVAtQ0FQ IHN1Yi1UTFYgYXJlIGFsc28gZGVmaW5lZCBpbiB0aGUgUENFUCwgIGEgY2xlYXIgZGl2aXNpb24g c2hvdWxkIGJlIG1hZGUuICANCgkgDQoJDQoJIEpMTFI6ICBBY3R1YWxseSwgYXQgdGhlIHRpbWUg YmVpbmcgdGhlIFBDRVAgc3BlYyBkb2VzIG5vdCBkZWZpbmUgYW55IGNhcGFiaWxpdHkgaW5mb3Jt YXRpb24uDQoJSW4gY3VycmVudCBQQ0VQIHNwZWMsIHdlIG9ubHkgbWVudGlvbiB0aGF0IGRldGFp bGVkIGNhcGFiaWxpdGVzIGNvdWxkIGJlIGNhcnJpZWQgaW4gb3B0aW9uYWwgc3ViLVRMVnMgb2Yg dGhlIE9wZW4gb2JqZWN0IChjYXJyaWVkIGluIHRoZSBPcGVuIG1lc3NhZ2UpLg0KCUJ1dCB5b3Ug YXJlIHJpZ2h0IHN1Y2ggY2FwYWJpbGl0eSBpbmZvcm1hdGlvbiBtYXkgYmUgY2FycmllZCBpbiBQ Q0VQLg0KCSANCglUaGUgaWRlYSB3b3VsZCBiZSB0byBjYXJyeSBzaW1wbGUgY2FwYWJpbGl0aWVz IGluIHRoZSBJR1AgYW5kIG1vcmUgY29tcGxleCBjYXBhYmlsaXRpZXMgaW4gUENFUC4NCgkgDQoJ QW55d2F5IEkgZG9uJ3QgcmVhbGx5IHNlZSBhbnkgaXNzdWUgaWYgd2UgZGVmaW5lIHR3byB3YXlz IHRvIGNhcnJ5IHNvbWUgcGllY2VzIG9mIGluZm9ybWF0aW9uOg0KCS1JR1AtYmFzZWQgY2FwYWJp bGl0eSBkaXNjb3ZlcnkgaXMgdXNlZnVsIGZvciBQQ0NzIHRoYXQgZG9uJ3QgaGF2ZSBhIFBDRVAg c2Vzc2lvbiB3aXRoIHRoZSBQQ0UuDQoJLVBDRVAtYmFzZWQgY2FwYWJpbGl0eSBkaXNjb3Zlcnkg aXMgdXNlZnVsIHdoZW4gSUdQIGJhc2VkIGRpc2NvdmVyeSBpcyBub3QgYWN0aXZhdGVkLiANCgkg DQoJVGhhbmtzIGZvciB0aGVzZSBjb21tZW50cywNCgkgDQoJUmVnYXJkcywNCgkgDQoJSkwgDQoJ IA0KCSANCgkgDQoJIA0KCUNoZWVycywNCgkgDQoJWmhhbmcgUmVuaGFpDQoNCg== ------_=_NextPart_001_01C69379.B50DDE8E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMjg3MyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBz aXplPTI+SGkgWmhhbmc8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xv cj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJp YWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGFua3MgZm9yIHlvdXIgY29tbWVudHM8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTc3MTky ODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNp emU9Mj5QbGVhc2Ugc2VlIGlubGluZSw8L0ZPTlQ+PC9TUEFOPjwvRElWPjxCUj4NCjxCTE9DS1FV T1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7 IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8 RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZnIgZGlyPWx0ciBhbGlnbj1sZWZ0 Pg0KICA8SFIgdGFiSW5kZXg9LTE+DQogIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5EZSZu YnNwOzo8L0I+IFpoYW5nIFJlbmhhaSANCiAgW21haWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29t XSA8QlI+PEI+RW52b3nDqSZuYnNwOzo8L0I+IG1hcmRpIDEzIGp1aW4gMjAwNiANCiAgMDk6MDc8 QlI+PEI+w4AmbmJzcDs6PC9CPiBwY2VAaWV0Zi5vcmc8QlI+PEI+T2JqZXQmbmJzcDs6PC9CPiBb UGNlXSBDb21tZW50cyBvbiANCiAgZHJhZnQtaWV0Zi1wY2UtZGlzY28tcHJvdG8taWdwPEJSPjwv Rk9OVD48QlI+PC9ESVY+DQogIDxESVY+PC9ESVY+DQogIDxESVY+DQogIDxESVY+PEZPTlQgZmFj ZT1Db3VyaWVyPkhpLCBhbGw8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVy IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPkkg cmVjZW50bHkgcmVhZCB0aGUgZHJhZnQgDQogIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWln cCBhZ2FpbiwgaGVyZSBhcmUgc29tZSBjb21tZW50c+OAgjwvRk9OVD48L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUNvdXJpZXI+PC9GT05UPjxGT05UIGZhY2U9Q291cmllcj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPldoZW4gSUdQIGlzIHVzZWQmbmJzcDth cyBhIFBDRUQgcHJvdG9jb2wsIHRoZSANCiAgY2FwYWJpbGl0aWVzIG9mIHBjZSB3aWxsIGJlIGFk dmVydGlzZWQgcGVyaW9kaWNseSBhbG9uZyB3aXRoIG90aGVyIGxzYS9sc3AgDQogIGluZm9ybWF0 aW9uLiBJbiBteSBvcGluaW9uLCB1bmxlc3MgdGhlIFBDRSdzIGNhcGFiaWxpdGllcyBjaGFuZ2Us Jm5ic3A7IHRoZXJlIA0KICBpcyBubyBuZWVkIGZvciB0aGUgUENDIHRvIHJlY2VpdmUgYW5kJm5i c3A7aGFuZGxlIHRoZSBpbmZvcm1hdGlvbiANCiAgYWdhaW4uJm5ic3A7PFNQQU4gY2xhc3M9NTc3 MTkyODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0y PiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTU3 NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5KTExS OiBCdXQgdGhlc2UgYXJlIHN0YW5kYXJkIElHUCBwcm9jZWR1cmVzLiBUaGlzIGlzIA0KICB0aGUg c2FtZSBmb3IgbGluayBzdGF0ZXMsIHRoZXkgYXJlIHJlZnJlc2hlZCBldmVuIGlmIHRoZXJlIGlz IG5vdCBjaGFuZ2UuIEJ5IA0KICB0aGUgd2F5IHRoZSByZWZyZXNoIGludGVydmFsIGNhbiBiZSBx dWl0ZSBsYXJnZSAoZS5nLiAxOCBob3VycyBmb3IgDQogIElTLUlTKS48L1NQQU4+PC9GT05UPjwv RElWPg0KICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BBTiANCiAgY2xhc3M9NTc3MTkyODA3 LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1D b3VyaWVyPjxTUEFOIA0KICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gDQogIGNsYXNzPTU3 NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDs8L1NQQU4+RnVydGhlcm1vcmUsIGlmIG1vc3Qgb2YgdGhl IHJvdXRlcnMgaW4gYSANCiAgZG9tYWluIHdpbGwgYWx3YXlzIGhhdmUgbm8gcmVxdWVzdCB0byBh IFBDRSwgdGhlcmUgaXMgYWxzbyBubyBuZWVkIGZvciB0aGVtIHRvIA0KICBtYWludGFpbiB0aGUg aW5mb3JtYXRpb24uJm5ic3A7PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAN CiAgc2l6ZT0yPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDs8L1NQQU4+PC9G T05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQogIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwv RElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g Y2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2Pg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5KTExSOiBJ biB0aGlzIGNhc2UgUENFIGRpc2NvdmVyeSBpcyBkZWFjdGl2YXRlZCBvbiANCiAgdGhlc2Ugcm91 dGVycyBhbmQgdGhleSB3aWxsIG5vdCBwcm9jZXNzIHRoZSBQQ0VEIGFuZCBQQ0VTIA0KICBUTFZz Li4uPC9TUEFOPjwvRk9OVD48L0RJVj48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTU3NzE5Mjgw Ny0xOTA2MjAwNj4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 Q291cmllcj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPk15 IGNvbmNlcm4gdG8gUENFLURFU1QtRE9NQUlOUyBzdWItVExWJm5ic3A7aXMgdGhhdCB3ZSANCiAg Y2FuJ3QgYW50aWNpcGF0ZSBob3cgbWFueSBkZXN0aW5hdGlvbiBkb21haW5zIGEgUENFIGNhbiAm bmJzcDtjb21wdXRhdGUgcGF0aCANCiAgdG93YXJkcywmbmJzcDthcyBhIHJlc3VsdCx0aGUgbGVu Z3RoIG9mIHNwYWNlIHRha2VuIGJ5IHRoaXMgY2FwYWxpdHkgaW4gdGhlIA0KICBtZXNzYWdlIGNh bid0IGJlIGNvbnRyb2xsZWQuJm5ic3A7PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxG T05UIA0KICBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQ QU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48 L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PkpMTFI6IEFjdHVhbGx5 IHlvdSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gd2l0aCB0aGUgDQogIG51bWJlciBvZiBURS1saW5r cyBhZHZlcnRpc2VkIGJ5Jm5ic3A7YW4gTFNSIG9yIHRoZSBudW1iZXIgb2YgcmVhY2hlYWJsZSAN CiAgcHJlZml4ZXMgYWR2ZXJ0aXNlZCBieSBhbiBBQlIuIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQog IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz01 NzcxOTI4MDctMTkwNjIwMDY+T25lIA0KICBtYXkgbGltaXQgYnkgY29uZmlndXJhdGlvbiB0aGUg bnVtYmVyIG9mIGRlc3QgZG9tYWlucyANCiAgYWR2ZXJ0aXNlZC48L1NQQU4+PC9GT05UPjwvRElW Pg0KICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BBTiANCiAgY2xhc3M9NTc3MTkyODA3LTE5 MDYyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Db3Vy aWVyPjxTUEFOIA0KICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJz cDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gY2xhc3M9NTc3MTkyODA3 LTE5MDYyMDA2PiZuYnNwOzwvU1BBTj5TbyBJIHRoaW5rIA0KICBpZiB0aGUgUENDIHNlbmQgYSBy ZXF1ZXN0IHRvIGEgUENFIHdoaWNoIGNhbid0IGNvbXB1dGUgdGhlIHBhdGggZm9yIHRoZSByZWFz b24gDQogIG9mIHRoZSBkZXN0aW5hdGlvbiBkb21haW4sIHRoZSBQQ0UgY2FuIHRlbGwgdGhlIFBD QyBpbiB0aGUgUENyZXAgDQogIG1lc3NhZ2UmbmJzcDt0aGUgcmlnaHQgUENFLiZuYnNwOzxTUEFO IGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCANCiAgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9O VD48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0K ICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+SkxMUjogQnV0IGhvdyB0aGUgUENFIHdpbGwgaGF2 ZSB0aGUgDQogIGluZm9ybWF0aW9uPzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg ZmFjZT1Db3VyaWVyPjxTUEFOIA0KICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gY2xhc3M9 NTc3MTkyODA3LTE5MDYyMDA2PiZuYnNwOzwvU1BBTj5PbmUgDQogIGFkZGl0aW9uYWwgcXVlc2lv bjogaXMgaXQgc3VpdGFibGUgZm9yIHRoZSBQQ0UgdG8gaGF2ZSBzdWNoIGFiaWxpdHkgdG8ga25v dyANCiAgZXhhY3RseSB0aGUgZGVzdGluYXRpb24gZG9tYWluIGl0IGNhbiBjb21wdXRlIHRvd2Fy ZHM/PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFO IGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8 RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNz PTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTU3NzE5 MjgwNy0xOTA2MjAwNj5KTExSOiBUaGlzIGlzIGFjdHVhbGx5Jm5ic3A7cmVxdWlyZWQuIEZvciBp bnN0YW5jZSBpbiANCiAgYW4gaW50ZXItQVMgY2FzZSwgYW4gQVMgbWF5IGJlIGNvbm5lY3RlZCB0 byBtdWx0aXBsZSBBU3MsIGFuZCZuYnNwO3RoZXJlIG1heSANCiAgYmUgbXVsdGlwbGUgUENFcyBp biB0aGlzIEFTIChlLmcuIEFTQlJzKSwgZWFjaCByZXNwb25zaWJsZSBmb3IgY29tcHV0aW5nIHBh dGggDQogIHRvd2FyZHMgYSBnaXZlbiBuZWlnaGJvcmQgQVMuPC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxG T05UIGZhY2U9Q291cmllcj5Tb21lIGZ1bmN0aW9ucyBzcGVjaWZpZWQgaW4gdGhlIFBBVEgtQ0FN UC1DQVAgc3ViLVRMViANCiAgYXJlIGFsc28mbmJzcDtkZWZpbmVkJm5ic3A7aW4gdGhlIFBDRVAs Jm5ic3A7IGEgY2xlYXIgZGl2aXNpb24gc2hvdWxkIGJlIA0KICBtYWRlLiZuYnNwOzwvRk9OVD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz01Nzcx OTI4MDctMTkwNjIwMDY+Jm5ic3A7PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz01NzcxOTI4MDct MTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVD48U1BBTiBj bGFzcz01NzcxOTI4MDctMTkwNjIwMDY+DQogIDxESVY+PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAy MDYyMDA2PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCiAgc2l6 ZT0yPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDtKTExSOiAmbmJzcDs8L1NQ QU4+QWN0dWFsbHksIGF0IA0KICB0aGUgdGltZSBiZWluZyB0aGUgUENFUCBzcGVjIGRvZXMgbm90 IGRlZmluZSBhbnkgY2FwYWJpbGl0eSANCiAgaW5mb3JtYXRpb24uPC9GT05UPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBz aXplPTI+PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PkluIA0KICBjdXJyZW50IFBDRVAg c3BlYywgd2Ugb25seSBtZW50aW9uIHRoYXQgZGV0YWlsZWQgY2FwYWJpbGl0ZXMgY291bGQgYmUg Y2FycmllZCANCiAgaW4gb3B0aW9uYWwgc3ViLVRMVnMgb2YgdGhlIE9wZW4gb2JqZWN0IChjYXJy aWVkIGluIHRoZSBPcGVuIA0KICBtZXNzYWdlKS48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9NTM4NDQ0 MzE2LTAyMDYyMDA2PkJ1dCANCiAgeW91IGFyZSByaWdodCBzdWNoIGNhcGFiaWxpdHkgaW5mb3Jt YXRpb24gbWF5IGJlIGNhcnJpZWQgaW4gDQogIFBDRVAuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz01Mzg0NDQzMTYtMDIwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTUzODQ0NDMx Ni0wMjA2MjAwNj5UaGUgDQogIGlkZWEmbmJzcDt3b3VsZCBiZSZuYnNwO3RvIGNhcnJ5Jm5ic3A7 c2ltcGxlIGNhcGFiaWxpdGllcyZuYnNwO2luIHRoZSBJR1AgDQogIGFuZCZuYnNwO21vcmUgY29t cGxleCBjYXBhYmlsaXRpZXMgaW4gUENFUC48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTUzODQ0 NDMxNi0wMjA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZh Y2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQQU4gDQogIGNsYXNz PTUzODQ0NDMxNi0wMjA2MjAwNj5Bbnl3YXkgSSBkb24ndCByZWFsbHkgc2VlIGFueSBpc3N1ZSBp PC9TUEFOPjxTUEFOIA0KICBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+ZiB3ZSBkZWZpbmUgdHdv IHdheXMgdG8mbmJzcDtjYXJyeSZuYnNwO3NvbWUgcGllY2VzIA0KICBvZiBpbmZvcm1hdGlvbjo8 L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2 Pi1JR1AtYmFzZWQgY2FwYWJpbGl0eSBkaXNjb3ZlcnkgaXMgdXNlZnVsIGZvciBQQ0NzIA0KICB0 aGF0IGRvbid0IGhhdmUgYSBQQ0VQIHNlc3Npb24gd2l0aCB0aGUgUENFLjwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PjxGT05UIGZhY2U9 QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCiAgc2l6ZT0yPi1QQ0VQLWJhc2VkIGNh cGFiaWxpdHkgZGlzY292ZXJ5IGlzIHVzZWZ1bCB3aGVuIElHUCBiYXNlZCBkaXNjb3ZlcnkgaXMg DQogIG5vdCBhY3RpdmF0ZWQuPFNQQU4gDQogIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJz cDs8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFO IGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMw MDAwZmY+PEZPTlQgDQogIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2 PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+ PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29s b3I9IzAwMDBmZj48Rk9OVCANCiAgc2l6ZT0yPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAw Nj5UaGFua3MgZm9yIHRoZXNlIA0KICBjb21tZW50cyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48 Rk9OVCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQogIHNpemU9Mj48U1BB TiANCiAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAyMDYy MDA2PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCANCiAgc2l6ZT0y PjxTUEFOIA0KICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+UmVnYXJkcyw8L1NQQU4+PC9GT05U PjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTUzODQ0NDMx Ni0wMjA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQog IHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+ PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVY+PFNQQU4gY2xhc3M9NTM4 NDQ0MzE2LTAyMDYyMDA2PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9O VCANCiAgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+SkwmbmJzcDs8 L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTUzODQ0NDMxNi0w MjA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAw Nj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxG T05UIGZhY2U9Q291cmllcj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1D b3VyaWVyPkNoZWVycyw8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+WmhhbmcgDQpSZW5o YWk8L0ZPTlQ+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C69379.B50DDE8E-- --===============1510691689== 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 --===============1510691689==-- From pce-bounces@lists.ietf.org Mon Jun 19 20:10:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTpX-0004DU-Gg; Mon, 19 Jun 2006 20:10:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTpV-0004DP-RI for pce@ietf.org; Mon, 19 Jun 2006 20:10:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTpT-0005h5-HP for pce@ietf.org; Mon, 19 Jun 2006 20:10:53 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2006 17:10:50 -0700 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 k5K0Anno000458; Mon, 19 Jun 2006 20:10:49 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 20:10:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 20:10:45 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D33201988D45@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-bradford-pce-path-key-00.txt Thread-Index: AcaSBrUNrKKQobJoTnmZ+2p7TDxIPABm6AjA From: "Rich Bradford \(rbradfor\)" To: X-OriginalArrivalTime: 20 Jun 2006 00:10:48.0973 (UTC) FILETIME=[FBF42BD0:01C693FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: bae22017ea94d808e6875b7fc764857f Cc: Subject: [Pce] FW: I-D ACTION:draft-bradford-pce-path-key-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1662809804==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1662809804== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C693FD.FBAC0188" This is a multi-part message in MIME format. ------_=_NextPart_001_01C693FD.FBAC0188 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG members, Thanks to all on the excellent suggestions about draft-rbradfor-ccamp-confidential-segment-00.txt. We've uploaded a streamlined successor which describes just the use of Path Keys (to replace the confidential path segments in the EROs returned by a PCE and used for lsp setup). The changes include: - This version focuses exclusively on the use of a Path Key in the ERO rather using of encryption on segments of the ERO.=20 - Switched this to pce from ccamp since the Path Key solution has more impact on this wg. - The mechanics of using Path Keys has been clarified. - Section 4 includes a description of handling multiple PKSs in the same ERO. - An issue was identified regarding Path Key reuse. - The security section was expanded. =20 =20 The new draft can be found at: http://www.ietf.org/internet-drafts/draft-bradford-pce-path-key-00.txt =20 Comments welcomed, Rich =20 =20 =20 Begin forwarded message: =20 =20 From: Internet-Drafts@ietf.org Date: June 16, 2006 6:50:01 PM EDT To: i-d-announce@ietf.org Subject: I-D ACTION:draft-bradford-pce-path-key-00.txt=20 Reply-To: internet-drafts@ietf.org =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 =20 Title : Preserving Topology Confidentiality in Inter-Domain Path Computation and Signaling=20 Author(s) : R. Bradford, et al. Filename : draft-bradford-pce-path-key-00.txt Pages :=20 Date : 2006-6-16 =20 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)=20 Label Switched Paths (LSPs) may be computed by Path Computation=20 Elements (PCEs). Where the TE LSP crosses multiple domains, such=20 as Autonomous Systems (ASs), the path may be computed by multiple=20 PCEs that cooperate, with each responsible for computing a segment=20 of the path.=20 =20 However, in some cases such as when ASs are administered by=20 separate Service Providers, it would break confidentiality rules=20 for a PCE to supply a path segment to a PCE in another domain,=20 thus disclosing internal topology information. This issue may be=20 circumvented by returning a loose hop and by invoking a new path=20 computation from the domain boundary LSR during TE LSP setup as=20 the LSP enters the second domain, but this technique has several=20 issues including the problem of maintaining path diversity.=20 =20 This document defines a mechanism to hide the contents of a=20 segment of a path, called the Confidential Path Segment (CPS). The=20 CPS may be replaced by a Path Key that can be conveyed in the PCE=20 Communication Protocol (PCEP) and signaled within in a Resource=20 Reservation Protocol (RSVP) explicit route object.=20 =20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bradford-pce-path-key-00.txt =20 To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. =20 =20 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-bradford-pce-path-key-00.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bradford-pce-path-key-00.txt". =20 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. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2006-6-16151809.I-D@ietf.org> =20 _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce =20 ------_=_NextPart_001_01C693FD.FBAC0188 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG members,

Thanks to all on the excellent suggestions about = draft-rbradfor-ccamp-confidential-segment-00.txt. We’ve uploaded a streamlined successor which describes just the = use of Path Keys (to replace the confidential path segments in the EROs = returned by a PCE and used for lsp setup).

The changes include:

-          This version focuses = exclusively on the use of a Path Key in the ERO rather using of encryption on = segments of the ERO.

-          Switched this to pce from = ccamp since the Path Key solution has more impact on this wg.

-          The mechanics of using Path = Keys has been clarified.

-          Section 4 includes a = description of handling multiple PKSs in the same ERO.

-          An issue was identified = regarding Path Key reuse.

-          The security section was = expanded.

 

 

  The new draft can be found = at:

http://www.ietf.org/internet-drafts/draft-bradford-pce-path-key-0= 0.txt

 

Comments = welcomed,

  Rich

 

 

 

Begin forwarded message:

 

 

From: Internet-Drafts@ietf.org

Date: June 16, 2006 6:50:01 PM EDT

To: i-d-announce@ietf.org

Subject: I-D = ACTION:draft-bradford-pce-path-key-00.txt <= /p>

Reply-To: internet-drafts@ietf.org

 

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

 

 

     = Title         : Preserving Topology Confidentiality in Inter-Domain Path Computation = and Signaling 

     Author(s) : R. Bradford, et = al.

     Filename  : draft-bradford-pce-path-key-00.txt

     = Pages         : 

     Date      : = 2006-6-16

    

   Multiprotocol Label Switching (MPLS) Traffic = Engineering (TE) 

   Label Switched Paths (LSPs) may be computed by Path Computation 

   Elements (PCEs). Where the TE LSP crosses multiple domains, such 

   as Autonomous Systems (ASs), the path may be = computed by multiple 

   PCEs that cooperate, with each responsible for = computing a segment 

   of the path. 

 

   However, in some cases such as when ASs are = administered by 

   separate Service Providers, it would break = confidentiality rules 

   for a PCE to supply a path segment to a PCE in = another domain, 

   thus disclosing internal topology information. This = issue may be 

   circumvented by returning a loose hop and by = invoking a new path 

   computation from the domain boundary LSR during TE = LSP setup as 

   the LSP enters the second domain, but this = technique has several 

   issues including the problem of maintaining path diversity. 

 

   This document defines a mechanism to hide the = contents of a 

   segment of a path, called the Confidential Path = Segment (CPS). The 

   CPS may be replaced by a Path Key that can be = conveyed in the PCE 

   Communication Protocol (PCEP) and signaled within = in a Resource 

   Reservation Protocol (RSVP) explicit route = object. 

 

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-bradford-pce-path-key-0= 0.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-bradford-pce-path-key-00.txt".

 

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

http://www.ietf.org/shadow.html 

or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

 

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

 

Send a message to:

     = mailserv@ietf.org.

In the body type:

     "FILE /internet-drafts/draft-bradford-pce-path-key-00.txt".

    

NOTE:     The mail server at ietf.org can = return the document in

     MIME-encoded form by using the "mpack" utility.  To use = this

     feature, insert the command = "ENCODING mime" before the "FILE"

     command.  To decode the = response(s), you will need "munpack" or

     a MIME-compliant mail reader.  = Different MIME-compliant mail readers

     exhibit different behavior, especially = when dealing with

     "multipart" MIME messages = (i.e. documents which have been split

     up into multiple messages), so check = your local documentation on

     how to manipulate these = messages.

          =

          =

Below is the data which will enable a MIME compliant mail = reader

implementation to automatically retrieve the ASCII version of = the

Internet-Draft.

Content-Type: text/plain

Content-ID: = <2006-6-16151809.I-D@ietf.org>

 

_______________________________________________=

I-D-Announce mailing list

I-D-Announce@ietf.org

https://www1.ietf.org/mailman/listinfo/i-d-announce

 

------_=_NextPart_001_01C693FD.FBAC0188-- --===============1662809804== 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 --===============1662809804==-- From pce-bounces@lists.ietf.org Mon Jun 19 23:57:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsXNC-0008IO-7Q; Mon, 19 Jun 2006 23:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsXNB-0008Ho-8g for pce@ietf.org; Mon, 19 Jun 2006 23:57:53 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsXN9-0001s8-QG for pce@ietf.org; Mon, 19 Jun 2006 23:57:53 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J15009PR4ATXO@szxga01-in.huawei.com> for pce@ietf.org; Tue, 20 Jun 2006 11:56:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500EFE4ASB0@szxga01-in.huawei.com> for pce@ietf.org; Tue, 20 Jun 2006 11:56:53 +0800 (CST) Received: from z18605 ([10.110.114.156]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1500BJO4PW8R@szxml04-in.huawei.com> for pce@ietf.org; Tue, 20 Jun 2006 12:05:56 +0800 (CST) Date: Tue, 20 Jun 2006 11:25:38 +0800 From: Zhang Renhai Subject: Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp To: LE ROUX Jean-Louis RD-CORE-LAN , pce@ietf.org Message-id: <003101c69419$33e55a80$9c726e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf 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="===============1780123884==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1780123884== Content-type: multipart/alternative; boundary="Boundary_(ID_AKMsui3FgTWMdDydEYg/Yg)" This is a multi-part message in MIME format. --Boundary_(ID_AKMsui3FgTWMdDydEYg/Yg) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 SGksIEplYW4tTG91aXMNCg0KU2VlIGlubGluZSwgcGxlYXNlLg0KICAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4gDQog IFRvOiBaaGFuZyBSZW5oYWkgOyBwY2VAaWV0Zi5vcmcgDQogIFNlbnQ6IE1vbmRheSwgSnVuZSAx OSwgMjAwNiA0OjIzIFBNDQogIFN1YmplY3Q6IFJFOiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1p ZXRmLXBjZS1kaXNjby1wcm90by1pZ3ANCg0KDQogIEhpIFpoYW5nDQoNCiAgVGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzDQoNCiAgUGxlYXNlIHNlZSBpbmxpbmUsDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICAgRGUgOiBaaGFuZyBSZW5oYWkgW21haWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWku Y29tXSANCiAgICBFbnZvecOpIDogbWFyZGkgMTMganVpbiAyMDA2IDA5OjA3DQogICAgw4AgOiBw Y2VAaWV0Zi5vcmcNCiAgICBPYmpldCA6IFtQY2VdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNl LWRpc2NvLXByb3RvLWlncA0KDQoNCiAgICBIaSwgYWxsDQoNCiAgICBJIHJlY2VudGx5IHJlYWQg dGhlIGRyYWZ0IGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncCBhZ2FpbiwgaGVyZSBhcmUg c29tZSBjb21tZW50c+OAgg0KDQogICAgV2hlbiBJR1AgaXMgdXNlZCBhcyBhIFBDRUQgcHJvdG9j b2wsIHRoZSBjYXBhYmlsaXRpZXMgb2YgcGNlIHdpbGwgYmUgYWR2ZXJ0aXNlZCBwZXJpb2RpY2x5 IGFsb25nIHdpdGggb3RoZXIgbHNhL2xzcCBpbmZvcm1hdGlvbi4gSW4gbXkgb3BpbmlvbiwgdW5s ZXNzIHRoZSBQQ0UncyBjYXBhYmlsaXRpZXMgY2hhbmdlLCAgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig dGhlIFBDQyB0byByZWNlaXZlIGFuZCBoYW5kbGUgdGhlIGluZm9ybWF0aW9uIGFnYWluLiAgDQoN CiAgICBKTExSOiBCdXQgdGhlc2UgYXJlIHN0YW5kYXJkIElHUCBwcm9jZWR1cmVzLiBUaGlzIGlz IHRoZSBzYW1lIGZvciBsaW5rIHN0YXRlcywgdGhleSBhcmUgcmVmcmVzaGVkIGV2ZW4gaWYgdGhl cmUgaXMgbm90IGNoYW5nZS4gQnkgdGhlIHdheSB0aGUgcmVmcmVzaCBpbnRlcnZhbCBjYW4gYmUg cXVpdGUgbGFyZ2UgKGUuZy4gMTggaG91cnMgZm9yIElTLUlTKS4NCg0KDQoNCiAgICAgRnVydGhl cm1vcmUsIGlmIG1vc3Qgb2YgdGhlIHJvdXRlcnMgaW4gYSBkb21haW4gd2lsbCBhbHdheXMgaGF2 ZSBubyByZXF1ZXN0IHRvIGEgUENFLCB0aGVyZSBpcyBhbHNvIG5vIG5lZWQgZm9yIHRoZW0gdG8g bWFpbnRhaW4gdGhlIGluZm9ybWF0aW9uLiAgDQoNCiAgICBKTExSOiBJbiB0aGlzIGNhc2UgUENF IGRpc2NvdmVyeSBpcyBkZWFjdGl2YXRlZCBvbiB0aGVzZSByb3V0ZXJzIGFuZCB0aGV5IHdpbGwg bm90IHByb2Nlc3MgdGhlIFBDRUQgYW5kIFBDRVMgVExWcy4uLg0KQnV0IEkgZG9uJ3Qga25vdyBp ZiBpdCBpcyBwb3NzaWJsZSBmb3IgYSByb3V0ZXIgdG8gYmUgcmUtY29uZmlndXJlZCBhcyBhIFBD QyBvciBoYXZlIHNvbWUgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0IGFmdGVyIGl0IHJlY2VpdmVz IHRoZXNlIFRMVnMgYW5kIG5vdCBwcm9jZXNzZXMgdGhlbSwgDQoNCg0KICAgIE15IGNvbmNlcm4g dG8gUENFLURFU1QtRE9NQUlOUyBzdWItVExWIGlzIHRoYXQgd2UgY2FuJ3QgYW50aWNpcGF0ZSBo b3cgbWFueSBkZXN0aW5hdGlvbiBkb21haW5zIGEgUENFIGNhbiAgY29tcHV0YXRlIHBhdGggdG93 YXJkcywgYXMgYSByZXN1bHQsdGhlIGxlbmd0aCBvZiBzcGFjZSB0YWtlbiBieSB0aGlzIGNhcGFs aXR5IGluIHRoZSBtZXNzYWdlIGNhbid0IGJlIGNvbnRyb2xsZWQuICANCg0KICAgIEpMTFI6IEFj dHVhbGx5IHlvdSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gd2l0aCB0aGUgbnVtYmVyIG9mIFRFLWxp bmtzIGFkdmVydGlzZWQgYnkgYW4gTFNSIG9yIHRoZSBudW1iZXIgb2YgcmVhY2hlYWJsZSBwcmVm aXhlcyBhZHZlcnRpc2VkIGJ5IGFuIEFCUi4gDQogICAgT25lIG1heSBsaW1pdCBieSBjb25maWd1 cmF0aW9uIHRoZSBudW1iZXIgb2YgZGVzdCBkb21haW5zIGFkdmVydGlzZWQuDQpCdXQgSSBzdGls bCBkb3VidCB0aGF0IGlmIGl0J3MgbmVlZGVkIGZvciB0aGUgUENFIHRvIG1haW50YWluIHN1Y2gg aW5mb3JtYXRpb24gYW5kIGhvdyBhIFBDRSBvYnRhaW5zIHRoZXNlIGluZm8/DQoNCg0KICAgICBT byBJIHRoaW5rIGlmIHRoZSBQQ0Mgc2VuZCBhIHJlcXVlc3QgdG8gYSBQQ0Ugd2hpY2ggY2FuJ3Qg Y29tcHV0ZSB0aGUgcGF0aCBmb3IgdGhlIHJlYXNvbiBvZiB0aGUgZGVzdGluYXRpb24gZG9tYWlu LCB0aGUgUENFIGNhbiB0ZWxsIHRoZSBQQ0MgaW4gdGhlIFBDcmVwIG1lc3NhZ2UgdGhlIHJpZ2h0 IFBDRS4gIA0KDQogICAgSkxMUjogQnV0IGhvdyB0aGUgUENFIHdpbGwgaGF2ZSB0aGUgaW5mb3Jt YXRpb24/DQoNCiAgICAgT25lIGFkZGl0aW9uYWwgcXVlc2lvbjogaXMgaXQgc3VpdGFibGUgZm9y IHRoZSBQQ0UgdG8gaGF2ZSBzdWNoIGFiaWxpdHkgdG8ga25vdyBleGFjdGx5IHRoZSBkZXN0aW5h dGlvbiBkb21haW4gaXQgY2FuIGNvbXB1dGUgdG93YXJkcz8gDQoNCiAgICBKTExSOiBUaGlzIGlz IGFjdHVhbGx5IHJlcXVpcmVkLiBGb3IgaW5zdGFuY2UgaW4gYW4gaW50ZXItQVMgY2FzZSwgYW4g QVMgbWF5IGJlIGNvbm5lY3RlZCB0byBtdWx0aXBsZSBBU3MsIGFuZCB0aGVyZSBtYXkgYmUgbXVs dGlwbGUgUENFcyBpbiB0aGlzIEFTIChlLmcuIEFTQlJzKSwgZWFjaCByZXNwb25zaWJsZSBmb3Ig Y29tcHV0aW5nIHBhdGggdG93YXJkcyBhIGdpdmVuIG5laWdoYm9yZCBBUy4NCkhlcmUgeW91IHNh aWQgdGhlIG5laWdoYm9yaW5nIEFTLCBidXQgbm90IHRoZSBkZXN0aW5hdGlvbiBBUy4NCg0KICAg IFNvbWUgZnVuY3Rpb25zIHNwZWNpZmllZCBpbiB0aGUgUEFUSC1DQU1QLUNBUCBzdWItVExWIGFy ZSBhbHNvIGRlZmluZWQgaW4gdGhlIFBDRVAsICBhIGNsZWFyIGRpdmlzaW9uIHNob3VsZCBiZSBt YWRlLiAgDQoNCiAgICAgSkxMUjogIEFjdHVhbGx5LCBhdCB0aGUgdGltZSBiZWluZyB0aGUgUENF UCBzcGVjIGRvZXMgbm90IGRlZmluZSBhbnkgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbi4NCiAgICBJ biBjdXJyZW50IFBDRVAgc3BlYywgd2Ugb25seSBtZW50aW9uIHRoYXQgZGV0YWlsZWQgY2FwYWJp bGl0ZXMgY291bGQgYmUgY2FycmllZCBpbiBvcHRpb25hbCBzdWItVExWcyBvZiB0aGUgT3BlbiBv YmplY3QgKGNhcnJpZWQgaW4gdGhlIE9wZW4gbWVzc2FnZSkuDQogICAgQnV0IHlvdSBhcmUgcmln aHQgc3VjaCBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIG1heSBiZSBjYXJyaWVkIGluIFBDRVAuDQoN CiAgICBUaGUgaWRlYSB3b3VsZCBiZSB0byBjYXJyeSBzaW1wbGUgY2FwYWJpbGl0aWVzIGluIHRo ZSBJR1AgYW5kIG1vcmUgY29tcGxleCBjYXBhYmlsaXRpZXMgaW4gUENFUC4NCg0KICAgIEFueXdh eSBJIGRvbid0IHJlYWxseSBzZWUgYW55IGlzc3VlIGlmIHdlIGRlZmluZSB0d28gd2F5cyB0byBj YXJyeSBzb21lIHBpZWNlcyBvZiBpbmZvcm1hdGlvbjoNCiAgICAtSUdQLWJhc2VkIGNhcGFiaWxp dHkgZGlzY292ZXJ5IGlzIHVzZWZ1bCBmb3IgUENDcyB0aGF0IGRvbid0IGhhdmUgYSBQQ0VQIHNl c3Npb24gd2l0aCB0aGUgUENFLg0KICAgIC1QQ0VQLWJhc2VkIGNhcGFiaWxpdHkgZGlzY292ZXJ5 IGlzIHVzZWZ1bCB3aGVuIElHUCBiYXNlZCBkaXNjb3ZlcnkgaXMgbm90IGFjdGl2YXRlZC4gDQpU aGlzIHNvdW5kcyBmaW5lIHRvIG1lLg0KDQpSZWdhcmRzLA0KWmhhbmcgDQoNCg0KICAgIFRoYW5r cyBmb3IgdGhlc2UgY29tbWVudHMsDQoNCiAgICBSZWdhcmRzLA0KDQogICAgSkwgDQoNCg0KICAg ICANCg0KICAgIENoZWVycywNCg0KICAgIFpoYW5nIFJlbmhhaQ0K --Boundary_(ID_AKMsui3FgTWMdDydEYg/Yg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjUw LjQ4MDcuMjMwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPkhpLCBK ZWFuLUxvdWlzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+U2VlIGlubGlu ZSwgcGxlYXNlLjwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFE RElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9S REVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9E SVY+DQogIDxESVYgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCDlrovkvZM7 IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWplYW5sb3Vpcy5s ZXJvdXhAb3JhbmdlLWZ0LmNvbSANCiAgaHJlZj0ibWFpbHRvOmplYW5sb3Vpcy5sZXJvdXhAb3Jh bmdlLWZ0LmNvbSI+TEUgUk9VWCBKZWFuLUxvdWlzIA0KICBSRC1DT1JFLUxBTjwvQT4gPC9ESVY+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlRvOjwvQj4gPEEgdGl0bGU9emhh bmdyZW5oYWlAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOnpoYW5ncmVuaGFpQGh1YXdlaS5j b20iPlpoYW5nIFJlbmhhaTwvQT4gOyA8QSB0aXRsZT1wY2VAaWV0Zi5vcmcgDQogIGhyZWY9Im1h aWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlNlbnQ6PC9CPiBNb25kYXksIEp1bmUgMTksIDIwMDYgNDoy MyBQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0Ojwv Qj4gUkU6IFtQY2VdIENvbW1lbnRzIG9uIA0KICBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1p Z3A8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0j MDAwMGZmIHNpemU9Mj5IaSBaaGFuZzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFy aWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K ICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+ PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+VGhhbmtzIGZvciB5b3Vy IGNvbW1lbnRzPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFy aWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5QbGVhc2Ugc2VlIGlubGluZSw8L0ZPTlQ+PC9T UEFOPjwvRElWPjxCUj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJTkct TEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29s aWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVh ZGVyIGxhbmc9ZnIgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICAgIDxIUiB0YWJJbmRleD0tMT4NCiAg ICA8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RGUmbmJzcDs6PC9CPiBaaGFuZyBSZW5oYWkg DQogICAgW21haWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29tXSA8QlI+PEI+RW52b3nDqSZuYnNw Ozo8L0I+IG1hcmRpIDEzIGp1aW4gMjAwNiANCiAgICAwOTowNzxCUj48Qj7DgCZuYnNwOzo8L0I+ IDxBIA0KICAgIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvQT48QlI+ PEI+T2JqZXQmbmJzcDs6PC9CPiBbUGNlXSANCiAgICBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBj ZS1kaXNjby1wcm90by1pZ3A8QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgICA8RElWPjwvRElWPg0K ICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPkhpLCBhbGw8L0ZPTlQ+PC9ESVY+DQogICAgPERJ Vj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElW PjxGT05UIGZhY2U9Q291cmllcj5JIHJlY2VudGx5IHJlYWQgdGhlIGRyYWZ0IA0KICAgIGRyYWZ0 LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncCBhZ2FpbiwgaGVyZSBhcmUgc29tZSBjb21tZW50c+OA gjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48L0ZPTlQ+PEZPTlQg ZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291 cmllcj5XaGVuIElHUCBpcyB1c2VkJm5ic3A7YXMgYSBQQ0VEIHByb3RvY29sLCB0aGUgDQogICAg Y2FwYWJpbGl0aWVzIG9mIHBjZSB3aWxsIGJlIGFkdmVydGlzZWQgcGVyaW9kaWNseSBhbG9uZyB3 aXRoIG90aGVyIGxzYS9sc3AgDQogICAgaW5mb3JtYXRpb24uIEluIG15IG9waW5pb24sIHVubGVz cyB0aGUgUENFJ3MgY2FwYWJpbGl0aWVzIGNoYW5nZSwmbmJzcDsgDQogICAgdGhlcmUgaXMgbm8g bmVlZCBmb3IgdGhlIFBDQyB0byByZWNlaXZlIGFuZCZuYnNwO2hhbmRsZSB0aGUgaW5mb3JtYXRp b24gDQogICAgYWdhaW4uJm5ic3A7PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgICBzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgIHNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48U1BBTiANCiAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+SkxMUjogQnV0IHRoZXNl IGFyZSBzdGFuZGFyZCBJR1AgcHJvY2VkdXJlcy4gVGhpcyANCiAgICBpcyB0aGUgc2FtZSBmb3Ig bGluayBzdGF0ZXMsIHRoZXkgYXJlIHJlZnJlc2hlZCBldmVuIGlmIHRoZXJlIGlzIG5vdCBjaGFu Z2UuIA0KICAgIEJ5IHRoZSB3YXkgdGhlIHJlZnJlc2ggaW50ZXJ2YWwgY2FuIGJlIHF1aXRlIGxh cmdlIChlLmcuIDE4IGhvdXJzIGZvciANCiAgICBJUy1JUykuPC9TUEFOPjwvRk9OVD48L0RJVj4N CiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQog ICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQog ICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gDQogICAgY2xhc3M9NTc3MTkyODA3LTE5 MDYyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUNv dXJpZXI+PFNQQU4gDQogICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gDQogICAgY2xh c3M9NTc3MTkyODA3LTE5MDYyMDA2PiZuYnNwOzwvU1BBTj5GdXJ0aGVybW9yZSwgaWYgbW9zdCBv ZiB0aGUgcm91dGVycyBpbiANCiAgICBhIGRvbWFpbiB3aWxsIGFsd2F5cyBoYXZlIG5vIHJlcXVl c3QgdG8gYSBQQ0UsIHRoZXJlIGlzIGFsc28gbm8gbmVlZCBmb3IgDQogICAgdGhlbSB0byBtYWlu dGFpbiB0aGUgaW5mb3JtYXRpb24uJm5ic3A7PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiANCiAgICBzaXplPTI+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PiZuYnNw OzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+ PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+DQogICAgPERJVj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTU3NzE5 MjgwNy0xOTA2MjAwNj5KTExSOiBJbiB0aGlzIGNhc2UgUENFIGRpc2NvdmVyeSBpcyBkZWFjdGl2 YXRlZCBvbiANCiAgICB0aGVzZSByb3V0ZXJzIGFuZCB0aGV5IHdpbGwgbm90IHByb2Nlc3MgdGhl IFBDRUQgYW5kIFBDRVMgDQogICAgVExWcy4uLjwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9C TE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCjxESVYgZGlyPWx0cj48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05U IGNvbG9yPSMwMDAwMDA+QnV0IEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBwb3NzaWJsZSANCmZvciBh IHJvdXRlciB0byBiZSByZS1jb25maWd1cmVkJm5ic3A7YXMgYSBQQ0Mgb3IgaGF2ZSBzb21lJm5i c3A7cGF0aCANCmNvbXB1dGF0aW9uIHJlcXVlc3QmbmJzcDthZnRlciZuYnNwO2l0IHJlY2VpdmVz IHRoZXNlIFRMVnMgYW5kIG5vdCBwcm9jZXNzZXMgDQp0aGVtLDwvRk9OVD4gPC9TUEFOPjwvRk9O VD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4 OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAw MDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxCTE9DS1FVT1RFIGRpcj1sdHIg DQogIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxF RlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgPERJVj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTU3NzE5 MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQog ICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+ PEZPTlQgZmFjZT1Db3VyaWVyPk15IGNvbmNlcm4gdG8gUENFLURFU1QtRE9NQUlOUyBzdWItVExW Jm5ic3A7aXMgdGhhdCANCiAgICB3ZSBjYW4ndCBhbnRpY2lwYXRlIGhvdyBtYW55IGRlc3RpbmF0 aW9uIGRvbWFpbnMgYSBQQ0UgY2FuICZuYnNwO2NvbXB1dGF0ZSANCiAgICBwYXRoIHRvd2FyZHMs Jm5ic3A7YXMgYSByZXN1bHQsdGhlIGxlbmd0aCBvZiBzcGFjZSB0YWtlbiBieSB0aGlzIGNhcGFs aXR5IGluIA0KICAgIHRoZSBtZXNzYWdlIGNhbid0IGJlIGNvbnRyb2xsZWQuJm5ic3A7PFNQQU4g Y2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIA0KICAgIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiBzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48 U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PEZPTlQgZmFjZT3lrovkvZMgDQogICAgc2l6 ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAw Nj5KTExSOiBBY3R1YWxseSB5b3UgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtIHdpdGggdGhlIA0KICAg IG51bWJlciBvZiBURS1saW5rcyBhZHZlcnRpc2VkIGJ5Jm5ic3A7YW4gTFNSIG9yIHRoZSBudW1i ZXIgb2YgcmVhY2hlYWJsZSANCiAgICBwcmVmaXhlcyBhZHZlcnRpc2VkIGJ5IGFuIEFCUi4gPC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiBzaXplPTI+PFNQQU4gDQogICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2Pk9uZSBtYXkgbGlt aXQgYnkgY29uZmlndXJhdGlvbiB0aGUgbnVtYmVyIG9mIGRlc3QgDQogICAgZG9tYWlucyBhZHZl cnRpc2VkLjwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCjxE SVYgZGlyPWx0cj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NzcxOTI4MDct MTkwNjIwMDY+QnV0IEkgc3RpbGwgDQpkb3VidCB0aGF0IGlmIGl0J3MgbmVlZGVkIGZvciB0aGUg UENFIHRvIG1haW50YWluIHN1Y2ggaW5mb3JtYXRpb24gYW5kIGhvdyBhIFBDRSANCm9idGFpbnMg dGhlc2UgaW5mbz88L1NQQU4+PC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0 eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDog NXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4N CiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJH SU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdI VDogMHB4Ij4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BBTiANCiAgICBjbGFzcz01 NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxG T05UIGZhY2U9Q291cmllcj48U1BBTiANCiAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9T UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BB TiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+Jm5ic3A7PC9TUEFOPlNvIEkgDQogICAgdGhpbmsg aWYgdGhlIFBDQyBzZW5kIGEgcmVxdWVzdCB0byBhIFBDRSB3aGljaCBjYW4ndCBjb21wdXRlIHRo ZSBwYXRoIGZvciANCiAgICB0aGUgcmVhc29uIG9mIHRoZSBkZXN0aW5hdGlvbiBkb21haW4sIHRo ZSBQQ0UgY2FuIHRlbGwgdGhlIFBDQyBpbiB0aGUgUENyZXAgDQogICAgbWVzc2FnZSZuYnNwO3Ro ZSByaWdodCBQQ0UuJm5ic3A7PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIA0K ICAgIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48 L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPSswPjxTUEFOIGNsYXNzPTU3NzE5Mjgw Ny0xOTA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz01NzcxOTI4MDct MTkwNjIwMDY+SkxMUjogQnV0IGhvdyB0aGUgUENFIHdpbGwgaGF2ZSB0aGUgDQogICAgaW5mb3Jt YXRpb24/PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48 U1BBTiANCiAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BBTiBjbGFzcz01NzcxOTI4MDct MTkwNjIwMDY+Jm5ic3A7PC9TUEFOPk9uZSANCiAgICBhZGRpdGlvbmFsIHF1ZXNpb246IGlzIGl0 IHN1aXRhYmxlIGZvciB0aGUgUENFIHRvIGhhdmUgc3VjaCBhYmlsaXR5IHRvIGtub3cgDQogICAg ZXhhY3RseSB0aGUgZGVzdGluYXRpb24gZG9tYWluIGl0IGNhbiBjb21wdXRlIHRvd2FyZHM/PC9G T05UPjxGT05UIA0KICAgIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQog ICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQog ICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAg IGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAg IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBj bGFzcz01NzcxOTI4MDctMTkwNjIwMDY+SkxMUjogVGhpcyBpcyBhY3R1YWxseSZuYnNwO3JlcXVp cmVkLiBGb3IgaW5zdGFuY2UgDQogICAgaW4gYW4gaW50ZXItQVMgY2FzZSwgYW4gQVMgbWF5IGJl IGNvbm5lY3RlZCB0byBtdWx0aXBsZSBBU3MsIGFuZCZuYnNwO3RoZXJlIA0KICAgIG1heSBiZSBt dWx0aXBsZSBQQ0VzIGluIHRoaXMgQVMgKGUuZy4gQVNCUnMpLCBlYWNoIHJlc3BvbnNpYmxlIGZv ciBjb21wdXRpbmcgDQogICAgcGF0aCB0b3dhcmRzIGEgZ2l2ZW4gbmVpZ2hib3JkIEFTLjwvU1BB Tj48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCjxESVYgZGlyPWx0cj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+SGVy ZSB5b3UgDQpzYWlkIHRoZSBuZWlnaGJvcmluZyBBUywgYnV0IG5vdCB0aGUgZGVzdGluYXRpb24g QVMuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFE RElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9S REVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxCTE9D S1FVT1RFIGRpcj1sdHIgDQogIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6 IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+ DQogICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgIDxE SVY+PEZPTlQgZmFjZT1Db3VyaWVyPlNvbWUgZnVuY3Rpb25zIHNwZWNpZmllZCBpbiB0aGUgUEFU SC1DQU1QLUNBUCANCiAgICBzdWItVExWIGFyZSBhbHNvJm5ic3A7ZGVmaW5lZCZuYnNwO2luIHRo ZSBQQ0VQLCZuYnNwOyBhIGNsZWFyIGRpdmlzaW9uIA0KICAgIHNob3VsZCBiZSBtYWRlLiZuYnNw OzwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAg IGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRElWPg0KICAg IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBj bGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8 RElWPjxGT05UIHNpemU9KzA+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2Pg0KICAgIDxE SVY+PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQg DQogICAgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5 MDYyMDA2PiZuYnNwO0pMTFI6IA0KICAgICZuYnNwOzwvU1BBTj5BY3R1YWxseSwgYXQgdGhlIHRp bWUgYmVpbmcgdGhlIFBDRVAgc3BlYyBkb2VzIG5vdCBkZWZpbmUgYW55IA0KICAgIGNhcGFiaWxp dHkgaW5mb3JtYXRpb24uPC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz01Mzg0 NDQzMTYtMDIwNjIwMDY+SW4gDQogICAgY3VycmVudCBQQ0VQIHNwZWMsIHdlIG9ubHkgbWVudGlv biB0aGF0IGRldGFpbGVkIGNhcGFiaWxpdGVzIGNvdWxkIGJlIA0KICAgIGNhcnJpZWQgaW4gb3B0 aW9uYWwgc3ViLVRMVnMgb2YgdGhlIE9wZW4gb2JqZWN0IChjYXJyaWVkIGluIHRoZSBPcGVuIA0K ICAgIG1lc3NhZ2UpLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTUzODQ0NDMxNi0wMjA2 MjAwNj5CdXQgeW91IGFyZSByaWdodCBzdWNoIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gbWF5IA0K ICAgIGJlIGNhcnJpZWQgaW4gUENFUC48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz01Mzg0 NDQzMTYtMDIwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogICAgY2xhc3M9NTM4NDQ0 MzE2LTAyMDYyMDA2PlRoZSBpZGVhJm5ic3A7d291bGQgYmUmbmJzcDt0byBjYXJyeSZuYnNwO3Np bXBsZSANCiAgICBjYXBhYmlsaXRpZXMmbmJzcDtpbiB0aGUgSUdQIGFuZCZuYnNwO21vcmUgY29t cGxleCBjYXBhYmlsaXRpZXMgaW4gDQogICAgUENFUC48L1NQQU4+PC9GT05UPjwvRElWPg0KICAg IDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICBj bGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8 RElWPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQ QU4gDQogICAgY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PkFueXdheSBJIGRvbid0IHJlYWxseSBz ZWUgYW55IGlzc3VlIGk8L1NQQU4+PFNQQU4gDQogICAgY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2 PmYgd2UgZGVmaW5lIHR3byB3YXlzIHRvJm5ic3A7Y2FycnkmbmJzcDtzb21lIHBpZWNlcyANCiAg ICBvZiBpbmZvcm1hdGlvbjo8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogICAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNs YXNzPTUzODQ0NDMxNi0wMjA2MjAwNj4tSUdQLWJhc2VkIGNhcGFiaWxpdHkgZGlzY292ZXJ5IGlz IHVzZWZ1bCBmb3IgUENDcyANCiAgICB0aGF0IGRvbid0IGhhdmUgYSBQQ0VQIHNlc3Npb24gd2l0 aCB0aGUgUENFLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz01Mzg0 NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgICBjb2xvcj0jMDAwMGZm PjxGT05UIHNpemU9Mj4tUENFUC1iYXNlZCBjYXBhYmlsaXR5IGRpc2NvdmVyeSBpcyB1c2VmdWwg d2hlbiANCiAgICBJR1AgYmFzZWQgZGlzY292ZXJ5IGlzIG5vdCBhY3RpdmF0ZWQuPFNQQU4gDQog ICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv Rk9OVD48L1NQQU4+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCjxESVYg ZGlyPWx0cj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+VGhpcyBzb3VuZHMg ZmluZSB0byANCm1lLjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGly PWx0cj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9O VCBzaXplPTI+PFNQQU4gDQpjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyPjxTUEFOIGNsYXNzPTUzODQ0 NDMxNi0wMjA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiANCmNsYXNz PTU3NzE5MjgwNy0xOTA2MjAwNj5SZWdhcmRzLDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48 L0RJVj4NCjxESVYgZGlyPWx0cj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQg ZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+ WmhhbmcgPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPEJMT0NLUVVPVEUgZGly PWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJH SU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdI VDogMHB4Ij4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJTkctTEVGVDog NXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1B UkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8RElWPjxTUEFOIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAw Nj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICAgIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0y PjxTUEFOIA0KICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPjwvRk9O VD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9NTM4NDQ0 MzE2LTAyMDYyMDA2PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQogICAgY29sb3I9IzAwMDBmZj48 Rk9OVCBzaXplPTI+PFNQQU4gDQogICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48 L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBj bGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgICBjb2xv cj0jMDAwMGZmPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+VGhh bmtzIGZvciB0aGVzZSANCiAgICBjb21tZW50cyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PjxG T05UIGZhY2U9QXJpYWw+PEZPTlQgDQogICAgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQ QU4gDQogICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv Rk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJVj48U1BBTiBjbGFzcz01Mzg0NDQzMTYt MDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgICBjb2xvcj0jMDAwMGZmPjxGT05U IHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+UmVnYXJkcyw8L1NQ QU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xh c3M9NTM4NDQ0MzE2LTAyMDYyMDA2PjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgDQogICAgY29sb3I9 IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQQU4gDQogICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2 PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgPERJ Vj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCAN CiAgICBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz01NzcxOTI4 MDctMTkwNjIwMDY+SkwmbmJzcDs8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCiAgICBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQogICAgY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPiZuYnNwOzwv Rk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj5DaGVlcnMsPC9G T05UPjwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj5aaGFuZyANClJlbmhhaTwvRk9OVD48L0RJ Vj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_AKMsui3FgTWMdDydEYg/Yg)-- --===============1780123884== 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 --===============1780123884==-- From pce-bounces@lists.ietf.org Tue Jun 20 02:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsa7i-0005eI-8E; Tue, 20 Jun 2006 02:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsa7g-0005eD-Gz for pce@ietf.org; Tue, 20 Jun 2006 02:54:04 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsa7f-0005lA-9S for pce@ietf.org; Tue, 20 Jun 2006 02:54:04 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 08:54:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp Date: Tue, 20 Jun 2006 08:53:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-igp Thread-Index: AcaUHWB0qx9ZyqXOSBKUfPHjK+w2XAAFm2rw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Zhang Renhai" , X-OriginalArrivalTime: 20 Jun 2006 06:54:00.0946 (UTC) FILETIME=[4F7E4D20:01C69436] X-Spam-Score: 0.0 (/) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded 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="===============0433895303==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0433895303== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69436.4F771400" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69436.4F771400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgWmhhbmcsDQogDQpQbGVhc2Ugc2VlIGlubGluZSwNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQoJRGUgOiBaaGFuZyBSZW5oYWkgW21haWx0bzp6aGFuZ3JlbmhhaUBo dWF3ZWkuY29tXSANCglFbnZvecOpIDogbWFyZGkgMjAganVpbiAyMDA2IDA1OjI2DQoJw4AgOiBM RSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU47IHBjZUBpZXRmLm9yZw0KCU9iamV0IDogUmU6 IFtQY2VdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncA0KCQ0KCQ0K CUhpLCBKZWFuLUxvdWlzDQoJIA0KCVNlZSBpbmxpbmUsIHBsZWFzZS4NCg0KCQktLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KCQlGcm9tOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1M QU4gPG1haWx0bzpqZWFubG91aXMubGVyb3V4QG9yYW5nZS1mdC5jb20+ICANCgkJVG86IFpoYW5n IFJlbmhhaSA8bWFpbHRvOnpoYW5ncmVuaGFpQGh1YXdlaS5jb20+ICA7IHBjZUBpZXRmLm9yZyAN CgkJU2VudDogTW9uZGF5LCBKdW5lIDE5LCAyMDA2IDQ6MjMgUE0NCgkJU3ViamVjdDogUkU6IFtQ Y2VdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncA0KDQoJCUhpIFpo YW5nDQoJCSANCgkJVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzDQoJCSANCgkJUGxlYXNlIHNlZSBp bmxpbmUsDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KCQkJRGUgOiBa aGFuZyBSZW5oYWkgW21haWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29tXSANCgkJCUVudm95w6kg OiBtYXJkaSAxMyBqdWluIDIwMDYgMDk6MDcNCgkJCcOAIDogcGNlQGlldGYub3JnDQoJCQlPYmpl dCA6IFtQY2VdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncA0KCQkJ DQoJCQkNCgkJCUhpLCBhbGwNCgkJCSANCgkJCUkgcmVjZW50bHkgcmVhZCB0aGUgZHJhZnQgZHJh ZnQtaWV0Zi1wY2UtZGlzY28tcHJvdG8taWdwIGFnYWluLCBoZXJlIGFyZSBzb21lIGNvbW1lbnRz 44CCDQoJCQkgDQoJCQlXaGVuIElHUCBpcyB1c2VkIGFzIGEgUENFRCBwcm90b2NvbCwgdGhlIGNh cGFiaWxpdGllcyBvZiBwY2Ugd2lsbCBiZSBhZHZlcnRpc2VkIHBlcmlvZGljbHkgYWxvbmcgd2l0 aCBvdGhlciBsc2EvbHNwIGluZm9ybWF0aW9uLiBJbiBteSBvcGluaW9uLCB1bmxlc3MgdGhlIFBD RSdzIGNhcGFiaWxpdGllcyBjaGFuZ2UsICB0aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgUENDIHRv IHJlY2VpdmUgYW5kIGhhbmRsZSB0aGUgaW5mb3JtYXRpb24gYWdhaW4uICANCgkJCSANCgkJCUpM TFI6IEJ1dCB0aGVzZSBhcmUgc3RhbmRhcmQgSUdQIHByb2NlZHVyZXMuIFRoaXMgaXMgdGhlIHNh bWUgZm9yIGxpbmsgc3RhdGVzLCB0aGV5IGFyZSByZWZyZXNoZWQgZXZlbiBpZiB0aGVyZSBpcyBu b3QgY2hhbmdlLiBCeSB0aGUgd2F5IHRoZSByZWZyZXNoIGludGVydmFsIGNhbiBiZSBxdWl0ZSBs YXJnZSAoZS5nLiAxOCBob3VycyBmb3IgSVMtSVMpLg0KCQkJIA0KCQkJIA0KCQkJIA0KCQkJIEZ1 cnRoZXJtb3JlLCBpZiBtb3N0IG9mIHRoZSByb3V0ZXJzIGluIGEgZG9tYWluIHdpbGwgYWx3YXlz IGhhdmUgbm8gcmVxdWVzdCB0byBhIFBDRSwgdGhlcmUgaXMgYWxzbyBubyBuZWVkIGZvciB0aGVt IHRvIG1haW50YWluIHRoZSBpbmZvcm1hdGlvbi4gIA0KCQkJIA0KCQkJDQoJCQlKTExSOiBJbiB0 aGlzIGNhc2UgUENFIGRpc2NvdmVyeSBpcyBkZWFjdGl2YXRlZCBvbiB0aGVzZSByb3V0ZXJzIGFu ZCB0aGV5IHdpbGwgbm90IHByb2Nlc3MgdGhlIFBDRUQgYW5kIFBDRVMgVExWcy4uLg0KDQoJQnV0 IEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBwb3NzaWJsZSBmb3IgYSByb3V0ZXIgdG8gYmUgcmUtY29u ZmlndXJlZCBhcyBhIFBDQyBvciBoYXZlIHNvbWUgcGF0aCBjb21wdXRhdGlvbiByZXF1ZXN0IGFm dGVyIGl0IHJlY2VpdmVzIHRoZXNlIFRMVnMgYW5kIG5vdCBwcm9jZXNzZXMgdGhlbSwgIA0KCSAN CglOb3cgaWYgYSByb3V0ZXIgaXMgY29uZmlndXJlZCBhcyBQQ0MgYXQgc29tZSBwb2ludCBpbiB0 aW1lLCB0aGVuIGl0IHN0YXJ0cyBwcm9jZXNzaW5nIGluZm9ybWF0aW9uIGNhcnJpZWQgaW4gUENF RCBhbmQgUENFUyBUTFZzLi4uKEJlZm9yZSB5b3UgYWN0aXZhdGUgUENFIGRpc2NvdmVyeSBvbiB0 aGUgUENDIHRoZSBpbmZvcm1hdGlvbiBpcyBzdG9yZWQgYnV0IG5vdCBwcm9jZXNzZWQpLg0KCSAN Cg0KCQkJIA0KCQkJIA0KCQkJTXkgY29uY2VybiB0byBQQ0UtREVTVC1ET01BSU5TIHN1Yi1UTFYg aXMgdGhhdCB3ZSBjYW4ndCBhbnRpY2lwYXRlIGhvdyBtYW55IGRlc3RpbmF0aW9uIGRvbWFpbnMg YSBQQ0UgY2FuICBjb21wdXRhdGUgcGF0aCB0b3dhcmRzLCBhcyBhIHJlc3VsdCx0aGUgbGVuZ3Ro IG9mIHNwYWNlIHRha2VuIGJ5IHRoaXMgY2FwYWxpdHkgaW4gdGhlIG1lc3NhZ2UgY2FuJ3QgYmUg Y29udHJvbGxlZC4gIA0KCQkJIA0KCQkJSkxMUjogQWN0dWFsbHkgeW91IGhhdmUgdGhlIHNhbWUg cHJvYmxlbSB3aXRoIHRoZSBudW1iZXIgb2YgVEUtbGlua3MgYWR2ZXJ0aXNlZCBieSBhbiBMU1Ig b3IgdGhlIG51bWJlciBvZiByZWFjaGVhYmxlIHByZWZpeGVzIGFkdmVydGlzZWQgYnkgYW4gQUJS LiANCgkJCU9uZSBtYXkgbGltaXQgYnkgY29uZmlndXJhdGlvbiB0aGUgbnVtYmVyIG9mIGRlc3Qg ZG9tYWlucyBhZHZlcnRpc2VkLg0KDQoJQnV0IEkgc3RpbGwgZG91YnQgdGhhdCBpZiBpdCdzIG5l ZWRlZCBmb3IgdGhlIFBDRSB0byBtYWludGFpbiBzdWNoIGluZm9ybWF0aW9uIGFuZCBob3cgYSBQ Q0Ugb2J0YWlucyB0aGVzZSBpbmZvPyANCglBcyBkaXNjdXNzZWQgbGF0dGVyIHRoaXMgaXMgYSBy ZWFsbHkgdXNlZnVsIGZlYXR1cmUgdGhhdCBoZWxwcyBQQ0Ugc2VsZWN0aW9uIGFuZCBsb2FkIGJh bGFuY2luZy4NCglJbiB0aGUgaW50ZXItYXJlYSBjYXNlLCB0aGUgY2FuIGxlYXJuIHRoaXMgaW5m byBib3RoIHZpYSBjb25maWcgYW5kIHZpYSB0aGUgSUdQIChlLmcuIGlmIHRoZSBQQ0UgaXMgYW4g QUJSLCBpdCBjYW4gZWFzaWx5IGtub3cgYXR0YWNoZWQgYXJlYXMpLg0KCUluIHRoZSBpbnRlci1B UyBjYXNlLCB0aGUgUENFIGNhbiBsZWFybiB0aGlzIGluZm9ybWF0aW9uIGJvdGggdmlhIGNvbmZp ZyBhbmQgdmlhIEJHUC4gDQoNCgkJCSANCgkJCSANCgkJCSBTbyBJIHRoaW5rIGlmIHRoZSBQQ0Mg c2VuZCBhIHJlcXVlc3QgdG8gYSBQQ0Ugd2hpY2ggY2FuJ3QgY29tcHV0ZSB0aGUgcGF0aCBmb3Ig dGhlIHJlYXNvbiBvZiB0aGUgZGVzdGluYXRpb24gZG9tYWluLCB0aGUgUENFIGNhbiB0ZWxsIHRo ZSBQQ0MgaW4gdGhlIFBDcmVwIG1lc3NhZ2UgdGhlIHJpZ2h0IFBDRS4gIA0KCQkJIA0KCQkJSkxM UjogQnV0IGhvdyB0aGUgUENFIHdpbGwgaGF2ZSB0aGUgaW5mb3JtYXRpb24/DQoJCQkgDQoJCQkg T25lIGFkZGl0aW9uYWwgcXVlc2lvbjogaXMgaXQgc3VpdGFibGUgZm9yIHRoZSBQQ0UgdG8gaGF2 ZSBzdWNoIGFiaWxpdHkgdG8ga25vdyBleGFjdGx5IHRoZSBkZXN0aW5hdGlvbiBkb21haW4gaXQg Y2FuIGNvbXB1dGUgdG93YXJkcz8gDQoJCQkgDQoJCQlKTExSOiBUaGlzIGlzIGFjdHVhbGx5IHJl cXVpcmVkLiBGb3IgaW5zdGFuY2UgaW4gYW4gaW50ZXItQVMgY2FzZSwgYW4gQVMgbWF5IGJlIGNv bm5lY3RlZCB0byBtdWx0aXBsZSBBU3MsIGFuZCB0aGVyZSBtYXkgYmUgbXVsdGlwbGUgUENFcyBp biB0aGlzIEFTIChlLmcuIEFTQlJzKSwgZWFjaCByZXNwb25zaWJsZSBmb3IgY29tcHV0aW5nIHBh dGggdG93YXJkcyBhIGdpdmVuIG5laWdoYm9yZCBBUy4NCg0KCUhlcmUgeW91IHNhaWQgdGhlIG5l aWdoYm9yaW5nIEFTLCBidXQgbm90IHRoZSBkZXN0aW5hdGlvbiBBUy4gDQoJIA0KCUl0IHdhcyBh biBleGFtcGxlIHdoZXJlIHRoZSBkZXN0aW5hdGlvbiBpcyBsb2NhdGVkIGluIHRoZSBuZWlnaGJv cmluZyBBUy4uLiBCdXQgdGhlIHNhbWUgYXBwbGllcyB3aGVuIHRoZSBkZXN0aW5hdGlvbiBpcyBs b2NhdGVkIGZhcnRoZXIuDQoJIA0KCVRoYW5rcyANCgkgDQoJSkwNCg0KCQkJIA0KCQkJU29tZSBm dW5jdGlvbnMgc3BlY2lmaWVkIGluIHRoZSBQQVRILUNBTVAtQ0FQIHN1Yi1UTFYgYXJlIGFsc28g ZGVmaW5lZCBpbiB0aGUgUENFUCwgIGEgY2xlYXIgZGl2aXNpb24gc2hvdWxkIGJlIG1hZGUuICAN CgkJCSANCgkJCQ0KCQkJIEpMTFI6ICBBY3R1YWxseSwgYXQgdGhlIHRpbWUgYmVpbmcgdGhlIFBD RVAgc3BlYyBkb2VzIG5vdCBkZWZpbmUgYW55IGNhcGFiaWxpdHkgaW5mb3JtYXRpb24uDQoJCQlJ biBjdXJyZW50IFBDRVAgc3BlYywgd2Ugb25seSBtZW50aW9uIHRoYXQgZGV0YWlsZWQgY2FwYWJp bGl0ZXMgY291bGQgYmUgY2FycmllZCBpbiBvcHRpb25hbCBzdWItVExWcyBvZiB0aGUgT3BlbiBv YmplY3QgKGNhcnJpZWQgaW4gdGhlIE9wZW4gbWVzc2FnZSkuDQoJCQlCdXQgeW91IGFyZSByaWdo dCBzdWNoIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gbWF5IGJlIGNhcnJpZWQgaW4gUENFUC4NCgkJ CSANCgkJCVRoZSBpZGVhIHdvdWxkIGJlIHRvIGNhcnJ5IHNpbXBsZSBjYXBhYmlsaXRpZXMgaW4g dGhlIElHUCBhbmQgbW9yZSBjb21wbGV4IGNhcGFiaWxpdGllcyBpbiBQQ0VQLg0KCQkJIA0KCQkJ QW55d2F5IEkgZG9uJ3QgcmVhbGx5IHNlZSBhbnkgaXNzdWUgaWYgd2UgZGVmaW5lIHR3byB3YXlz IHRvIGNhcnJ5IHNvbWUgcGllY2VzIG9mIGluZm9ybWF0aW9uOg0KCQkJLUlHUC1iYXNlZCBjYXBh YmlsaXR5IGRpc2NvdmVyeSBpcyB1c2VmdWwgZm9yIFBDQ3MgdGhhdCBkb24ndCBoYXZlIGEgUENF UCBzZXNzaW9uIHdpdGggdGhlIFBDRS4NCgkJCS1QQ0VQLWJhc2VkIGNhcGFiaWxpdHkgZGlzY292 ZXJ5IGlzIHVzZWZ1bCB3aGVuIElHUCBiYXNlZCBkaXNjb3ZlcnkgaXMgbm90IGFjdGl2YXRlZC4g DQoNCglUaGlzIHNvdW5kcyBmaW5lIHRvIG1lLg0KCSANCglSZWdhcmRzLA0KCVpoYW5nIA0KDQoJ CQkgDQoJCQkgDQoJCQlUaGFua3MgZm9yIHRoZXNlIGNvbW1lbnRzLA0KCQkJIA0KCQkJUmVnYXJk cywNCgkJCSANCgkJCUpMIA0KCQkJIA0KCQkJIA0KCQkJIA0KCQkJIA0KCQkJQ2hlZXJzLA0KCQkJ IA0KCQkJWmhhbmcgUmVuaGFpDQoNCg== ------_=_NextPart_001_01C69436.4F771400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMjg3MyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNs YXNzPTk4NjA0MzYwNi0yMDA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBz aXplPTI+SGkgWmhhbmcsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxTUEFOIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KY29s b3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0 ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj48Rk9OVCBmYWNlPUFy aWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+UGxlYXNlIHNlZSBpbmxpbmUsPC9GT05UPjwvU1BB Tj48L0RJVj48QlI+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctTEVGVDog NXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1B UkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5n PWZyIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4PS0xPg0KICA8Rk9OVCBmYWNl PVRhaG9tYSBzaXplPTI+PEI+RGUmbmJzcDs6PC9CPiBaaGFuZyBSZW5oYWkgDQogIFttYWlsdG86 emhhbmdyZW5oYWlAaHVhd2VpLmNvbV0gPEJSPjxCPkVudm95w6kmbmJzcDs6PC9CPiBtYXJkaSAy MCBqdWluIDIwMDYgDQogIDA1OjI2PEJSPjxCPsOAJm5ic3A7OjwvQj4gTEUgUk9VWCBKZWFuLUxv dWlzIFJELUNPUkUtTEFOOyANCiAgcGNlQGlldGYub3JnPEJSPjxCPk9iamV0Jm5ic3A7OjwvQj4g UmU6IFtQY2VdIENvbW1lbnRzIG9uIA0KICBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3A8 QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPeWu i+S9kyBzaXplPTI+SGksIEplYW4tTG91aXM8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFj ZT3lrovkvZMgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPeWu i+S9kyBzaXplPTI+U2VlIGlubGluZSwgcGxlYXNlLjwvRk9OVD48L0RJVj4NCiAgPEJMT0NLUVVP VEUgZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1 cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFS R0lOLVJJR0hUOiAwcHgiPg0KICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogICAgPERJViANCiAgICBzdHlsZT0iQkFD S0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IOWui+S9kzsgZm9udC1jb2xvcjogYmxhY2siPjxC PkZyb206PC9CPiA8QSANCiAgICB0aXRsZT1qZWFubG91aXMubGVyb3V4QG9yYW5nZS1mdC5jb20g DQogICAgaHJlZj0ibWFpbHRvOmplYW5sb3Vpcy5sZXJvdXhAb3JhbmdlLWZ0LmNvbSI+TEUgUk9V WCBKZWFuLUxvdWlzIA0KICAgIFJELUNPUkUtTEFOPC9BPiA8L0RJVj4NCiAgICA8RElWIHN0eWxl PSJGT05UOiA5cHQg5a6L5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXpoYW5ncmVuaGFpQGh1YXdl aS5jb20gDQogICAgaHJlZj0ibWFpbHRvOnpoYW5ncmVuaGFpQGh1YXdlaS5jb20iPlpoYW5nIFJl bmhhaTwvQT4gOyA8QSANCiAgICB0aXRsZT1wY2VAaWV0Zi5vcmcgaHJlZj0ibWFpbHRvOnBjZUBp ZXRmLm9yZyI+cGNlQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgICA8RElWIHN0eWxlPSJGT05UOiA5 cHQg5a6L5L2TIj48Qj5TZW50OjwvQj4gTW9uZGF5LCBKdW5lIDE5LCAyMDA2IDQ6MjMgUE08L0RJ Vj4NCiAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0OjwvQj4gUkU6 IFtQY2VdIENvbW1lbnRzIG9uIA0KICAgIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncDwv RElWPg0KICAgIDxESVY+PEJSPjwvRElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPkhpIFpoYW5nPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PEZPTlQgZmFj ZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv RElWPg0KICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0x OTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPlRoYW5r cyBmb3IgeW91ciBjb21tZW50czwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJp YWwgDQogICAgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4N CiAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIw MDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5QbGVhc2Ugc2Vl IGlubGluZSw8L0ZPTlQ+PC9TUEFOPjwvRElWPjxCUj4NCiAgICA8QkxPQ0tRVU9URSBkaXI9bHRy IA0KICAgIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVS LUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElW IGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZnIgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0K ICAgICAgPEhSIHRhYkluZGV4PS0xPg0KICAgICAgPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxC PkRlJm5ic3A7OjwvQj4gWmhhbmcgUmVuaGFpIA0KICAgICAgW21haWx0bzp6aGFuZ3JlbmhhaUBo dWF3ZWkuY29tXSA8QlI+PEI+RW52b3nDqSZuYnNwOzo8L0I+IG1hcmRpIDEzIGp1aW4gDQogICAg ICAyMDA2IDA5OjA3PEJSPjxCPsOAJm5ic3A7OjwvQj4gPEEgDQogICAgICBocmVmPSJtYWlsdG86 cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L0E+PEJSPjxCPk9iamV0Jm5ic3A7OjwvQj4gW1Bj ZV0gDQogICAgICBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3A8QlI+ PC9GT05UPjxCUj48L0RJVj4NCiAgICAgIDxESVY+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZh Y2U9Q291cmllcj5IaSwgYWxsPC9GT05UPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUNv dXJpZXIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1D b3VyaWVyPkkgcmVjZW50bHkgcmVhZCB0aGUgZHJhZnQgDQogICAgICBkcmFmdC1pZXRmLXBjZS1k aXNjby1wcm90by1pZ3AgYWdhaW4sIGhlcmUgYXJlIHNvbWUgY29tbWVudHPjgII8L0ZPTlQ+PC9E SVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48L0ZPTlQ+PEZPTlQgZmFjZT1Db3Vy aWVyPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPldo ZW4gSUdQIGlzIHVzZWQmbmJzcDthcyBhIFBDRUQgcHJvdG9jb2wsIHRoZSANCiAgICAgIGNhcGFi aWxpdGllcyBvZiBwY2Ugd2lsbCBiZSBhZHZlcnRpc2VkIHBlcmlvZGljbHkgYWxvbmcgd2l0aCBv dGhlciBsc2EvbHNwIA0KICAgICAgaW5mb3JtYXRpb24uIEluIG15IG9waW5pb24sIHVubGVzcyB0 aGUgUENFJ3MgY2FwYWJpbGl0aWVzIGNoYW5nZSwmbmJzcDsgDQogICAgICB0aGVyZSBpcyBubyBu ZWVkIGZvciB0aGUgUENDIHRvIHJlY2VpdmUgYW5kJm5ic3A7aGFuZGxlIHRoZSBpbmZvcm1hdGlv biANCiAgICAgIGFnYWluLiZuYnNwOzxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICBzaXplPTI+Jm5ic3A7PC9GT05UPjwv U1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2 MjAwNj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICBzaXplPTI+PC9GT05U PjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5KTExS OiBCdXQgdGhlc2UgYXJlIHN0YW5kYXJkIElHUCBwcm9jZWR1cmVzLiBUaGlzIA0KICAgICAgaXMg dGhlIHNhbWUgZm9yIGxpbmsgc3RhdGVzLCB0aGV5IGFyZSByZWZyZXNoZWQgZXZlbiBpZiB0aGVy ZSBpcyBub3QgDQogICAgICBjaGFuZ2UuIEJ5IHRoZSB3YXkgdGhlIHJlZnJlc2ggaW50ZXJ2YWwg Y2FuIGJlIHF1aXRlIGxhcmdlIChlLmcuIDE4IGhvdXJzIA0KICAgICAgZm9yIElTLUlTKS48L1NQ QU4+PC9GT05UPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BBTiAN CiAgICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElW Pg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gDQogICAgICBjbGFzcz01Nzcx OTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZP TlQgZmFjZT1Db3VyaWVyPjxTUEFOIA0KICAgICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PiZu YnNwOzwvU1BBTj5GdXJ0aGVybW9yZSwgaWYgbW9zdCBvZiB0aGUgcm91dGVycyANCiAgICAgIGlu IGEgZG9tYWluIHdpbGwgYWx3YXlzIGhhdmUgbm8gcmVxdWVzdCB0byBhIFBDRSwgdGhlcmUgaXMg YWxzbyBubyBuZWVkIA0KICAgICAgZm9yIHRoZW0gdG8gbWFpbnRhaW4gdGhlIGluZm9ybWF0aW9u LiZuYnNwOzwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgY29sb3I9IzAwMDBmZiBzaXpl PTI+PFNQQU4gDQogICAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+Jm5ic3A7PC9TUEFOPjwv Rk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05U PiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmPjxTUEFOIGNsYXNz PTU3NzE5MjgwNy0xOTA2MjAwNj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5KTExS OiBJbiB0aGlzIGNhc2UgUENFIGRpc2NvdmVyeSBpcyBkZWFjdGl2YXRlZCANCiAgICAgIG9uIHRo ZXNlIHJvdXRlcnMgYW5kIHRoZXkgd2lsbCBub3QgcHJvY2VzcyB0aGUgUENFRCBhbmQgUENFUyAN CiAgICAgIFRMVnMuLi48L1NQQU4+PC9GT05UPjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT48L0JM T0NLUVVPVEU+DQogIDxESVYgZGlyPWx0cj48Rk9OVCBjb2xvcj0jMDAwMGZmPjxTUEFOIGNsYXNz PTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCANCiAgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEZP TlQgY29sb3I9IzAwMDAwMD5CdXQgSSBkb24ndCBrbm93IGlmIGl0IGlzIHBvc3NpYmxlIA0KICBm b3IgYSByb3V0ZXIgdG8gYmUgcmUtY29uZmlndXJlZCZuYnNwO2FzIGEgUENDIG9yIGhhdmUgc29t ZSZuYnNwO3BhdGggDQogIGNvbXB1dGF0aW9uIHJlcXVlc3QmbmJzcDthZnRlciZuYnNwO2l0IHJl Y2VpdmVzIHRoZXNlIFRMVnMgYW5kIG5vdCBwcm9jZXNzZXMgDQogIHRoZW0sPC9GT05UPiZuYnNw OzxTUEFOIA0KICBjbGFzcz05ODYwNDM2MDYtMjAwNjIwMDY+Jm5ic3A7PC9TUEFOPjwvRk9OVD48 L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJViBkaXI9bHRyPjxGT05UIGNvbG9yPSMw MDAwZmY+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIA0KICBmYWNlPUFyaWFs PjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9OTg2MDQzNjA2LTIwMDYyMDA2PjwvU1BBTj48 L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0cj48 Rk9OVCBjb2xvcj0jMDAwMGZmPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCAN CiAgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9OTg2MDQzNjA2LTIwMDYyMDA2 Pk5vdyANCiAgaTwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PEZPTlQgY29sb3I9 IzAwMDBmZj48U1BBTiANCiAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjxGT05UIGZhY2U9QXJp YWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz05ODYwNDM2MDYtMjAwNjIwMDY+ZiBhIHJv dXRlciBpcyBjb25maWd1cmVkIGFzIFBDQyBhdCBzb21lIHBvaW50IGluIA0KICB0aW1lLCB0aGVu Jm5ic3A7aXQmbmJzcDtzdGFydHMgcHJvY2Vzc2luZyZuYnNwO2luZm9ybWF0aW9uIGNhcnJpZWQg aW4gUENFRCBhbmQgDQogIFBDRVMgVExWcy4uLihCZWZvcmUgeW91IGFjdGl2YXRlIFBDRSBkaXNj b3Zlcnkgb24gdGhlIFBDQyB0aGUgaW5mb3JtYXRpb24gaXMgDQogIHN0b3JlZCBidXQgbm90IHBy b2Nlc3NlZCkuPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJ ViBkaXI9bHRyPjxGT05UIGNvbG9yPSMwMDAwZmY+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYy MDA2PjxGT05UIA0KICBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9OTg2 MDQzNjA2LTIwMDYyMDA2PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQogIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogIHN0eWxlPSJQQURESU5HLVJJR0hUOiAw cHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAw MDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICA8QkxPQ0tRVU9URSBkaXI9 bHRyIA0KICAgIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9S REVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8 RElWPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPk15IGNvbmNlcm4gdG8gUENFLURF U1QtRE9NQUlOUyBzdWItVExWJm5ic3A7aXMgDQogICAgICB0aGF0IHdlIGNhbid0IGFudGljaXBh dGUgaG93IG1hbnkgZGVzdGluYXRpb24gZG9tYWlucyBhIFBDRSBjYW4gDQogICAgICAmbmJzcDtj b21wdXRhdGUgcGF0aCB0b3dhcmRzLCZuYnNwO2FzIGEgcmVzdWx0LHRoZSBsZW5ndGggb2Ygc3Bh Y2UgdGFrZW4gDQogICAgICBieSB0aGlzIGNhcGFsaXR5IGluIHRoZSBtZXNzYWdlIGNhbid0IGJl IGNvbnRyb2xsZWQuJm5ic3A7PFNQQU4gDQogICAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0yPiZuYnNwOzwvRk9O VD48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01NzcxOTI4MDct MTkwNjIwMDY+PEZPTlQgZmFjZT3lrovkvZMgDQogICAgICBzaXplPTI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNp emU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5KTExSOiBBY3R1YWxs eSB5b3UgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtIHdpdGggdGhlIA0KICAgICAgbnVtYmVyIG9mIFRF LWxpbmtzIGFkdmVydGlzZWQgYnkmbmJzcDthbiBMU1Igb3IgdGhlIG51bWJlciBvZiByZWFjaGVh YmxlIA0KICAgICAgcHJlZml4ZXMgYWR2ZXJ0aXNlZCBieSBhbiBBQlIuIDwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+ PFNQQU4gDQogICAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+T25lIG1heSBsaW1pdCBieSBj b25maWd1cmF0aW9uIHRoZSBudW1iZXIgb2YgZGVzdCANCiAgICAgIGRvbWFpbnMgYWR2ZXJ0aXNl ZC48L1NQQU4+PC9GT05UPjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQogIDxESVYg ZGlyPWx0cj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCBzaXplPTI+QnV0IA0KICBJIHN0aWxsIGRvdWJ0IHRoYXQgaWYgaXQncyBuZWVkZWQgZm9y IHRoZSBQQ0UgdG8gbWFpbnRhaW4gc3VjaCBpbmZvcm1hdGlvbiBhbmQgDQogIGhvdyBhIFBDRSBv YnRhaW5zIHRoZXNlIGluZm8/PFNQQU4gY2xhc3M9OTg2MDQzNjA2LTIwMDYyMDA2PjxGT05UIA0K ICBjb2xvcj0jMDAwMGZmPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+ PC9ESVY+DQogIDxESVYgZGlyPWx0cj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PEZP TlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgc2l6ZT0yPjxTUEFOIGNsYXNzPTk4NjA0MzYwNi0yMDA2 MjAwNj48Rk9OVCBjb2xvcj0jMDAwMGZmPkFzIGRpc2N1c3NlZCBsYXR0ZXIgDQogIHRoaXMgaXMg YSByZWFsbHkgdXNlZnVsIGZlYXR1cmUgdGhhdCBoZWxwcyBQQ0Ugc2VsZWN0aW9uIGFuZCBsb2Fk IA0KICBiYWxhbmNpbmcuPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj4N CiAgPERJViBkaXI9bHRyPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNl PUFyaWFsPjxGT05UIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9OTg2 MDQzNjA2LTIwMDYyMDA2PkluPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjxTUEFOIA0KICBj bGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PFNQ QU4gDQogIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj48Rk9OVCBjb2xvcj0jMDAwMGZmPiZuYnNw O3RoZSBpbnRlci1hcmVhIGNhc2UsIHRoZSANCiAgY2FuIGxlYXJuIHRoaXMgaW5mbyBib3RoIHZp YSBjb25maWcgYW5kIHZpYSB0aGUgSUdQIChlLmcuIGlmIHRoZSBQQ0UgaXMgYW4gDQogIEFCUiwg aXQgY2FuIGVhc2lseSBrbm93IGF0dGFjaGVkIA0KICBhcmVhcykuPC9GT05UPjwvU1BBTj48L0ZP TlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyPjxTUEFOIGNsYXNzPTU3NzE5 MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBjb2xvcj0jMDAwMGZmIHNp emU9Mj48U1BBTiBjbGFzcz05ODYwNDM2MDYtMjAwNjIwMDY+SW4gdGhlIGludGVyLUFTIGNhc2Us IHRoZSANCiAgUENFIGNhbiBsZWFybiB0aGlzIGluZm9ybWF0aW9uIGJvdGgmbmJzcDt2aWEmbmJz cDtjb25maWcmbmJzcDthbmQgdmlhIA0KICBCR1AuPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9TUEFO PjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCANCiAgZmFjZT1BcmlhbD48Rk9O VCBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj4mbmJzcDs8L1NQQU4+ PC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogIHN0 eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDog NXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4N CiAgICA8QkxPQ0tRVU9URSBkaXI9bHRyIA0KICAgIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsg TUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4t UklHSFQ6IDBweCI+DQogICAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BBTiANCiAgICAg IGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAg ICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gDQogICAgICBjbGFzcz01NzcxOTI4MDct MTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFj ZT1Db3VyaWVyPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDs8L1NQQU4+U28g SSANCiAgICAgIHRoaW5rIGlmIHRoZSBQQ0Mgc2VuZCBhIHJlcXVlc3QgdG8gYSBQQ0Ugd2hpY2gg Y2FuJ3QgY29tcHV0ZSB0aGUgcGF0aCBmb3IgDQogICAgICB0aGUgcmVhc29uIG9mIHRoZSBkZXN0 aW5hdGlvbiBkb21haW4sIHRoZSBQQ0UgY2FuIHRlbGwgdGhlIFBDQyBpbiB0aGUgDQogICAgICBQ Q3JlcCBtZXNzYWdlJm5ic3A7dGhlIHJpZ2h0IFBDRS4mbmJzcDs8U1BBTiANCiAgICAgIGNsYXNz PTU3NzE5MjgwNy0xOTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAg ICBzaXplPTI+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxG T05UIHNpemU9KzA+PFNQQU4gDQogICAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFO PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5KTExS OiBCdXQgaG93IHRoZSBQQ0Ugd2lsbCBoYXZlIHRoZSANCiAgICAgIGluZm9ybWF0aW9uPzwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9Q291cmllcj48U1BBTiANCiAg ICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0K ICAgICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYy MDA2PiZuYnNwOzwvU1BBTj5PbmUgDQogICAgICBhZGRpdGlvbmFsIHF1ZXNpb246IGlzIGl0IHN1 aXRhYmxlIGZvciB0aGUgUENFIHRvIGhhdmUgc3VjaCBhYmlsaXR5IHRvIA0KICAgICAga25vdyBl eGFjdGx5IHRoZSBkZXN0aW5hdGlvbiBkb21haW4gaXQgY2FuIGNvbXB1dGUgdG93YXJkcz88L0ZP TlQ+PEZPTlQgDQogICAgICBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0K ICAgICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9ESVY+ DQogICAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQogICAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCiAgICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5KTExSOiBUaGlzIGlzIGFjdHVhbGx5 Jm5ic3A7cmVxdWlyZWQuIEZvciANCiAgICAgIGluc3RhbmNlIGluIGFuIGludGVyLUFTIGNhc2Us IGFuIEFTIG1heSBiZSBjb25uZWN0ZWQgdG8gbXVsdGlwbGUgQVNzLCANCiAgICAgIGFuZCZuYnNw O3RoZXJlIG1heSBiZSBtdWx0aXBsZSBQQ0VzIGluIHRoaXMgQVMgKGUuZy4gQVNCUnMpLCBlYWNo IA0KICAgICAgcmVzcG9uc2libGUgZm9yIGNvbXB1dGluZyBwYXRoIHRvd2FyZHMgYSBnaXZlbiBu ZWlnaGJvcmQgDQogICAgICBBUy48L1NQQU4+PC9GT05UPjwvRElWPjwvQkxPQ0tRVU9URT48L0JM T0NLUVVPVEU+DQogIDxESVYgZGlyPWx0cj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+ PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+SGVyZSANCiAgeW91IHNhaWQgdGhlIG5laWdo Ym9yaW5nIEFTLCBidXQgbm90IHRoZSBkZXN0aW5hdGlvbiBBUy48U1BBTiANCiAgY2xhc3M9OTg2 MDQzNjA2LTIwMDYyMDA2PjxGT05UIA0KICBjb2xvcj0jMDAwMGZmPiZuYnNwOzwvRk9OVD48L1NQ QU4+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0cj48U1BBTiBjbGFz cz01NzcxOTI4MDctMTkwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgY29sb3I9IzAw MDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj48L1NQQU4+PC9G T05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0cj48U1BBTiBjbGFz cz01NzcxOTI4MDctMTkwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgc2l6ZT0yPjxT UEFOIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj48Rk9OVCBjb2xvcj0jMDAwMGZmPkl0IHdhcyBh biBleGFtcGxlIA0KICB3aGVyZSB0aGUgZGVzdGluYXRpb24gaXMgbG9jYXRlZCBpbiB0aGUgbmVp Z2hib3JpbmcgQVMuLi4gQnV0IHRoZSBzYW1lIGFwcGxpZXMgDQogIHdoZW4gdGhlIGRlc3RpbmF0 aW9uIGlzIGxvY2F0ZWQgDQogIGZhcnRoZXIuPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwv U1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAw Nj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiAN CiAgY2xhc3M9OTg2MDQzNjA2LTIwMDYyMDA2PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyPjxTUEFOIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAw Nj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBj bGFzcz05ODYwNDM2MDYtMjAwNjIwMDY+VGhhbmtzIA0KICA8L1NQQU4+PC9GT05UPjwvRk9OVD48 L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0cj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIw MDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQogIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj48L1NQQU4+PC9GT05UPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0cj48U1BBTiBjbGFzcz01NzcxOTI4MDctMTkwNjIw MDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQogIGNsYXNzPTk4NjA0MzYwNi0yMDA2MjAwNj5KTDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJTkctUklHSFQ6 IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAj MDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgIDxCTE9DS1FVT1RFIGRp cj1sdHIgDQogICAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBC T1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgICAg IDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+ PEZPTlQgZmFjZT1Db3VyaWVyPlNvbWUgZnVuY3Rpb25zIHNwZWNpZmllZCBpbiB0aGUgUEFUSC1D QU1QLUNBUCANCiAgICAgIHN1Yi1UTFYgYXJlIGFsc28mbmJzcDtkZWZpbmVkJm5ic3A7aW4gdGhl IFBDRVAsJm5ic3A7IGEgY2xlYXIgZGl2aXNpb24gDQogICAgICBzaG91bGQgYmUgbWFkZS4mbmJz cDs8L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAg ICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDs8L1NQQU4+PC9GT05UPjwvRElWPg0K ICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0K ICAgICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQogICAgICA8RElWPjxGT05UIHNpemU9KzA+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2 Pg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1B cmlhbD48Rk9OVCANCiAgICAgIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPjxTUEFOIGNsYXNz PTU3NzE5MjgwNy0xOTA2MjAwNj4mbmJzcDtKTExSOiANCiAgICAgICZuYnNwOzwvU1BBTj5BY3R1 YWxseSwgYXQgdGhlIHRpbWUgYmVpbmcgdGhlIFBDRVAgc3BlYyBkb2VzIG5vdCBkZWZpbmUgYW55 IA0KICAgICAgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbi48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQ QU4+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+PFNQQU4gDQogICAgICBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+SW4gY3VycmVudCBQQ0VQ IHNwZWMsIHdlIG9ubHkgbWVudGlvbiB0aGF0IA0KICAgICAgZGV0YWlsZWQgY2FwYWJpbGl0ZXMg Y291bGQgYmUgY2FycmllZCBpbiBvcHRpb25hbCBzdWItVExWcyBvZiB0aGUgT3BlbiANCiAgICAg IG9iamVjdCAoY2FycmllZCBpbiB0aGUgT3BlbiBtZXNzYWdlKS48L1NQQU4+PC9GT05UPjwvRElW Pg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFO IA0KICAgICAgY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PkJ1dCB5b3UgYXJlIHJpZ2h0IHN1Y2gg Y2FwYWJpbGl0eSBpbmZvcm1hdGlvbiBtYXkgDQogICAgICBiZSBjYXJyaWVkIGluIFBDRVAuPC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIHNpemU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48L1NQQU4+ PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PlRoZSBp ZGVhJm5ic3A7d291bGQgYmUmbmJzcDt0byBjYXJyeSZuYnNwO3NpbXBsZSANCiAgICAgIGNhcGFi aWxpdGllcyZuYnNwO2luIHRoZSBJR1AgYW5kJm5ic3A7bW9yZSBjb21wbGV4IGNhcGFiaWxpdGll cyBpbiANCiAgICAgIFBDRVAuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgICAgIGNsYXNzPTUzODQ0 NDMxNi0wMjA2MjAwNj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICAg ICAgY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PkFueXdheSBJIGRvbid0IHJlYWxseSBzZWUgYW55 IGlzc3VlIGk8L1NQQU4+PFNQQU4gDQogICAgICBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+ZiB3 ZSBkZWZpbmUgdHdvIHdheXMgdG8mbmJzcDtjYXJyeSZuYnNwO3NvbWUgDQogICAgICBwaWVjZXMg b2YgaW5mb3JtYXRpb246PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRElWPg0KICAgICAg PERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAg Y2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2Pi1JR1AtYmFzZWQgY2FwYWJpbGl0eSBkaXNjb3Zlcnkg aXMgdXNlZnVsIGZvciANCiAgICAgIFBDQ3MgdGhhdCBkb24ndCBoYXZlIGEgUENFUCBzZXNzaW9u IHdpdGggdGhlIFBDRS48L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFz cz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgICAgIGNvbG9y PSMwMDAwZmY+PEZPTlQgc2l6ZT0yPi1QQ0VQLWJhc2VkIGNhcGFiaWxpdHkgZGlzY292ZXJ5IGlz IHVzZWZ1bCB3aGVuIA0KICAgICAgSUdQIGJhc2VkIGRpc2NvdmVyeSBpcyBub3QgYWN0aXZhdGVk LjxTUEFOIA0KICAgICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PiZuYnNwOzwvU1BBTj48L0ZP TlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tR VU9URT4NCiAgPERJViBkaXI9bHRyPjxTUEFOIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48Rk9O VCBmYWNlPUFyaWFsPjxGT05UIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYy MDA2PlRoaXMgc291bmRzIGZpbmUgdG8gDQogIG1lLjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgPERJViBkaXI9bHRyPjxTUEFOIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48 Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBzaXplPTI+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5 MDYyMDA2PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBk aXI9bHRyPjxTUEFOIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxG T05UIA0KICBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj5SZWdhcmRz LDwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyPjxTUEFO IGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBzaXpl PTI+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PlpoYW5nIDwvU1BBTj48L0ZPTlQ+PC9G T05UPjwvU1BBTj48L0RJVj4NCiAgPEJMT0NLUVVPVEUgZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJ TkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRF Ui1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgIDxCTE9D S1FVT1RFIGRpcj1sdHIgDQogICAgc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVG VDogNXB4OyBCT1JERVItTEVGVDogIzAwMDBmZiAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4 Ij4NCiAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTM4NDQ0MzE2LTAyMDYyMDA2PjxGT05UIGZhY2U9 QXJpYWw+PEZPTlQgDQogICAgICBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj48U1BBTiANCiAg ICAgIGNsYXNzPTU3NzE5MjgwNy0xOTA2MjAwNj48L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIw NjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgICAgIGNvbG9yPSMwMDAwZmY+PEZPTlQg c2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZP TlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNs YXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICAgICAgY29s b3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PlRo YW5rcyBmb3IgdGhlc2UgDQogICAgICBjb21tZW50cyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIwNjIw MDY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCiAgICAgIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6 ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+ PC9GT05UPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNz PTUzODQ0NDMxNi0wMjA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICAgICAgY29sb3I9 IzAwMDBmZj48Rk9OVCBzaXplPTI+PFNQQU4gDQogICAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIw MDY+UmVnYXJkcyw8L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAg ICAgPERJVj48U1BBTiBjbGFzcz01Mzg0NDQzMTYtMDIwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbD48 Rk9OVCANCiAgICAgIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xh c3M9NTc3MTkyODA3LTE5MDYyMDA2PjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxTUEFOIGNsYXNzPTUzODQ0NDMxNi0wMjA2MjAwNj48 Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICAgICAgY29sb3I9IzAwMDBmZj48Rk9OVCBzaXplPTI+ PFNQQU4gDQogICAgICBjbGFzcz01NzcxOTI4MDctMTkwNjIwMDY+SkwmbmJzcDs8L1NQQU4+PC9G T05UPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgICAgY2xhc3M9NTM4NDQ0MzE2LTAy MDYyMDA2PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogICAgICBjbGFzcz01Mzg0NDQzMTYt MDIwNjIwMDY+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+PC9GT05U PiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+PC9GT05UPiZuYnNw OzwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPUNvdXJpZXI+Q2hlZXJzLDwvRk9OVD48L0RJ Vj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAg ICAgIDxESVY+PEZPTlQgZmFjZT1Db3VyaWVyPlpoYW5nIA0KUmVuaGFpPC9GT05UPjwvRElWPjwv QkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C69436.4F771400-- --===============0433895303== 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 --===============0433895303==-- From pce-bounces@lists.ietf.org Wed Jun 21 13:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6Ob-0002gM-B4; Wed, 21 Jun 2006 13:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6Oa-0002gG-0Z for pce@ietf.org; Wed, 21 Jun 2006 13:21:40 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6OU-00042q-HH for pce@ietf.org; Wed, 21 Jun 2006 13:21:39 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1800CJ002ORI@usaga01-in.huawei.com> for pce@ietf.org; Wed, 21 Jun 2006 10:18:25 -0700 (PDT) Received: from Yong73674 (futurewei.com [65.104.224.98]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1800D2X02IMX@usaga01-in.huawei.com> for pce@ietf.org; Wed, 21 Jun 2006 10:18:24 -0700 (PDT) Date: Wed, 21 Jun 2006 12:21:27 -0500 From: Lucy Yong Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp In-reply-to: To: 'LE ROUX Jean-Louis RD-CORE-LAN' , 'Zhang Renhai' , pce@ietf.org Message-id: <009601c69557$21a6a2e0$0202a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcaUHWB0qx9ZyqXOSBKUfPHjK+w2XAAFm2rwAEgxYnA= X-Spam-Score: 0.0 (/) X-Scan-Signature: ebec7ca71b0ffe303cd4359f11c64568 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="===============0763540190==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0763540190== Content-type: multipart/alternative; boundary="Boundary_(ID_mQzw7HqjDBH/IXqq5zejqg)" This is a multi-part message in MIME format. --Boundary_(ID_mQzw7HqjDBH/IXqq5zejqg) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Hello JLLR, =20 The draft covers various discovery requirements as mentioned in section = 4.2. Good work. Once thing I would like to get clarification is that the draft focus on = the discovery between a PCC and a PCE, a PCE and domains that the PCE = has visibility and can compute paths, and a PCE and domains that the PCE = can compute paths toward. The draft also mentions that PCE information = is disclosed to PCC. =20 >From these set of discoveries, I could not see if the discoveries also = include the discovery between PCEs and information changes between PCEs. = Maybe I miss them in context. Could you help to clarify? =20 =20 Best Regards, Lucy=20 =20 _____ =20 From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@orange-ft.com]=20 Sent: Tuesday, June 20, 2006 1:54 AM To: Zhang Renhai; pce@ietf.org Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp =20 Hi Zhang, =20 Please see inline, =20 _____ =20 De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 Envoy=C3=A9 : mardi 20 juin 2006 05:26 =C3=80 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org Objet : Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp Hi, Jean-Louis =20 See inline, please. ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN = =20 To: Zhang Renhai ; pce@ietf.org=20 Sent: Monday, June 19, 2006 4:23 PM Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp =20 Hi Zhang =20 Thanks for your comments =20 Please see inline, =20 _____ =20 De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 Envoy=C3=A9 : mardi 13 juin 2006 09:07 =C3=80 : pce@ietf.org Objet : [Pce] Comments on draft-ietf-pce-disco-proto-igp Hi, all =20 I recently read the draft draft-ietf-pce-disco-proto-igp again, here are = some comments=E3=80=82 =20 When IGP is used as a PCED protocol, the capabilities of pce will be = advertised periodicly along with other lsa/lsp information. In my = opinion, unless the PCE's capabilities change, there is no need for the = PCC to receive and handle the information again. =20 =20 JLLR: But these are standard IGP procedures. This is the same for link = states, they are refreshed even if there is not change. By the way the = refresh interval can be quite large (e.g. 18 hours for IS-IS). =20 =20 =20 Furthermore, if most of the routers in a domain will always have no = request to a PCE, there is also no need for them to maintain the = information. =20 =20 JLLR: In this case PCE discovery is deactivated on these routers and = they will not process the PCED and PCES TLVs... But I don't know if it is possible for a router to be re-configured as a = PCC or have some path computation request after it receives these TLVs = and not processes them, =20 =20 Now if a router is configured as PCC at some point in time, then it = starts processing information carried in PCED and PCES TLVs...(Before = you activate PCE discovery on the PCC the information is stored but not = processed). =20 =20 =20 My concern to PCE-DEST-DOMAINS sub-TLV is that we can't anticipate how = many destination domains a PCE can computate path towards, as a = result,the length of space taken by this capality in the message can't = be controlled. =20 =20 JLLR: Actually you have the same problem with the number of TE-links = advertised by an LSR or the number of reacheable prefixes advertised by = an ABR.=20 One may limit by configuration the number of dest domains advertised. But I still doubt that if it's needed for the PCE to maintain such = information and how a PCE obtains these info?=20 As discussed latter this is a really useful feature that helps PCE = selection and load balancing. In the inter-area case, the can learn this info both via config and via = the IGP (e.g. if the PCE is an ABR, it can easily know attached areas). In the inter-AS case, the PCE can learn this information both via config = and via BGP.=20 =20 =20 So I think if the PCC send a request to a PCE which can't compute the = path for the reason of the destination domain, the PCE can tell the PCC = in the PCrep message the right PCE. =20 =20 JLLR: But how the PCE will have the information? =20 One additional quesion: is it suitable for the PCE to have such ability = to know exactly the destination domain it can compute towards?=20 =20 JLLR: This is actually required. For instance in an inter-AS case, an AS = may be connected to multiple ASs, and there may be multiple PCEs in this = AS (e.g. ASBRs), each responsible for computing path towards a given = neighbord AS. Here you said the neighboring AS, but not the destination AS.=20 =20 It was an example where the destination is located in the neighboring = AS... But the same applies when the destination is located farther. =20 Thanks=20 =20 JL =20 Some functions specified in the PATH-CAMP-CAP sub-TLV are also defined = in the PCEP, a clear division should be made. =20 =20 JLLR: Actually, at the time being the PCEP spec does not define any = capability information. In current PCEP spec, we only mention that detailed capabilites could be = carried in optional sub-TLVs of the Open object (carried in the Open = message). But you are right such capability information may be carried in PCEP. =20 The idea would be to carry simple capabilities in the IGP and more = complex capabilities in PCEP. =20 Anyway I don't really see any issue if we define two ways to carry some = pieces of information: -IGP-based capability discovery is useful for PCCs that don't have a = PCEP session with the PCE. -PCEP-based capability discovery is useful when IGP based discovery is = not activated.=20 This sounds fine to me. =20 Regards, Zhang=20 =20 =20 Thanks for these comments, =20 Regards, =20 JL=20 =20 =20 =20 =20 Cheers, =20 Zhang Renhai --Boundary_(ID_mQzw7HqjDBH/IXqq5zejqg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable =EF=BB=BF

Hello = JLLR,

 

The draft covers various = discovery requirements as mentioned in section 4.2. Good = work.

Once thing I would like to get = clarification is that the draft focus on the discovery between a PCC and a PCE, a PCE = and domains that the PCE has visibility and can compute paths, and a PCE and domains that the PCE can compute paths toward. The draft also mentions = that PCE information is disclosed to PCC.

 

From these set of discoveries, I = could not see if the discoveries also include the discovery between PCEs and information changes between PCEs. Maybe I miss them in context. Could = you help to clarify? =C2=A0

 

Best = Regards,

Lucy =

 

From: = LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux@orange-ft.com]
Sent: Tuesday, June 20, = 2006 1:54 AM
To: Zhang Renhai; = pce@ietf.org
Subject: RE: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

 

Hi = Zhang,

 

Please see = inline,

 

De :<= /span> Zhang Renhai [mailto:zhangrenhai@huawei.com]
Envoy=C3=A9 : mardi = 20 juin 2006 05:26
=C3=80 : LE ROUX = Jean-Louis RD-CORE-LAN; pce@ietf.org
Objet : Re: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

Hi, = Jean-Louis

 

See inline, = please.

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

Sent:<= font size=3D1 face=3D=E5=AE=8B=E4=BD=93> Monday, June = 19, 2006 4:23 PM

Subject: RE: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

 

Hi = Zhang

 

Thanks for your = comments

 

Please see = inline,

 

De :<= /span> Zhang Renhai [mailto:zhangrenhai@huawei.com]
Envoy=C3=A9 : mardi = 13 juin 2006 09:07
=C3=80 : pce@ietf.org
Objet : [Pce] = Comments on draft-ietf-pce-disco-proto-igp

Hi, all

 

I recently read the draft = draft-ietf-pce-disco-proto-igp again, here are some comments=E3=80=82

 

When IGP is used as a PCED protocol, the = capabilities of pce will be advertised periodicly along with other lsa/lsp = information. In my opinion, unless the PCE's capabilities change,  there is no need = for the PCC to receive and handle the information = again.  

 

JLLR: But these are standard IGP procedures. This is the same for link states, they are refreshed even if = there is not change. By the way the refresh interval can be quite large (e.g. = 18 hours for IS-IS).

 

 

 

 Furthermore, if most of the routers in a = domain will always have no request to a PCE, there is also no need for them to = maintain the information.  

 

JLLR: In this case PCE discovery is deactivated on these routers and they will not process the PCED and PCES TLVs...

But I don't know if it is possible = for a router to be re-configured as a PCC or have some path = computation request after it receives these TLVs and not processes = them,  

 

=

Now if a router is configured as = PCC at some point in time, then it starts processing information carried in PCED and PCES TLVs...(Before you activate PCE discovery on = the PCC the information is stored but not processed).

 

=

 

 

My concern to PCE-DEST-DOMAINS sub-TLV is that = we can't anticipate how many destination domains a PCE can  computate = path towards, as a result,the length of space taken by this capality in = the message can't be controlled.  

 

JLLR: Actually you have the same = problem with the number of TE-links advertised by an LSR or the number of reacheable prefixes advertised by an ABR.

One may limit by configuration the = number of dest domains advertised.

But I still doubt that if it's needed for the PCE to maintain such information and how a PCE obtains these info? 

As discussed latter this is a = really useful feature that helps PCE selection and load = balancing.

In the inter-area case, the = can learn this info both via config and via the IGP (e.g. if the PCE is an ABR, it = can easily know attached areas).

In the inter-AS case, the PCE can = learn this information both via config and via = BGP. 

 

 

 So I think if the PCC send a request to a PCE = which can't compute the path for the reason of the destination domain, the PCE = can tell the PCC in the PCrep message the right = PCE.  

 

JLLR: But how the PCE will have the information?

 

 One additional quesion: is it suitable for = the PCE to have such ability to know exactly the destination domain it can = compute towards? 

 

JLLR: This is = actually required. For instance in an inter-AS case, an AS may be connected to multiple ASs, and there may be multiple PCEs in this AS (e.g. ASBRs), each = responsible for computing path towards a given neighbord = AS.

Here you said the neighboring AS, but not the = destination AS. 

 

It was an example where the = destination is located in the neighboring AS... But the same applies when the = destination is located farther.

 

Thanks =

 

JL

 

Some functions specified in the PATH-CAMP-CAP = sub-TLV are also defined in the PCEP,  a clear division should be made.  

 

 JLLR:  Actually, at the = time being the PCEP spec does not define any capability = information.

In current PCEP spec, we only = mention that detailed capabilites could be carried in optional sub-TLVs of the Open = object (carried in the Open message).

But you are right such capability information may be carried in PCEP.

 

The idea would be to carry simple capabilities in the IGP and more complex capabilities in PCEP.

 

Anyway I don't really see any issue = if we define two ways to carry some pieces of = information:

-IGP-based capability discovery is = useful for PCCs that don't have a PCEP session with the = PCE.

-PCEP-based capability discovery is = useful when IGP based discovery is not = activated. 

This sounds fine to me.

 

Regards,

Zhang

 

 

Thanks for these = comments,

 

Regards,

 

JL 

 

 

 

 

Cheers,

 

Zhang Renhai

--Boundary_(ID_mQzw7HqjDBH/IXqq5zejqg)-- --===============0763540190== 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 --===============0763540190==-- From pce-bounces@lists.ietf.org Wed Jun 21 20:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCfa-0006HU-CC; Wed, 21 Jun 2006 20:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCfZ-0006HN-Jk for pce@ietf.org; Wed, 21 Jun 2006 20:03:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCfY-0000sy-Cd for pce@ietf.org; Wed, 21 Jun 2006 20:03:37 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2006 17:03:36 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,163,1149490800"; d="scan'208,217"; a="30190254:sNHT37052688" 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 k5M03Zno002255; Wed, 21 Jun 2006 20:03:35 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 20:03:35 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 20:03:35 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: pce@ietf.org Message-Id: <5B545FD4-F467-489A-B457-F39EA3B2527D@cisco.com> Subject: [Pce] Incremental limited WG LC on draft-ietf-pce-discovery-reqs-05.txt ended From: JP Vasseur Date: Wed, 21 Jun 2006 20:03:22 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 Jun 2006 00:03:35.0250 (UTC) FILETIME=[4E42CB20:01C6958F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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="===============0246839916==" Errors-To: pce-bounces@lists.ietf.org --===============0246839916== Content-Type: multipart/alternative; boundary=Apple-Mail-31-828710719 --Apple-Mail-31-828710719 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed WG, The incremental WG on [Pce] Incremental limited WG LC on draft-ietf- pce-discovery-reqs-05.txt has ended, with no further comment. Thus we can move forward on this ID. Thanks. JP. --Apple-Mail-31-828710719 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 WG,

The incremental WG = on=A0[Pce] Incremental limited WG LC on = draft-ietf-pce-discovery-reqs-05.txt=A0has ended, with no further = comment.

Thus we can = move forward on this ID.

Thanks.

References: <009601c69557$21a6a2e0$0202a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <162E039E-6BF4-4673-8C5B-BCA4B3DF2162@cisco.com> From: JP Vasseur Subject: Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp Date: Wed, 21 Jun 2006 20:07:39 -0400 To: Lucy Yong X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 Jun 2006 00:07:56.0768 (UTC) FILETIME=[EA234600:01C6958F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d7967c711acf4eec6f9b62d49dcc5a34 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="===============0841984552==" Errors-To: pce-bounces@lists.ietf.org --===============0841984552== Content-Type: multipart/alternative; boundary=Apple-Mail-33-828970761 --Apple-Mail-33-828970761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Hi, On Jun 21, 2006, at 1:21 PM, Lucy Yong wrote: > Hello JLLR, > > > > The draft covers various discovery requirements as mentioned in =20 > section 4.2. Good work. > > Once thing I would like to get clarification is that the draft =20 > focus on the discovery between a PCC and a PCE, a PCE and domains =20 > that the PCE has visibility and can compute paths, and a PCE and =20 > domains that the PCE can compute paths toward. The draft also =20 > mentions that PCE information is disclosed to PCC. > > > > =46rom these set of discoveries, I could not see if the discoveries =20= > also include the discovery between PCEs and information changes =20 > between PCEs. Maybe I miss them in context. Could you help to clarify? > > yes it does. PCE originates IGP updates announcing their capabilities =20= that can be processed by the PCCs or PCEs (acting a PCCs). JP. > > > Best Regards, > > Lucy > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@orange-ft.com] > Sent: Tuesday, June 20, 2006 1:54 AM > To: Zhang Renhai; pce@ietf.org > Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp > > > > Hi Zhang, > > > > Please see inline, > > > > De : Zhang Renhai [mailto:zhangrenhai@huawei.com] > Envoy=C3=A9 : mardi 20 juin 2006 05:26 > =C3=80 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > Objet : Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp > > Hi, Jean-Louis > > > > See inline, please. > > ----- Original Message ----- > > From: LE ROUX Jean-Louis RD-CORE-LAN > > To: Zhang Renhai ; pce@ietf.org > > Sent: Monday, June 19, 2006 4:23 PM > > Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp > > > > Hi Zhang > > > > Thanks for your comments > > > > Please see inline, > > > > De : Zhang Renhai [mailto:zhangrenhai@huawei.com] > Envoy=C3=A9 : mardi 13 juin 2006 09:07 > =C3=80 : pce@ietf.org > Objet : [Pce] Comments on draft-ietf-pce-disco-proto-igp > > Hi, all > > > > I recently read the draft draft-ietf-pce-disco-proto-igp again, =20 > here are some comments=E3=80=82 > > > > When IGP is used as a PCED protocol, the capabilities of pce will =20 > be advertised periodicly along with other lsa/lsp information. In =20 > my opinion, unless the PCE's capabilities change, there is no need =20= > for the PCC to receive and handle the information again. > > > > JLLR: But these are standard IGP procedures. This is the same for =20 > link states, they are refreshed even if there is not change. By the =20= > way the refresh interval can be quite large (e.g. 18 hours for IS-IS). > > > > > > > > Furthermore, if most of the routers in a domain will always have =20 > no request to a PCE, there is also no need for them to maintain the =20= > information. > > > > JLLR: In this case PCE discovery is deactivated on these routers =20 > and they will not process the PCED and PCES TLVs... > > But I don't know if it is possible for a router to be re-configured =20= > as a PCC or have some path computation request after it receives =20 > these TLVs and not processes them, > > > > Now if a router is configured as PCC at some point in time, then it =20= > starts processing information carried in PCED and PCES TLVs...=20 > (Before you activate PCE discovery on the PCC the information is =20 > stored but not processed). > > > > > > > > My concern to PCE-DEST-DOMAINS sub-TLV is that we can't anticipate =20 > how many destination domains a PCE can computate path towards, as =20 > a result,the length of space taken by this capality in the message =20 > can't be controlled. > > > > JLLR: Actually you have the same problem with the number of TE-=20 > links advertised by an LSR or the number of reacheable prefixes =20 > advertised by an ABR. > > One may limit by configuration the number of dest domains advertised. > > But I still doubt that if it's needed for the PCE to maintain such =20 > information and how a PCE obtains these info? > > As discussed latter this is a really useful feature that helps PCE =20 > selection and load balancing. > > In the inter-area case, the can learn this info both via config and =20= > via the IGP (e.g. if the PCE is an ABR, it can easily know attached =20= > areas). > > In the inter-AS case, the PCE can learn this information both via =20 > config and via BGP. > > > > > > So I think if the PCC send a request to a PCE which can't compute =20 > the path for the reason of the destination domain, the PCE can tell =20= > the PCC in the PCrep message the right PCE. > > > > JLLR: But how the PCE will have the information? > > > > One additional quesion: is it suitable for the PCE to have such =20 > ability to know exactly the destination domain it can compute towards? > > > > JLLR: This is actually required. For instance in an inter-AS case, =20 > an AS may be connected to multiple ASs, and there may be multiple =20 > PCEs in this AS (e.g. ASBRs), each responsible for computing path =20 > towards a given neighbord AS. > > Here you said the neighboring AS, but not the destination AS. > > > > It was an example where the destination is located in the =20 > neighboring AS... But the same applies when the destination is =20 > located farther. > > > > Thanks > > > > JL > > > > Some functions specified in the PATH-CAMP-CAP sub-TLV are also =20 > defined in the PCEP, a clear division should be made. > > > > JLLR: Actually, at the time being the PCEP spec does not define =20 > any capability information. > > In current PCEP spec, we only mention that detailed capabilites =20 > could be carried in optional sub-TLVs of the Open object (carried =20 > in the Open message). > > But you are right such capability information may be carried in PCEP. > > > > The idea would be to carry simple capabilities in the IGP and more =20 > complex capabilities in PCEP. > > > > Anyway I don't really see any issue if we define two ways to carry =20 > some pieces of information: > > -IGP-based capability discovery is useful for PCCs that don't have =20 > a PCEP session with the PCE. > > -PCEP-based capability discovery is useful when IGP based discovery =20= > is not activated. > > This sounds fine to me. > > > > Regards, > > Zhang > > > > > > Thanks for these comments, > > > > Regards, > > > > JL > > > > > > > > > > Cheers, > > > > Zhang Renhai > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-33-828970761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi,

On Jun 21, = 2006, at 1:21 PM, Lucy Yong wrote:

Hello = JLLR,

=C2=A0

=

The draft covers various = discovery requirements as mentioned in section 4.2. Good = work.

Once thing I would like to get = clarification is that the draft focus on the discovery between a PCC and = a PCE, a PCE and domains that the PCE has visibility and can compute = paths, and a PCE and domains that the PCE can compute paths toward. The = draft also mentions that PCE information is disclosed to = PCC.

=C2=A0

=

=46rom these set of discoveries, = I could not see if the discoveries also include the discovery between = PCEs and information changes between PCEs. Maybe I miss them in context. = Could you help to clarify? =C2=A0


yes it does. PCE = originates IGP updates announcing their capabilities that can be = processed by the PCCs or PCEs (acting a PCCs).

JP.

=C2=A0

=

Best = Regards,

Lucy =

=C2=A0

=

From: LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux@ora= nge-ft.com]
Sent: = Tuesday, June 20, 2006 1:54 AM
To: Zhang Renhai; pce@ietf.org
Subject: RE: [Pce] Comments on = draft-ietf-pce-disco-proto-igp

=C2=A0

Hi = Zhang,

=C2=A0

Please see = inline,

=

=C2=A0

De=C2=A0: Zhang Renhai [mailto:zhangrenhai@huawei.com] =
Envoy=C3=A9=C2=A0: = mardi 20 juin 2006 05:26
=C3=80=C2=A0: LE ROUX Jean-Louis = RD-CORE-LAN; pce@ietf.org
= Objet=C2=A0: Re: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

Hi, = Jean-Louis

=C2=A0

=

<= SPAN style=3D"font-size:10.0pt; font-family:=E5=AE=8B=E4=BD=93">See = inline, please.

=

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

Sent: Monday, June = 19, 2006 4:23 PM

Subject: RE: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

=

=C2=A0

Hi = Zhang

=C2=A0

Thanks for your = comments

=C2=A0

Please see = inline,

=

=C2=A0

De=C2=A0: Zhang Renhai [mailto:zhangrenhai@huawei.com] =
Envoy=C3=A9=C2=A0: = mardi 13 juin 2006 09:07
=C3=80=C2=A0: pce@ietf.org
Objet=C2=A0: [Pce] Comments on = draft-ietf-pce-disco-proto-igp

Hi, all

=C2=A0

=

I recently read the = draft draft-ietf-pce-disco-proto-igp again, here are some = comments=E3=80=82

=C2=A0

When IGP is used=C2=A0as = a PCED protocol, the capabilities of pce will be advertised periodicly = along with other lsa/lsp information. In my opinion, unless the PCE's = capabilities change,=C2=A0 there is no need for the PCC to receive = and=C2=A0handle the information again.=C2=A0=C2=A0

=C2=A0

=

JLLR: But these are standard IGP = procedures. This is the same for link states, they are refreshed even if = there is not change. By the way the refresh interval can be quite large = (e.g. 18 hours for IS-IS).

=C2=A0

=

=C2=A0

=C2=A0

=C2=A0Furthermore, if most of the routers in a = domain will always have no request to a PCE, there is also no need for = them to maintain the information.=C2=A0=C2=A0

=C2=A0

JLLR: In this = case PCE discovery is deactivated on these routers and they will not = process the PCED and PCES TLVs...

=

But I don't know if it is possible = for a router to be re-configured=C2=A0as a PCC or have some=C2=A0path = computation request=C2=A0after=C2=A0it receives these TLVs and not = processes them,=C2=A0=C2=A0

=C2=A0

=

Now if a router is configured as = PCC at some point in time, then=C2=A0it=C2=A0starts = processing=C2=A0information carried in PCED and PCES TLVs...(Before you = activate PCE discovery on the PCC the information is stored but not = processed).

=C2=A0

=
=
=

=C2=A0

=C2=A0

My concern to PCE-DEST-DOMAINS sub-TLV=C2=A0is that = we can't anticipate how many destination domains a PCE can =C2=A0computate= path towards,=C2=A0as a result,the length of space taken by this = capality in the message can't be controlled.=C2=A0=C2=A0

=C2=A0

JLLR: Actually = you have the same problem with the number of TE-links advertised by=C2=A0a= n LSR or the number of reacheable prefixes advertised by an ABR. =

One may limit by configuration the = number of dest domains advertised.

=

But I = still doubt that if it's needed for the PCE to maintain such information = and how a PCE obtains these info?=C2=A0

=

As discussed latter this is a = really useful feature that helps PCE selection and load = balancing.

In=C2=A0the = inter-area case, the can learn this info both via config and via the IGP = (e.g. if the PCE is an ABR, it can easily know attached = areas).

In the inter-AS = case, the PCE can learn this information both=C2=A0via=C2=A0config=C2=A0an= d via BGP.=C2=A0

=
=

=C2=A0

=C2=A0

=C2=A0So I think if the PCC send a request to a PCE = which can't compute the path for the reason of the destination domain, = the PCE can tell the PCC in the PCrep message=C2=A0the right = PCE.=C2=A0=C2=A0

=C2=A0

=

JLLR: But how the PCE will have the = information?

=C2=A0

=

=C2=A0One additional = quesion: is it suitable for the PCE to have such ability to know exactly = the destination domain it can compute towards?=C2=A0

=C2=A0

JLLR: This is = actually=C2=A0required. For instance in an inter-AS case, an AS may be = connected to multiple ASs, and=C2=A0there may be multiple PCEs in this = AS (e.g. ASBRs), each responsible for computing path towards a given = neighbord AS.

=

Here = you said the neighboring AS, but not the destination AS.=C2=A0

=

=C2=A0

It was an example where the = destination is located in the neighboring AS... But the same applies = when the destination is located farther.

=

=C2=A0

Thanks =

=C2=A0

JL

=
=
=

=C2=A0

Some functions specified in the PATH-CAMP-CAP = sub-TLV are also=C2=A0defined=C2=A0in the PCEP,=C2=A0 a clear division = should be made.=C2=A0=C2=A0

=C2=A0

=C2=A0JLLR: = =C2=A0Actually, at the time being the PCEP spec does not define any = capability information.

In current PCEP = spec, we only mention that detailed capabilites could be carried in = optional sub-TLVs of the Open object (carried in the Open = message).

But you are = right such capability information may be carried in = PCEP.

=C2=A0

=

The idea=C2=A0would be=C2=A0to = carry=C2=A0simple capabilities=C2=A0in the IGP and=C2=A0more complex = capabilities in PCEP.

=C2=A0

=

Anyway I don't really see any issue = if we define two ways to=C2=A0carry=C2=A0some pieces of = information:

-IGP-based = capability discovery is useful for PCCs that don't have a PCEP session = with the PCE.

-PCEP-based = capability discovery is useful when IGP based discovery is not = activated.=C2=A0

=

This = sounds fine to me.

=C2=A0

=

Regards,

Zhang =

=
=

=C2=A0

=C2=A0

Thanks for these = comments,

=C2=A0

=

Regards,

=

=C2=A0

JL=C2=A0

=

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Cheers,

=C2=A0

=

Zhang = Renhai

=
Pce mailing list
=

= --Apple-Mail-33-828970761-- --===============0841984552== 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 --===============0841984552==-- From pce-bounces@lists.ietf.org Thu Jun 22 07:26:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNKL-0007R0-8H; Thu, 22 Jun 2006 07:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNCy-000345-RC for pce@ietf.org; Thu, 22 Jun 2006 07:18:48 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNCx-0004vj-3n for pce@ietf.org; Thu, 22 Jun 2006 07:18:48 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 08:30:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: TR: [Pce] Comments on draft-ietf-pce-disco-proto-igp Date: Thu, 22 Jun 2006 08:30:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-igp Thread-Index: AcaUHWB0qx9ZyqXOSBKUfPHjK+w2XAAFm2rwAEgxYnAAALqUQAAbZkRA From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "Zhang Renhai" , X-OriginalArrivalTime: 22 Jun 2006 06:30:30.0207 (UTC) FILETIME=[5B741CF0:01C695C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: baa5f0d7df7d67a6bff4df65bb02daf5 X-Mailman-Approved-At: Thu, 22 Jun 2006 07:26:23 -0400 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="===============0202119557==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0202119557== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C695C5.5B241063" This is a multi-part message in MIME format. ------_=_NextPart_001_01C695C5.5B241063 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U2VudCBhZ2Fpbg0KVGhpcyBlbWFpbCB3YXMgbm90IHJlY2VpdmVkIG9uIHRoZSBwY2UgbGlzdC4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoJRGUgOiBMRSBST1VYIEpl YW4tTG91aXMgUkQtQ09SRS1MQU4gDQoJRW52b3nDqSA6IG1lcmNyZWRpIDIxIGp1aW4gMjAwNiAx OTozMg0KCcOAIDogJ0x1Y3kgWW9uZyc7ICdaaGFuZyBSZW5oYWknOyBwY2VAaWV0Zi5vcmcNCglP YmpldCA6IFJFOiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1p Z3ANCgkNCgkNCglIaSBMdWN5LA0KCSANCglUaGFua3MgZm9yIHRoaXMgZmVlZGJhY2ssDQoJIA0K CUEgUENFIHRoYXQgc2VuZHMgYSByZXF1ZXN0IHRvIGFub3RoZXIgUENFIGNhbiBiZSBjb25zaWRl cmVkIGFzIGEgUENDLCBpdCBpcyBhY3R1YWxseSBhY3RpbmcgYXMgYSBQQ0MuIEhlbmNlLCBhcyBk aXNjdXNzZWQgaW4gdGhlIHJlcXVpcmVtZW50IElELCB0aGVyZSBpcyBubyBuZWVkIHRvLCBhbmQg d2UgZG8gbm90LCBtYWtlIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRpc2NvdmVyeSBieSBQQ0Nz IGFuZCBkaXNjb3ZlcnkgYnkgUENFcy4uLg0KCUEgUENFIHRoYXQgd2FudHMgdG8gZGlzY292ZXIg b3RoZXIgUENFcyBpbiB0aGUgSUdQIGRvbWFpbiBzaW1wbHkgbmVlZHMgdG8gbGlzdGVuIHRvIElH UCBhZHZlcnRpc2VtZW50cyBkZWZpbmVkIGluIHRoaXMgZHJhZnQgIChpLmUuIGl0IGFjdHMgYXMg YSBQQ0MpLg0KCSANCglIb3BlIHRoaXMgY2xhcmlmaWVzDQoJIA0KCUJlc3QgUmVnYXJkcywNCgkg DQoJSkwNCgkgDQoJIA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCgkJ RGUgOiBMdWN5IFlvbmcgW21haWx0bzpsdWN5eW9uZ0BodWF3ZWkuY29tXSANCgkJRW52b3nDqSA6 IG1lcmNyZWRpIDIxIGp1aW4gMjAwNiAxOToyMQ0KCQnDgCA6IExFIFJPVVggSmVhbi1Mb3VpcyBS RC1DT1JFLUxBTjsgJ1poYW5nIFJlbmhhaSc7IHBjZUBpZXRmLm9yZw0KCQlPYmpldCA6IFJFOiBb UGNlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3ANCgkJDQoJCQ0K DQoJCUhlbGxvIEpMTFIsDQoNCgkJIA0KDQoJCVRoZSBkcmFmdCBjb3ZlcnMgdmFyaW91cyBkaXNj b3ZlcnkgcmVxdWlyZW1lbnRzIGFzIG1lbnRpb25lZCBpbiBzZWN0aW9uIDQuMi4gR29vZCB3b3Jr Lg0KDQoJCU9uY2UgdGhpbmcgSSB3b3VsZCBsaWtlIHRvIGdldCBjbGFyaWZpY2F0aW9uIGlzIHRo YXQgdGhlIGRyYWZ0IGZvY3VzIG9uIHRoZSBkaXNjb3ZlcnkgYmV0d2VlbiBhIFBDQyBhbmQgYSBQ Q0UsIGEgUENFIGFuZCBkb21haW5zIHRoYXQgdGhlIFBDRSBoYXMgdmlzaWJpbGl0eSBhbmQgY2Fu IGNvbXB1dGUgcGF0aHMsIGFuZCBhIFBDRSBhbmQgZG9tYWlucyB0aGF0IHRoZSBQQ0UgY2FuIGNv bXB1dGUgcGF0aHMgdG93YXJkLiBUaGUgZHJhZnQgYWxzbyBtZW50aW9ucyB0aGF0IFBDRSBpbmZv cm1hdGlvbiBpcyBkaXNjbG9zZWQgdG8gUENDLg0KDQoJCSANCg0KCQlGcm9tIHRoZXNlIHNldCBv ZiBkaXNjb3ZlcmllcywgSSBjb3VsZCBub3Qgc2VlIGlmIHRoZSBkaXNjb3ZlcmllcyBhbHNvIGlu Y2x1ZGUgdGhlIGRpc2NvdmVyeSBiZXR3ZWVuIFBDRXMgYW5kIGluZm9ybWF0aW9uIGNoYW5nZXMg YmV0d2VlbiBQQ0VzLiBNYXliZSBJIG1pc3MgdGhlbSBpbiBjb250ZXh0LiBDb3VsZCB5b3UgaGVs cCB0byBjbGFyaWZ5PyAgDQoNCgkJIA0KDQoJCUJlc3QgUmVnYXJkcywNCg0KCQlMdWN5IA0KDQoJ CSANCg0KCQkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KCQlGcm9tOiBM RSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4gW21haWx0bzpqZWFubG91aXMubGVyb3V4QG9y YW5nZS1mdC5jb21dIA0KCQlTZW50OiBUdWVzZGF5LCBKdW5lIDIwLCAyMDA2IDE6NTQgQU0NCgkJ VG86IFpoYW5nIFJlbmhhaTsgcGNlQGlldGYub3JnDQoJCVN1YmplY3Q6IFJFOiBbUGNlXSBDb21t ZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3ANCg0KCQkgDQoNCgkJSGkgWmhh bmcsDQoNCgkJIA0KDQoJCVBsZWFzZSBzZWUgaW5saW5lLA0KDQoJCQkgDQoNCgkJCQ0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoJCQlEZSA6IFpoYW5nIFJlbmhhaSBbbWFp bHRvOnpoYW5ncmVuaGFpQGh1YXdlaS5jb21dIA0KCQkJRW52b3nDqSA6IG1hcmRpIDIwIGp1aW4g MjAwNiAwNToyNg0KCQkJw4AgOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU47IHBjZUBp ZXRmLm9yZw0KCQkJT2JqZXQgOiBSZTogW1BjZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1wY2Ut ZGlzY28tcHJvdG8taWdwDQoNCgkJCUhpLCBKZWFuLUxvdWlzDQoNCgkJCSANCg0KCQkJU2VlIGlu bGluZSwgcGxlYXNlLg0KDQoJCQkJLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCg0KCQkJ CUZyb206IExFIFJPVVggSmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiA8bWFpbHRvOmplYW5sb3Vpcy5s ZXJvdXhAb3JhbmdlLWZ0LmNvbT4gIA0KDQoJCQkJVG86IFpoYW5nIFJlbmhhaSA8bWFpbHRvOnpo YW5ncmVuaGFpQGh1YXdlaS5jb20+ICA7IHBjZUBpZXRmLm9yZyANCg0KCQkJCVNlbnQ6IE1vbmRh eSwgSnVuZSAxOSwgMjAwNiA0OjIzIFBNDQoNCgkJCQlTdWJqZWN0OiBSRTogW1BjZV0gQ29tbWVu dHMgb24gZHJhZnQtaWV0Zi1wY2UtZGlzY28tcHJvdG8taWdwDQoNCgkJCQkgDQoNCgkJCQlIaSBa aGFuZw0KDQoJCQkJIA0KDQoJCQkJVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzDQoNCgkJCQkgDQoN CgkJCQlQbGVhc2Ugc2VlIGlubGluZSwNCg0KCQkJCQkgDQoNCgkJCQkJDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQoNCgkJCQkJRGUgOiBaaGFuZyBSZW5oYWkgW21haWx0bzp6 aGFuZ3JlbmhhaUBodWF3ZWkuY29tXSANCgkJCQkJRW52b3nDqSA6IG1hcmRpIDEzIGp1aW4gMjAw NiAwOTowNw0KCQkJCQnDgCA6IHBjZUBpZXRmLm9yZw0KCQkJCQlPYmpldCA6IFtQY2VdIENvbW1l bnRzIG9uIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncA0KDQoJCQkJCUhpLCBhbGwNCg0K CQkJCQkgDQoNCgkJCQkJSSByZWNlbnRseSByZWFkIHRoZSBkcmFmdCBkcmFmdC1pZXRmLXBjZS1k aXNjby1wcm90by1pZ3AgYWdhaW4sIGhlcmUgYXJlIHNvbWUgY29tbWVudHPjgIINCg0KCQkJCQkg DQoNCgkJCQkJV2hlbiBJR1AgaXMgdXNlZCBhcyBhIFBDRUQgcHJvdG9jb2wsIHRoZSBjYXBhYmls aXRpZXMgb2YgcGNlIHdpbGwgYmUgYWR2ZXJ0aXNlZCBwZXJpb2RpY2x5IGFsb25nIHdpdGggb3Ro ZXIgbHNhL2xzcCBpbmZvcm1hdGlvbi4gSW4gbXkgb3BpbmlvbiwgdW5sZXNzIHRoZSBQQ0UncyBj YXBhYmlsaXRpZXMgY2hhbmdlLCAgdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIFBDQyB0byByZWNl aXZlIGFuZCBoYW5kbGUgdGhlIGluZm9ybWF0aW9uIGFnYWluLiAgDQoNCgkJCQkJIA0KDQoJCQkJ CUpMTFI6IEJ1dCB0aGVzZSBhcmUgc3RhbmRhcmQgSUdQIHByb2NlZHVyZXMuIFRoaXMgaXMgdGhl IHNhbWUgZm9yIGxpbmsgc3RhdGVzLCB0aGV5IGFyZSByZWZyZXNoZWQgZXZlbiBpZiB0aGVyZSBp cyBub3QgY2hhbmdlLiBCeSB0aGUgd2F5IHRoZSByZWZyZXNoIGludGVydmFsIGNhbiBiZSBxdWl0 ZSBsYXJnZSAoZS5nLiAxOCBob3VycyBmb3IgSVMtSVMpLg0KDQoJCQkJCSANCg0KCQkJCQkgDQoN CgkJCQkJIA0KDQoJCQkJCSBGdXJ0aGVybW9yZSwgaWYgbW9zdCBvZiB0aGUgcm91dGVycyBpbiBh IGRvbWFpbiB3aWxsIGFsd2F5cyBoYXZlIG5vIHJlcXVlc3QgdG8gYSBQQ0UsIHRoZXJlIGlzIGFs c28gbm8gbmVlZCBmb3IgdGhlbSB0byBtYWludGFpbiB0aGUgaW5mb3JtYXRpb24uICANCg0KCQkJ CQkgDQoNCgkJCQkJSkxMUjogSW4gdGhpcyBjYXNlIFBDRSBkaXNjb3ZlcnkgaXMgZGVhY3RpdmF0 ZWQgb24gdGhlc2Ugcm91dGVycyBhbmQgdGhleSB3aWxsIG5vdCBwcm9jZXNzIHRoZSBQQ0VEIGFu ZCBQQ0VTIFRMVnMuLi4NCg0KCQkJQnV0IEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBwb3NzaWJsZSBm b3IgYSByb3V0ZXIgdG8gYmUgcmUtY29uZmlndXJlZCBhcyBhIFBDQyBvciBoYXZlIHNvbWUgcGF0 aCBjb21wdXRhdGlvbiByZXF1ZXN0IGFmdGVyIGl0IHJlY2VpdmVzIHRoZXNlIFRMVnMgYW5kIG5v dCBwcm9jZXNzZXMgdGhlbSwgIA0KDQoJCQkgDQoNCgkJCU5vdyBpZiBhIHJvdXRlciBpcyBjb25m aWd1cmVkIGFzIFBDQyBhdCBzb21lIHBvaW50IGluIHRpbWUsIHRoZW4gaXQgc3RhcnRzIHByb2Nl c3NpbmcgaW5mb3JtYXRpb24gY2FycmllZCBpbiBQQ0VEIGFuZCBQQ0VTIFRMVnMuLi4oQmVmb3Jl IHlvdSBhY3RpdmF0ZSBQQ0UgZGlzY292ZXJ5IG9uIHRoZSBQQ0MgdGhlIGluZm9ybWF0aW9uIGlz IHN0b3JlZCBidXQgbm90IHByb2Nlc3NlZCkuDQoNCgkJCSANCg0KCQkJCQkgDQoNCgkJCQkJIA0K DQoJCQkJCU15IGNvbmNlcm4gdG8gUENFLURFU1QtRE9NQUlOUyBzdWItVExWIGlzIHRoYXQgd2Ug Y2FuJ3QgYW50aWNpcGF0ZSBob3cgbWFueSBkZXN0aW5hdGlvbiBkb21haW5zIGEgUENFIGNhbiAg Y29tcHV0YXRlIHBhdGggdG93YXJkcywgYXMgYSByZXN1bHQsdGhlIGxlbmd0aCBvZiBzcGFjZSB0 YWtlbiBieSB0aGlzIGNhcGFsaXR5IGluIHRoZSBtZXNzYWdlIGNhbid0IGJlIGNvbnRyb2xsZWQu ICANCg0KCQkJCQkgDQoNCgkJCQkJSkxMUjogQWN0dWFsbHkgeW91IGhhdmUgdGhlIHNhbWUgcHJv YmxlbSB3aXRoIHRoZSBudW1iZXIgb2YgVEUtbGlua3MgYWR2ZXJ0aXNlZCBieSBhbiBMU1Igb3Ig dGhlIG51bWJlciBvZiByZWFjaGVhYmxlIHByZWZpeGVzIGFkdmVydGlzZWQgYnkgYW4gQUJSLiAN Cg0KCQkJCQlPbmUgbWF5IGxpbWl0IGJ5IGNvbmZpZ3VyYXRpb24gdGhlIG51bWJlciBvZiBkZXN0 IGRvbWFpbnMgYWR2ZXJ0aXNlZC4NCg0KCQkJQnV0IEkgc3RpbGwgZG91YnQgdGhhdCBpZiBpdCdz IG5lZWRlZCBmb3IgdGhlIFBDRSB0byBtYWludGFpbiBzdWNoIGluZm9ybWF0aW9uIGFuZCBob3cg YSBQQ0Ugb2J0YWlucyB0aGVzZSBpbmZvPyANCg0KCQkJQXMgZGlzY3Vzc2VkIGxhdHRlciB0aGlz IGlzIGEgcmVhbGx5IHVzZWZ1bCBmZWF0dXJlIHRoYXQgaGVscHMgUENFIHNlbGVjdGlvbiBhbmQg bG9hZCBiYWxhbmNpbmcuDQoNCgkJCUluIHRoZSBpbnRlci1hcmVhIGNhc2UsIHRoZSBjYW4gbGVh cm4gdGhpcyBpbmZvIGJvdGggdmlhIGNvbmZpZyBhbmQgdmlhIHRoZSBJR1AgKGUuZy4gaWYgdGhl IFBDRSBpcyBhbiBBQlIsIGl0IGNhbiBlYXNpbHkga25vdyBhdHRhY2hlZCBhcmVhcykuDQoNCgkJ CUluIHRoZSBpbnRlci1BUyBjYXNlLCB0aGUgUENFIGNhbiBsZWFybiB0aGlzIGluZm9ybWF0aW9u IGJvdGggdmlhIGNvbmZpZyBhbmQgdmlhIEJHUC4gDQoNCgkJCQkJIA0KDQoJCQkJCSANCg0KCQkJ CQkgU28gSSB0aGluayBpZiB0aGUgUENDIHNlbmQgYSByZXF1ZXN0IHRvIGEgUENFIHdoaWNoIGNh bid0IGNvbXB1dGUgdGhlIHBhdGggZm9yIHRoZSByZWFzb24gb2YgdGhlIGRlc3RpbmF0aW9uIGRv bWFpbiwgdGhlIFBDRSBjYW4gdGVsbCB0aGUgUENDIGluIHRoZSBQQ3JlcCBtZXNzYWdlIHRoZSBy aWdodCBQQ0UuICANCg0KCQkJCQkgDQoNCgkJCQkJSkxMUjogQnV0IGhvdyB0aGUgUENFIHdpbGwg aGF2ZSB0aGUgaW5mb3JtYXRpb24/DQoNCgkJCQkJIA0KDQoJCQkJCSBPbmUgYWRkaXRpb25hbCBx dWVzaW9uOiBpcyBpdCBzdWl0YWJsZSBmb3IgdGhlIFBDRSB0byBoYXZlIHN1Y2ggYWJpbGl0eSB0 byBrbm93IGV4YWN0bHkgdGhlIGRlc3RpbmF0aW9uIGRvbWFpbiBpdCBjYW4gY29tcHV0ZSB0b3dh cmRzPyANCg0KCQkJCQkgDQoNCgkJCQkJSkxMUjogVGhpcyBpcyBhY3R1YWxseSByZXF1aXJlZC4g Rm9yIGluc3RhbmNlIGluIGFuIGludGVyLUFTIGNhc2UsIGFuIEFTIG1heSBiZSBjb25uZWN0ZWQg dG8gbXVsdGlwbGUgQVNzLCBhbmQgdGhlcmUgbWF5IGJlIG11bHRpcGxlIFBDRXMgaW4gdGhpcyBB UyAoZS5nLiBBU0JScyksIGVhY2ggcmVzcG9uc2libGUgZm9yIGNvbXB1dGluZyBwYXRoIHRvd2Fy ZHMgYSBnaXZlbiBuZWlnaGJvcmQgQVMuDQoNCgkJCUhlcmUgeW91IHNhaWQgdGhlIG5laWdoYm9y aW5nIEFTLCBidXQgbm90IHRoZSBkZXN0aW5hdGlvbiBBUy4gDQoNCgkJCSANCg0KCQkJSXQgd2Fz IGFuIGV4YW1wbGUgd2hlcmUgdGhlIGRlc3RpbmF0aW9uIGlzIGxvY2F0ZWQgaW4gdGhlIG5laWdo Ym9yaW5nIEFTLi4uIEJ1dCB0aGUgc2FtZSBhcHBsaWVzIHdoZW4gdGhlIGRlc3RpbmF0aW9uIGlz IGxvY2F0ZWQgZmFydGhlci4NCg0KCQkJIA0KDQoJCQlUaGFua3MgDQoNCgkJCSANCg0KCQkJSkwN Cg0KCQkJCQkgDQoNCgkJCQkJU29tZSBmdW5jdGlvbnMgc3BlY2lmaWVkIGluIHRoZSBQQVRILUNB TVAtQ0FQIHN1Yi1UTFYgYXJlIGFsc28gZGVmaW5lZCBpbiB0aGUgUENFUCwgIGEgY2xlYXIgZGl2 aXNpb24gc2hvdWxkIGJlIG1hZGUuICANCg0KCQkJCQkgDQoNCgkJCQkJIEpMTFI6ICBBY3R1YWxs eSwgYXQgdGhlIHRpbWUgYmVpbmcgdGhlIFBDRVAgc3BlYyBkb2VzIG5vdCBkZWZpbmUgYW55IGNh cGFiaWxpdHkgaW5mb3JtYXRpb24uDQoNCgkJCQkJSW4gY3VycmVudCBQQ0VQIHNwZWMsIHdlIG9u bHkgbWVudGlvbiB0aGF0IGRldGFpbGVkIGNhcGFiaWxpdGVzIGNvdWxkIGJlIGNhcnJpZWQgaW4g b3B0aW9uYWwgc3ViLVRMVnMgb2YgdGhlIE9wZW4gb2JqZWN0IChjYXJyaWVkIGluIHRoZSBPcGVu IG1lc3NhZ2UpLg0KDQoJCQkJCUJ1dCB5b3UgYXJlIHJpZ2h0IHN1Y2ggY2FwYWJpbGl0eSBpbmZv cm1hdGlvbiBtYXkgYmUgY2FycmllZCBpbiBQQ0VQLg0KDQoJCQkJCSANCg0KCQkJCQlUaGUgaWRl YSB3b3VsZCBiZSB0byBjYXJyeSBzaW1wbGUgY2FwYWJpbGl0aWVzIGluIHRoZSBJR1AgYW5kIG1v cmUgY29tcGxleCBjYXBhYmlsaXRpZXMgaW4gUENFUC4NCg0KCQkJCQkgDQoNCgkJCQkJQW55d2F5 IEkgZG9uJ3QgcmVhbGx5IHNlZSBhbnkgaXNzdWUgaWYgd2UgZGVmaW5lIHR3byB3YXlzIHRvIGNh cnJ5IHNvbWUgcGllY2VzIG9mIGluZm9ybWF0aW9uOg0KDQoJCQkJCS1JR1AtYmFzZWQgY2FwYWJp bGl0eSBkaXNjb3ZlcnkgaXMgdXNlZnVsIGZvciBQQ0NzIHRoYXQgZG9uJ3QgaGF2ZSBhIFBDRVAg c2Vzc2lvbiB3aXRoIHRoZSBQQ0UuDQoNCgkJCQkJLVBDRVAtYmFzZWQgY2FwYWJpbGl0eSBkaXNj b3ZlcnkgaXMgdXNlZnVsIHdoZW4gSUdQIGJhc2VkIGRpc2NvdmVyeSBpcyBub3QgYWN0aXZhdGVk LiANCg0KCQkJVGhpcyBzb3VuZHMgZmluZSB0byBtZS4NCg0KCQkJIA0KDQoJCQlSZWdhcmRzLA0K DQoJCQlaaGFuZyANCg0KCQkJCQkgDQoNCgkJCQkJIA0KDQoJCQkJCVRoYW5rcyBmb3IgdGhlc2Ug Y29tbWVudHMsDQoNCgkJCQkJIA0KDQoJCQkJCVJlZ2FyZHMsDQoNCgkJCQkJIA0KDQoJCQkJCUpM IA0KDQoJCQkJCSANCg0KCQkJCQkgDQoNCgkJCQkJIA0KDQoJCQkJCSANCg0KCQkJCQlDaGVlcnMs DQoNCgkJCQkJIA0KDQoJCQkJCVpoYW5nIFJlbmhhaQ0KDQo= ------_=_NextPart_001_01C695C5.5B241063 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1l cXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxN RVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMjg3MyIgbmFtZT1HRU5FUkFUT1I+PCEtLVtp ZiAhbXNvXT4NCjxTVFlMRT52XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0N Cm9cOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kd1w6KiB7DQoJQkVIQVZJ T1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQouc2hhcGUgew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1 bHQjVk1MKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZSANCm5hbWVz cGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiANCm5h bWU9IlN0cmVldCI+PC9vOlNtYXJ0VGFnVHlwZT48bzpTbWFydFRhZ1R5cGUgDQpuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgDQpuYW1lPSJh ZGRyZXNzIj48L286U21hcnRUYWdUeXBlPjwhLS1baWYgIW1zb10+DQo8U1RZTEU+c3QxXDoqIHsN CglCRUhBVklPUjogdXJsKCNkZWZhdWx0I2llb291aSkNCn0NCjwvU1RZTEU+DQo8IVtlbmRpZl0t LT4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQ291cmllcjsNCn0NCkBmb250 LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZh bWlseTogVGFob21hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDlrovkvZM7DQp9 DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogOC41aW4gMTEuMGluOyBtYXJnaW46IDEuMGluIDEuMjVp biAxLjBpbiAxLjI1aW47IH0NClAuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJ TjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KTEkuTXNv Tm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFN SUxZOiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KRElWLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAx MnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IGJsdWU7IFRF WFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9OVC1X RUlHSFQ6IG5vcm1hbDsgQ09MT1I6IGJsdWU7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1J TFk6IENvdXJpZXI7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5cGU6IHBlcnNv bmFsLXJlcGx5DQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8L1NUWUxF Pg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwv SEVBRD4NCjxCT0RZIGxhbmc9RU4tVVMgdkxpbms9Ymx1ZSBsaW5rPWJsdWUgYmdDb2xvcj13aGl0 ZT4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiBzaXplPTI+PFNQQU4gDQpjbGFzcz00MzQzNTI4MDYtMjIwNjIwMDY+U2VudCBhZ2FpbjwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDM0MzUyODA2LTIyMDYyMDA2PlRo aXMgZW1haWwgd2FzIG5vdCByZWNlaXZlZCBvbiB0aGUgcGNlIA0KbGlzdC48L1NQQU4+PC9GT05U PjwvRElWPjxCUj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1MRUZUOiA1 cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFS R0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9 ZnIgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICA8SFIgdGFiSW5kZXg9LTE+DQogIDxGT05UIGZhY2U9 VGFob21hIHNpemU9Mj48Qj5EZSZuYnNwOzo8L0I+IExFIFJPVVggSmVhbi1Mb3VpcyBSRC1DT1JF LUxBTiANCiAgPEJSPjxCPkVudm95w6kmbmJzcDs6PC9CPiBtZXJjcmVkaSAyMSBqdWluIDIwMDYg MTk6MzI8QlI+PEI+w4AmbmJzcDs6PC9CPiAnTHVjeSANCiAgWW9uZyc7ICdaaGFuZyBSZW5oYWkn OyBwY2VAaWV0Zi5vcmc8QlI+PEI+T2JqZXQmbmJzcDs6PC9CPiBSRTogW1BjZV0gQ29tbWVudHMg DQogIG9uIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncDxCUj48L0ZPTlQ+PEJSPjwvRElW Pg0KICA8RElWPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00 NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXpl PTI+SGkgTHVjeSw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29s b3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDY4MDMyNDE3LTIxMDYyMDA2PjxGT05UIGZhY2U9 QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPlRoYW5rcyBmb3IgdGhpcyBmZWVkYmFjayw8 L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFz cz00NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBz aXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NDY4MDMyNDE3LTIxMDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQogIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPkEmbmJzcDtQQ0UgdGhhdCBzZW5kcyBhIHJlcXVlc3QgdG8gYW5v dGhlciBQQ0UgY2FuIGJlIA0KICBjb25zaWRlcmVkIGFzIGEgUENDLCBpdCBpcyBhY3R1YWxseSBh Y3RpbmcgYXMgYSBQQ0MuIEhlbmNlLCBhcyBkaXNjdXNzZWQgaW4gDQogIHRoZSByZXF1aXJlbWVu dCBJRCwmbmJzcDt0aGVyZSBpcyBubyBuZWVkIHRvLCBhbmQgd2UgZG8gbm90LCBtYWtlIHRoZSAN CiAgZGlzdGluY3Rpb24gYmV0d2VlbiBkaXNjb3ZlcnkgYnkgUENDcyBhbmQgZGlzY292ZXJ5IGJ5 IA0KICBQQ0VzLi4uPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NDY4MDMyNDE3LTIxMDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQogIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPkEgUENFIHRoYXQgd2FudHMgdG8gZGlzY292ZXIgb3RoZXIgUENF cyBpbiB0aGUgSUdQIGRvbWFpbiANCiAgc2ltcGx5IG5lZWRzIHRvIGxpc3RlbiB0byBJR1AgYWR2 ZXJ0aXNlbWVudHMgZGVmaW5lZCBpbiB0aGlzIA0KICBkcmFmdCZuYnNwOyZuYnNwOyhpLmUuIGl0 IGFjdHMgYXMgYSBQQ0MpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTQ2ODAzMjQxNy0yMTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0K ICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQg ZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+SG9wZSB0aGlzIGNsYXJpZmllczwv Rk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTQ2ODAzMjQxNy0yMTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29s b3I9IzAwMDBmZiBzaXplPTI+QmVzdCBSZWdhcmRzLDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQ2ODAzMjQxNy0yMTA2MjAwNj48Rk9O VCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NjgwMzI0MTct MjEwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+Skw8L0ZP TlQ+PC9TUEFOPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00 NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9IzAwMDBmZiBzaXpl PTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+ PFNQQU4gY2xhc3M9NDY4MDMyNDE3LTIxMDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+PEJSPg0KICA8QkxPQ0tR VU9URSBkaXI9bHRyIA0KICBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1 cHg7IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0K ICAgIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1mciBkaXI9bHRyIGFsaWdu PWxlZnQ+DQogICAgPEhSIHRhYkluZGV4PS0xPg0KICAgIDxGT05UIGZhY2U9VGFob21hIHNpemU9 Mj48Qj5EZSZuYnNwOzo8L0I+IEx1Y3kgWW9uZyANCiAgICBbbWFpbHRvOmx1Y3l5b25nQGh1YXdl aS5jb21dIDxCUj48Qj5FbnZvecOpJm5ic3A7OjwvQj4gbWVyY3JlZGkgMjEganVpbiAyMDA2IA0K ICAgIDE5OjIxPEJSPjxCPsOAJm5ic3A7OjwvQj4gTEUgUk9VWCBKZWFuLUxvdWlzIFJELUNPUkUt TEFOOyAnWmhhbmcgUmVuaGFpJzsgDQogICAgcGNlQGlldGYub3JnPEJSPjxCPk9iamV0Jm5ic3A7 OjwvQj4gUkU6IFtQY2VdIENvbW1lbnRzIG9uIA0KICAgIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXBy b3RvLWlncDxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KICAgIDxESVY+PC9ESVY+DQogICAgPERJViBj bGFzcz1TZWN0aW9uMT4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Db3VyaWVy IGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBibHVlOyBGT05ULUZBTUlMWTogQ291cmllciI+SGVsbG8gDQogICAgSkxMUiw8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNv dXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj5UaGUgZHJhZnQgY292ZXJzIA0K ICAgIHZhcmlvdXMgZGlzY292ZXJ5IHJlcXVpcmVtZW50cyBhcyBtZW50aW9uZWQgaW4gc2VjdGlv biA0LjIuIEdvb2QgDQogICAgd29yay48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+ PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFN SUxZOiBDb3VyaWVyIj5PbmNlIHRoaW5nIEkgDQogICAgd291bGQgbGlrZSB0byBnZXQgY2xhcmlm aWNhdGlvbiBpcyB0aGF0IHRoZSBkcmFmdCBmb2N1cyBvbiB0aGUgZGlzY292ZXJ5IA0KICAgIGJl dHdlZW4gYSBQQ0MgYW5kIGEgUENFLCBhIFBDRSBhbmQgZG9tYWlucyB0aGF0IHRoZSBQQ0UgaGFz IHZpc2liaWxpdHkgYW5kIA0KICAgIGNhbiBjb21wdXRlIHBhdGhzLCBhbmQgYSBQQ0UgYW5kIGRv bWFpbnMgdGhhdCB0aGUgUENFIGNhbiBjb21wdXRlIHBhdGhzIA0KICAgIHRvd2FyZC4gVGhlIGRy YWZ0IGFsc28gbWVudGlvbnMgdGhhdCBQQ0UgaW5mb3JtYXRpb24gaXMgZGlzY2xvc2VkIHRvIA0K ICAgIFBDQy48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj5Gcm9t IHRoZXNlIHNldCBvZiANCiAgICBkaXNjb3ZlcmllcywgSSBjb3VsZCBub3Qgc2VlIGlmIHRoZSBk aXNjb3ZlcmllcyBhbHNvIGluY2x1ZGUgdGhlIGRpc2NvdmVyeSANCiAgICBiZXR3ZWVuIFBDRXMg YW5kIGluZm9ybWF0aW9uIGNoYW5nZXMgYmV0d2VlbiBQQ0VzLiBNYXliZSBJIG1pc3MgdGhlbSBp biANCiAgICBjb250ZXh0LiBDb3VsZCB5b3UgaGVscCB0byBjbGFyaWZ5PyAmbmJzcDs8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNv dXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj5CZXN0IA0KICAgIFJlZ2FyZHMs PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1Db3VyaWVyIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQ291cmllciI+THVjeSANCiAg ICA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj48bzpwPiZu YnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxESVY+DQogICAgPERJViBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVyPjxGT05UIA0K ICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPg0KICAgIDxIUiB0YWJJbmRleD0tMSBhbGlnbj1jZW50ZXIgd2lkdGg9IjEwMCUiIFNJ WkU9Mj4NCiAgICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Qj48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJR0hU OiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPkZyb206PC9TUEFO PjwvRk9OVD48L0I+PEZPTlQgDQogICAgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPiANCiAgICA8c3QxOlN0cmVldCB3 OnN0PSJvbiI+PHN0MTphZGRyZXNzIHc6c3Q9Im9uIj5MRSBST1VYIEplYW4tTG91aXMgDQogICAg UkQ8L3N0MTphZGRyZXNzPjwvc3QxOlN0cmVldD4tQ09SRS1MQU4gDQogICAgW21haWx0bzpqZWFu bG91aXMubGVyb3V4QG9yYW5nZS1mdC5jb21dIDxCUj48Qj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQiPlNlbnQ6PC9TUEFOPjwvQj4gVHVlc2RheSwgSnVuZSAyMCwgMjAwNiAx OjU0IA0KICAgIEFNPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+VG86PC9T UEFOPjwvQj4gWmhhbmcgUmVuaGFpOyANCiAgICBwY2VAaWV0Zi5vcmc8QlI+PEI+PFNQQU4gc3R5 bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48L0I+IFJFOiANCiAgICBbUGNl XSBDb21tZW50cyBvbiANCiAgICBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3A8L1NQQU4+ PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0K ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJp YWwiPkhpIA0KICAgIFpoYW5nLDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFO IA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJs dWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+UGxlYXNlIHNlZSANCiAgICBpbmxpbmUsPC9TUEFOPjwv Rk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVS LVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRp dW0gbm9uZTsgUEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjog NXB0IDBpbiA1cHQgMy43NXB0OyBCT1JERVItTEVGVDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElO Ry1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAg ICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05U PjwvUD4NCiAgICAgIDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBjZW50 ZXIiIGFsaWduPWNlbnRlcj48Rk9OVCANCiAgICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0zPjxTUEFOIGxhbmc9RlIgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+DQogICAgICA8SFIgdGFi SW5kZXg9LTEgYWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpFPTI+DQogICAgICA8L1NQQU4+ PC9GT05UPjwvRElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tQk9U VE9NOiAxMnB0Ij48Qj48Rk9OVCBmYWNlPVRhaG9tYSANCiAgICAgIHNpemU9Mj48U1BBTiBsYW5n PUZSIA0KICAgICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBUYWhvbWEiPkRlJm5ic3A7OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAg ICAgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIGxhbmc9RlIgDQogICAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj4gWmhhbmcgUmVuaGFpIA0KICAgICAgW21h aWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29tXSA8QlI+PEI+PFNQQU4gDQogICAgICBzdHlsZT0i Rk9OVC1XRUlHSFQ6IGJvbGQiPkVudm95w6kmbmJzcDs6PC9TUEFOPjwvQj4gbWFyZGkgMjAganVp biAyMDA2IA0KICAgICAgMDU6MjY8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xk Ij7DgCZuYnNwOzo8L1NQQU4+PC9CPiBMRSBST1VYIA0KICAgICAgSmVhbi1Mb3VpcyBSRC1DT1JF LUxBTjsgcGNlQGlldGYub3JnPEJSPjxCPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtV0VJR0hU OiBib2xkIj5PYmpldCZuYnNwOzo8L1NQQU4+PC9CPiBSZTogW1BjZV0gQ29tbWVudHMgb24gDQog ICAgICBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3A8L1NQQU4+PC9GT05UPjxTUEFOIA0K ICAgICAgbGFuZz1GUj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAgICA8RElWPg0KICAgICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48U1BBTiANCiAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPkhpLCANCiAgICAg IEplYW4tTG91aXM8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgPERJ Vj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9Mz48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPlNlZSBpbmxpbmUsIA0KICAg ICAgcGxlYXNlLjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICA8QkxP Q0tRVU9URSANCiAgICAgIHN0eWxlPSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5H LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsg UEFERElORy1CT1RUT006IDBpbjsgTUFSR0lOOiA1cHQgMGluIDVwdCAzLjc1cHQ7IEJPUkRFUi1M RUZUOiBibGFjayAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTog bWVkaXVtIG5vbmUiPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0xPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpF OiA5cHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQogICAgICAgIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxE SVYgc3R5bGU9ImZvbnQtY29sb3I6IGJsYWNrIj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0Ij48Qj48Rk9OVCBmYWNlPeWui+S9kyANCiAgICAg ICAgc2l6ZT0xPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQt U0laRTogOXB0OyBGT05ULUZBTUlMWTog5a6L5L2TIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxG T05UIA0KICAgICAgICBmYWNlPeWui+S9kyBzaXplPTE+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog OXB0OyBGT05ULUZBTUlMWTog5a6L5L2TIj4gPEEgDQogICAgICAgIHRpdGxlPWplYW5sb3Vpcy5s ZXJvdXhAb3JhbmdlLWZ0LmNvbSANCiAgICAgICAgaHJlZj0ibWFpbHRvOmplYW5sb3Vpcy5sZXJv dXhAb3JhbmdlLWZ0LmNvbSI+TEUgUk9VWCBKZWFuLUxvdWlzIA0KICAgICAgICBSRC1DT1JFLUxB TjwvQT4gPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4N CiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U95a6L5L2TIHNpemU9MT48 U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDlwdDsg Rk9OVC1GQU1JTFk6IOWui+S9kyI+VG86PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgICAg IGZhY2U95a6L5L2TIHNpemU9MT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFN SUxZOiDlrovkvZMiPiA8QSANCiAgICAgICAgdGl0bGU9emhhbmdyZW5oYWlAaHVhd2VpLmNvbSBo cmVmPSJtYWlsdG86emhhbmdyZW5oYWlAaHVhd2VpLmNvbSI+WmhhbmcgDQogICAgICAgIFJlbmhh aTwvQT4gOyA8QSB0aXRsZT1wY2VAaWV0Zi5vcmcgDQogICAgICAgIGhyZWY9Im1haWx0bzpwY2VA aWV0Zi5vcmciPnBjZUBpZXRmLm9yZzwvQT4gDQogICAgICAgIDxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Qj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTE+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05U LVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPlNlbnQ6 PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgICAgIGZhY2U95a6L5L2TIHNpemU9MT48U1BB TiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPiBNb25kYXksIA0K ICAgICAgICBKdW5lIDE5LCAyMDA2IDQ6MjMgUE08bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q PjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZP TlQgZmFjZT3lrovkvZMgc2l6ZT0xPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6 IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTog5a6L5L2TIj5TdWJqZWN0OjwvU1BB Tj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgICAgICBmYWNlPeWui+S9kyBzaXplPTE+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTog5a6L5L2TIj4gUkU6IFtQY2VdIA0KICAg ICAgICBDb21tZW50cyBvbiANCiAgICAgICAgZHJhZnQtaWV0Zi1wY2UtZGlzY28tcHJvdG8taWdw PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAg ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0z PjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGkgDQogICAg ICAgIFpoYW5nPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgICAgICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAg ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+VGhhbmtzIGZvciB5b3VyIA0KICAgICAgICBj b21tZW50czwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogICAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAg ICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPlBsZWFzZSBzZWUgDQogICAgICAgIGlubGluZSw8 L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICAgICAgICA8QkxPQ0tRVU9URSANCiAgICAg ICAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsg Qk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRP TTogMGluOyBNQVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsdWUgMS41 cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4N CiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPTM+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PG86cD4m bmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgICAgICA8RElWIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+PEZPTlQgDQogICAg ICAgICAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gbGFuZz1GUiBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij4NCiAgICAgICAgICA8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVy IHdpZHRoPSIxMDAlIiBTSVpFPTI+DQogICAgICAgICAgPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg ICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxC PjxGT05UIGZhY2U9VGFob21hIA0KICAgICAgICAgIHNpemU9Mj48U1BBTiBsYW5nPUZSIA0KICAg ICAgICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogVGFob21hIj5EZSZuYnNwOzo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgICAgICAg ICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gbGFuZz1GUiANCiAgICAgICAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj4gWmhhbmcgUmVuaGFpIA0KICAgICAg ICAgIFttYWlsdG86emhhbmdyZW5oYWlAaHVhd2VpLmNvbV0gPEJSPjxCPjxTUEFOIA0KICAgICAg ICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+RW52b3nDqSZuYnNwOzo8L1NQQU4+PC9CPiBt YXJkaSAxMyBqdWluIDIwMDYgDQogICAgICAgICAgMDk6MDc8QlI+PEI+PFNQQU4gc3R5bGU9IkZP TlQtV0VJR0hUOiBib2xkIj7DgCZuYnNwOzo8L1NQQU4+PC9CPiA8QSANCiAgICAgICAgICBocmVm PSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L0E+PEJSPjxCPjxTUEFOIA0KICAg ICAgICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+T2JqZXQmbmJzcDs6PC9TUEFOPjwvQj4g W1BjZV0gQ29tbWVudHMgb24gDQogICAgICAgICAgZHJhZnQtaWV0Zi1wY2UtZGlzY28tcHJvdG8t aWdwPC9TUEFOPjwvRk9OVD48U1BBTiANCiAgICAgICAgICBsYW5nPUZSPjxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj5IaSwgDQogICAgICAgICAgYWxsPC9TUEFO PjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48 U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q291cmllciBzaXplPTM+PFNQQU4gDQogICAgICAg ICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPkkgcmVjZW50 bHkgcmVhZCB0aGUgDQogICAgICAgICAgZHJhZnQgZHJhZnQtaWV0Zi1wY2UtZGlzY28tcHJvdG8t aWdwIGFnYWluLCBoZXJlIGFyZSBzb21lIA0KICAgICAgICAgIGNvbW1lbnRzPC9TUEFOPjwvRk9O VD48Rk9OVCBmYWNlPeWui+S9kz48U1BBTiBsYW5nPVpILUNOIA0KICAgICAgICAgIHN0eWxlPSJG T05ULUZBTUlMWTog5a6L5L2TIj7jgII8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElW Pg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05U LVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQog ICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1D b3VyaWVyIHNpemU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBG T05ULUZBTUlMWTogQ291cmllciI+V2hlbiBJR1AgaXMgdXNlZCZuYnNwO2FzIA0KICAgICAgICAg IGEgUENFRCBwcm90b2NvbCwgdGhlIGNhcGFiaWxpdGllcyBvZiBwY2Ugd2lsbCBiZSBhZHZlcnRp c2VkIHBlcmlvZGljbHkgDQogICAgICAgICAgYWxvbmcgd2l0aCBvdGhlciBsc2EvbHNwIGluZm9y bWF0aW9uLiBJbiBteSBvcGluaW9uLCB1bmxlc3MgdGhlIFBDRSdzIA0KICAgICAgICAgIGNhcGFi aWxpdGllcyBjaGFuZ2UsJm5ic3A7IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBQQ0MgdG8gcmVj ZWl2ZSANCiAgICAgICAgICBhbmQmbmJzcDtoYW5kbGUgdGhlIGluZm9ybWF0aW9uIGFnYWluLiZu YnNwOzwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogICAgICAgICAgZmFjZT1BcmlhbCBjb2xvcj1ibHVl IHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog Ymx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+ PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5KTExSOiBC dXQgDQogICAgICAgICAgdGhlc2UgYXJlIHN0YW5kYXJkIElHUCBwcm9jZWR1cmVzLiBUaGlzIGlz IHRoZSBzYW1lIGZvciBsaW5rIHN0YXRlcywgDQogICAgICAgICAgdGhleSBhcmUgcmVmcmVzaGVk IGV2ZW4gaWYgdGhlcmUgaXMgbm90IGNoYW5nZS4gQnkgdGhlIHdheSB0aGUgcmVmcmVzaCANCiAg ICAgICAgICBpbnRlcnZhbCBjYW4gYmUgcXVpdGUgbGFyZ2UgKGUuZy4gMTggaG91cnMgZm9yIA0K ICAgICAgICAgIElTLUlTKS48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAg ICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAg ICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgICA8 RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+ DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q291cmllciBzaXplPTM+ PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENv dXJpZXIiPiZuYnNwO0Z1cnRoZXJtb3JlLCBpZiANCiAgICAgICAgICBtb3N0IG9mIHRoZSByb3V0 ZXJzIGluIGEgZG9tYWluIHdpbGwgYWx3YXlzIGhhdmUgbm8gcmVxdWVzdCB0byBhIFBDRSwgDQog ICAgICAgICAgdGhlcmUgaXMgYWxzbyBubyBuZWVkIGZvciB0aGVtIHRvIG1haW50YWluIHRoZSAN CiAgICAgICAgICBpbmZvcm1hdGlvbi4mbmJzcDs8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9Ymx1ZSANCiAgICAgICAgICBzaXplPTI+PFNQQU4gDQogICAgICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7 PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgICA8RElWPg0KICAg ICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAg ICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5KTExSOiBJbiB0aGlzIA0KICAgICAg ICAgIGNhc2UgUENFIGRpc2NvdmVyeSBpcyBkZWFjdGl2YXRlZCBvbiB0aGVzZSByb3V0ZXJzIGFu ZCB0aGV5IHdpbGwgbm90IA0KICAgICAgICAgIHByb2Nlc3MgdGhlIFBDRUQgYW5kIFBDRVMgVExW cy4uLjwvU1BBTj48L0ZPTlQ+PEZPTlQgY29sb3I9Ymx1ZT48U1BBTiANCiAgICAgICAgICBzdHls ZT0iQ09MT1I6IGJsdWUiPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+PC9ESVY+ PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gDQogICAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlh bCI+QnV0IEkgZG9uJ3Qga25vdyANCiAgICAgIGlmIGl0IGlzIHBvc3NpYmxlIGZvciBhIHJvdXRl ciB0byBiZSByZS1jb25maWd1cmVkJm5ic3A7YXMgYSBQQ0Mgb3IgaGF2ZSANCiAgICAgIHNvbWUm bmJzcDtwYXRoIGNvbXB1dGF0aW9uIHJlcXVlc3QmbmJzcDthZnRlciZuYnNwO2l0IHJlY2VpdmVz IHRoZXNlIFRMVnMgDQogICAgICBhbmQgbm90IHByb2Nlc3NlcyB0aGVtLDwvU1BBTj48L0ZPTlQ+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIA0KICAgICAgc2l6ZT0yPjxTUEFOIA0KICAgICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ Jm5ic3A7Jm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgICAgIGNvbG9yPWJsdWU+PFNQQU4g c3R5bGU9IkNPTE9SOiBibHVlIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0K ICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIGNvbG9yPWJsdWUgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgQ09MT1I6IGJsdWUiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Ob3cgaWYgYSByb3V0ZXIgDQog ICAgICBpcyBjb25maWd1cmVkIGFzIFBDQyBhdCBzb21lIHBvaW50IGluIHRpbWUsIHRoZW4mbmJz cDtpdCZuYnNwO3N0YXJ0cyANCiAgICAgIHByb2Nlc3NpbmcmbmJzcDtpbmZvcm1hdGlvbiBjYXJy aWVkIGluIFBDRUQgYW5kIFBDRVMgVExWcy4uLihCZWZvcmUgeW91IA0KICAgICAgYWN0aXZhdGUg UENFIGRpc2NvdmVyeSBvbiB0aGUgUENDIHRoZSBpbmZvcm1hdGlvbiBpcyBzdG9yZWQgYnV0IG5v dCANCiAgICAgIHByb2Nlc3NlZCkuPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1ibHVlPjxTUEFO IA0KICAgICAgc3R5bGU9IkNPTE9SOiBibHVlIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q PjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsdWUgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdDsgQ09MT1I6IGJsdWUiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+PC9ESVY+DQogICAgICA8QkxPQ0tRVU9URSANCiAgICAgIHN0eWxlPSJCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1lZGl1 bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBpbjsgTUFSR0lOOiA1 cHQgMGluIDVwdCAzLjc1cHQ7IEJPUkRFUi1MRUZUOiBibGFjayAxLjVwdCBzb2xpZDsgUEFERElO Ry1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgICA8QkxPQ0tR VU9URSANCiAgICAgICAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct UklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQ QURESU5HLUJPVFRPTTogMGluOyBNQVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsgQk9SREVSLUxF RlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1l ZGl1bSBub25lIj4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgICAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q PjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9E SVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1Db3VyaWVyIHNpemU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBGT05ULUZBTUlMWTogQ291cmllciI+TXkgY29uY2VybiB0byANCiAgICAgICAgICBQQ0Ut REVTVC1ET01BSU5TIHN1Yi1UTFYmbmJzcDtpcyB0aGF0IHdlIGNhbid0IGFudGljaXBhdGUgaG93 IG1hbnkgDQogICAgICAgICAgZGVzdGluYXRpb24gZG9tYWlucyBhIFBDRSBjYW4gJm5ic3A7Y29t cHV0YXRlIHBhdGggdG93YXJkcywmbmJzcDthcyBhIA0KICAgICAgICAgIHJlc3VsdCx0aGUgbGVu Z3RoIG9mIHNwYWNlIHRha2VuIGJ5IHRoaXMgY2FwYWxpdHkgaW4gdGhlIG1lc3NhZ2UgY2FuJ3Qg DQogICAgICAgICAgYmUgY29udHJvbGxlZC4mbmJzcDs8L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9Ymx1ZSANCiAgICAgICAgICBzaXplPTI+PFNQQU4gDQogICAgICAgICAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5i c3A7PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgICA8RElWPg0K ICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAg ICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXpl PTI+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+SkxMUjogDQogICAgICAgICAgQWN0dWFsbHkgeW91IGhhdmUg dGhlIHNhbWUgcHJvYmxlbSB3aXRoIHRoZSBudW1iZXIgb2YgVEUtbGlua3MgDQogICAgICAgICAg YWR2ZXJ0aXNlZCBieSZuYnNwO2FuIExTUiBvciB0aGUgbnVtYmVyIG9mIHJlYWNoZWFibGUgcHJl Zml4ZXMgDQogICAgICAgICAgYWR2ZXJ0aXNlZCBieSBhbiBBQlIuIDwvU1BBTj48L0ZPTlQ+PG86 cD48L286cD48L1A+PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAg ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFy aWFsIj5PbmUgbWF5IGxpbWl0IA0KICAgICAgICAgIGJ5IGNvbmZpZ3VyYXRpb24gdGhlIG51bWJl ciBvZiBkZXN0IGRvbWFpbnMgDQogICAgICAgICAgYWR2ZXJ0aXNlZC48L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQogICAgICA8RElW Pg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5CdXQg SSBzdGlsbCBkb3VidCB0aGF0IGlmIGl0J3MgDQogICAgICBuZWVkZWQgZm9yIHRoZSBQQ0UgdG8g bWFpbnRhaW4gc3VjaCBpbmZvcm1hdGlvbiBhbmQgaG93IGEgUENFIG9idGFpbnMgDQogICAgICB0 aGVzZSBpbmZvPzxGT05UIGNvbG9yPWJsdWU+PFNQQU4gDQogICAgICBzdHlsZT0iQ09MT1I6IGJs dWUiPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJ Vj4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPkFzIGRpc2N1c3NlZCANCiAgICAgIGxh dHRlciB0aGlzIGlzIGEgcmVhbGx5IHVzZWZ1bCBmZWF0dXJlIHRoYXQgaGVscHMgUENFIHNlbGVj dGlvbiBhbmQgbG9hZCANCiAgICAgIGJhbGFuY2luZy48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+ PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SW4mbmJzcDt0aGUgDQog ICAgICBpbnRlci1hcmVhIGNhc2UsIHRoZSBjYW4gbGVhcm4gdGhpcyBpbmZvIGJvdGggdmlhIGNv bmZpZyBhbmQgdmlhIHRoZSBJR1AgDQogICAgICAoZS5nLiBpZiB0aGUgUENFIGlzIGFuIEFCUiwg aXQgY2FuIGVhc2lseSBrbm93IGF0dGFjaGVkIA0KICAgICAgYXJlYXMpLjwvU1BBTj48L0ZPTlQ+ PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JbiB0 aGUgaW50ZXItQVMgDQogICAgICBjYXNlLCB0aGUgUENFIGNhbiBsZWFybiB0aGlzIGluZm9ybWF0 aW9uIA0KICAgICAgYm90aCZuYnNwO3ZpYSZuYnNwO2NvbmZpZyZuYnNwO2FuZCB2aWEgQkdQLjwv U1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgIHNpemU9Mj48U1BBTiANCiAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7PC9TUEFO PjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAg c3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9S REVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRPTTog MGluOyBNQVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsYWNrIDEuNXB0 IHNvbGlkOyBQQURESU5HLVRPUDogMGluOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZSI+DQog ICAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0g bm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1cHQgMy43 NXB0OyBCT1JERVItTEVGVDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6IDBpbjsgQk9S REVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFO IA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQog ICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxl PSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj4mbmJzcDtTbyBJIHRoaW5r IGlmIHRoZSANCiAgICAgICAgICBQQ0Mgc2VuZCBhIHJlcXVlc3QgdG8gYSBQQ0Ugd2hpY2ggY2Fu J3QgY29tcHV0ZSB0aGUgcGF0aCBmb3IgdGhlIA0KICAgICAgICAgIHJlYXNvbiBvZiB0aGUgZGVz dGluYXRpb24gZG9tYWluLCB0aGUgUENFIGNhbiB0ZWxsIHRoZSBQQ0MgaW4gdGhlIA0KICAgICAg ICAgIFBDcmVwIG1lc3NhZ2UmbmJzcDt0aGUgcmlnaHQgUENFLiZuYnNwOzwvU1BBTj48L0ZPTlQ+ PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgICAgICBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAg ICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6 IEFyaWFsIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAg ICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEy cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgICAg PERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5KTExSOiBCdXQgaG93IA0KICAgICAgICAg IHRoZSBQQ0Ugd2lsbCBoYXZlIHRoZSBpbmZvcm1hdGlvbj88L1NQQU4+PC9GT05UPjxvOnA+PC9v OnA+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0OyBGT05ULUZBTUlMWTogQ291cmllciI+Jm5ic3A7T25lIGFkZGl0aW9uYWwgDQog ICAgICAgICAgcXVlc2lvbjogaXMgaXQgc3VpdGFibGUgZm9yIHRoZSBQQ0UgdG8gaGF2ZSBzdWNo IGFiaWxpdHkgdG8ga25vdyANCiAgICAgICAgICBleGFjdGx5IHRoZSBkZXN0aW5hdGlvbiBkb21h aW4gaXQgY2FuIGNvbXB1dGUgDQogICAgICAgICAgdG93YXJkcz88L1NQQU4+PC9GT05UPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7PC9T UEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgICA8RElWPg0KICAgICAg ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQ QU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQt RkFNSUxZOiBBcmlhbCI+SkxMUjogVGhpcyBpcyANCiAgICAgICAgICBhY3R1YWxseSZuYnNwO3Jl cXVpcmVkLiBGb3IgaW5zdGFuY2UgaW4gYW4gaW50ZXItQVMgY2FzZSwgYW4gQVMgbWF5IGJlIA0K ICAgICAgICAgIGNvbm5lY3RlZCB0byBtdWx0aXBsZSBBU3MsIGFuZCZuYnNwO3RoZXJlIG1heSBi ZSBtdWx0aXBsZSBQQ0VzIGluIHRoaXMgDQogICAgICAgICAgQVMgKGUuZy4gQVNCUnMpLCBlYWNo IHJlc3BvbnNpYmxlIGZvciBjb21wdXRpbmcgcGF0aCB0b3dhcmRzIGEgZ2l2ZW4gDQogICAgICAg ICAgbmVpZ2hib3JkIEFTLjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+PC9CTE9D S1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkhlcmUgeW91IHNhaWQgdGhlIG5laWdoYm9yaW5n IA0KICAgICAgQVMsIGJ1dCBub3QgdGhlIGRlc3RpbmF0aW9uIEFTLjxGT05UIGNvbG9yPWJsdWU+ PFNQQU4gDQogICAgICBzdHlsZT0iQ09MT1I6IGJsdWUiPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9T UEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgIDxESVY+DQogICAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4g DQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SXQgd2FzIGFu IGV4YW1wbGUgDQogICAgICB3aGVyZSB0aGUgZGVzdGluYXRpb24gaXMgbG9jYXRlZCBpbiB0aGUg bmVpZ2hib3JpbmcgQVMuLi4gQnV0IHRoZSBzYW1lIA0KICAgICAgYXBwbGllcyB3aGVuIHRoZSBk ZXN0aW5hdGlvbiBpcyBsb2NhdGVkIA0KICAgICAgZmFydGhlci48L1NQQU4+PC9GT05UPjxvOnA+ PC9vOnA+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+ DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGFua3MgDQogICAgICA8L1NQQU4+PC9G T05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5KTDwvU1BBTj48L0ZPTlQ+ PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICA8QkxPQ0tRVU9URSANCiAgICAgIHN0eWxlPSJC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6 IG1lZGl1bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBpbjsgTUFS R0lOOiA1cHQgMGluIDVwdCAzLjc1cHQ7IEJPUkRFUi1MRUZUOiBibGFjayAxLjVwdCBzb2xpZDsg UEFERElORy1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgICA8 QkxPQ0tRVU9URSANCiAgICAgICAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDog NHB0OyBQQURESU5HLUJPVFRPTTogMGluOyBNQVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsgQk9S REVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RU T006IG1lZGl1bSBub25lIj4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAg ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9Q291cmllciBzaXplPTM+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZP TlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPlNvbWUgZnVuY3Rpb25zIHNwZWNp ZmllZCANCiAgICAgICAgICBpbiB0aGUgUEFUSC1DQU1QLUNBUCBzdWItVExWIGFyZSBhbHNvJm5i c3A7ZGVmaW5lZCZuYnNwO2luIHRoZSANCiAgICAgICAgICBQQ0VQLCZuYnNwOyBhIGNsZWFyIGRp dmlzaW9uIHNob3VsZCBiZSBtYWRlLiZuYnNwOzwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogICAgICAg ICAgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8 L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAg ICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAg ICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwO0pMTFI6IA0KICAgICAgICAg ICZuYnNwO0FjdHVhbGx5LCBhdCB0aGUgdGltZSBiZWluZyB0aGUgUENFUCBzcGVjIGRvZXMgbm90 IGRlZmluZSBhbnkgDQogICAgICAgICAgY2FwYWJpbGl0eSBpbmZvcm1hdGlvbi48L1NQQU4+PC9G T05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4g DQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFN SUxZOiBBcmlhbCI+SW4gY3VycmVudCANCiAgICAgICAgICBQQ0VQIHNwZWMsIHdlIG9ubHkgbWVu dGlvbiB0aGF0IGRldGFpbGVkIGNhcGFiaWxpdGVzIGNvdWxkIGJlIGNhcnJpZWQgDQogICAgICAg ICAgaW4gb3B0aW9uYWwgc3ViLVRMVnMgb2YgdGhlIE9wZW4gb2JqZWN0IChjYXJyaWVkIGluIHRo ZSBPcGVuIA0KICAgICAgICAgIG1lc3NhZ2UpLjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+ PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5CdXQgeW91 IGFyZSANCiAgICAgICAgICByaWdodCBzdWNoIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gbWF5IGJl IGNhcnJpZWQgaW4gDQogICAgICAgICAgUENFUC48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9Q PjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9E SVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGUgDQogICAg ICAgICAgaWRlYSZuYnNwO3dvdWxkIGJlJm5ic3A7dG8gY2FycnkmbmJzcDtzaW1wbGUgY2FwYWJp bGl0aWVzJm5ic3A7aW4gdGhlIA0KICAgICAgICAgIElHUCBhbmQmbmJzcDttb3JlIGNvbXBsZXgg Y2FwYWJpbGl0aWVzIGluIA0KICAgICAgICAgIFBDRVAuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpw PjwvUD48L0RJVj4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgICAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q PjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QW55d2F5 IEkgDQogICAgICAgICAgZG9uJ3QgcmVhbGx5IHNlZSBhbnkgaXNzdWUgaWYgd2UgZGVmaW5lIHR3 byB3YXlzIA0KICAgICAgICAgIHRvJm5ic3A7Y2FycnkmbmJzcDtzb21lIHBpZWNlcyBvZiANCiAg ICAgICAgICBpbmZvcm1hdGlvbjo8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0K ICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+LUlHUC1iYXNlZCANCiAg ICAgICAgICBjYXBhYmlsaXR5IGRpc2NvdmVyeSBpcyB1c2VmdWwgZm9yIFBDQ3MgdGhhdCBkb24n dCBoYXZlIGEgUENFUCBzZXNzaW9uIA0KICAgICAgICAgIHdpdGggdGhlIFBDRS48L1NQQU4+PC9G T05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4g DQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFN SUxZOiBBcmlhbCI+LVBDRVAtYmFzZWQgDQogICAgICAgICAgY2FwYWJpbGl0eSBkaXNjb3Zlcnkg aXMgdXNlZnVsIHdoZW4gSUdQIGJhc2VkIGRpc2NvdmVyeSBpcyBub3QgDQogICAgICAgICAgYWN0 aXZhdGVkLiZuYnNwOzwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+PC9ESVY+PC9C TE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPlRoaXMgc291bmRzIGZpbmUgdG8gDQogICAg ICBtZS48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAg ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mz48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5SZWdhcmRzLDwvU1BBTj48L0ZPTlQ+PG86 cD48L286cD48L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj5aaGFuZyANCiAgICAgIDwvU1BBTj48L0ZPTlQ+PG86 cD48L286cD48L1A+PC9ESVY+DQogICAgICA8QkxPQ0tRVU9URSANCiAgICAgIHN0eWxlPSJCT1JE RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1l ZGl1bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBpbjsgTUFSR0lO OiA1cHQgMGluIDVwdCAzLjc1cHQ7IEJPUkRFUi1MRUZUOiBibGFjayAxLjVwdCBzb2xpZDsgUEFE RElORy1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgICA8QkxP Q0tRVU9URSANCiAgICAgICAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0 OyBQQURESU5HLUJPVFRPTTogMGluOyBNQVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsgQk9SREVS LUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lIj4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgICAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5UaGFua3Mg Zm9yIA0KICAgICAgICAgIHRoZXNlIGNvbW1lbnRzLDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48 L1A+PC9ESVY+DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgICAgc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48 L0RJVj4NCiAgICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPlJlZ2FyZHMs PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgICA8RElWPg0KICAg ICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAg ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+ PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZP TlQtRkFNSUxZOiBBcmlhbCI+SkwmbmJzcDs8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwv RElWPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+ DQogICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAg ICAgICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpF OiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAg ICAgIDxESVY+DQogICAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEy cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgICAg PERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Db3VyaWVyIHNp emU9Mz48U1BBTiANCiAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlM WTogQ291cmllciI+Q2hlZXJzLDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQog ICAgICAgICAgPERJVj4NCiAgICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAg ICAgICA8RElWPg0KICAgICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNvdXJp ZXIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQt RkFNSUxZOiBDb3VyaWVyIj5aaGFuZyANCiAgICAgICAgICBSZW5oYWk8L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RF PjwvRElWPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C695C5.5B241063-- --===============0202119557== 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 --===============0202119557==-- From pce-bounces@lists.ietf.org Thu Jun 22 12:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSDL-00019t-93; Thu, 22 Jun 2006 12:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRt4-0005kx-Pf for pce@ietf.org; Thu, 22 Jun 2006 12:18:34 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRsy-0007JN-No for pce@ietf.org; Thu, 22 Jun 2006 12:18:34 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1900GXSRS5CT@usaga01-in.huawei.com> for pce@ietf.org; Thu, 22 Jun 2006 09:14:30 -0700 (PDT) Received: from Yong73674 ([10.124.8.212]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1900MHFRRZ80@usaga01-in.huawei.com> for pce@ietf.org; Thu, 22 Jun 2006 09:14:29 -0700 (PDT) Date: Thu, 22 Jun 2006 11:17:31 -0500 From: Lucy Yong Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp In-reply-to: <162E039E-6BF4-4673-8C5B-BCA4B3DF2162@cisco.com> To: 'JP Vasseur' Message-id: <002e01c69617$5d5edcb0$d4087c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcaVkGdyLwxcCtuEQ2ys0MW/SZMtugAhNxDQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 814262cf72d11fb6cb5903b95d3f8bec X-Mailman-Approved-At: Thu, 22 Jun 2006 12:39:30 -0400 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="===============1805794687==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1805794687== Content-type: multipart/alternative; boundary="Boundary_(ID_wE6enVrFD2s+bkQPNVlSEA)" This is a multi-part message in MIME format. --Boundary_(ID_wE6enVrFD2s+bkQPNVlSEA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Hi JP, =20 Does that mean all PCCs and PCEs under one IGP? How about PCE = partitioning? Does a PCC get PCE announcement from only PCEs it = discovers, or from all PCEs within IGP. =20 Looks like I miss something. =20 Best Regards, Lucy =20 _____ =20 From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: Wednesday, June 21, 2006 7:08 PM To: Lucy Yong Cc: 'LE ROUX Jean-Louis RD-CORE-LAN'; 'Zhang Renhai'; pce@ietf.org Subject: Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp =20 Hi, =20 On Jun 21, 2006, at 1:21 PM, Lucy Yong wrote: Hello JLLR, =20 The draft covers various discovery requirements as mentioned in section = 4.2. Good work. Once thing I would like to get clarification is that the draft focus on = the discovery between a PCC and a PCE, a PCE and domains that the PCE = has visibility and can compute paths, and a PCE and domains that the PCE = can compute paths toward. The draft also mentions that PCE information = is disclosed to PCC. =20 >From these set of discoveries, I could not see if the discoveries also = include the discovery between PCEs and information changes between PCEs. = Maybe I miss them in context. Could you help to clarify? =20 yes it does. PCE originates IGP updates announcing their capabilities = that can be processed by the PCCs or PCEs (acting a PCCs). =20 JP. =20 Best Regards, Lucy=20 =20 _____ =20 From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@orange-ft.com]=20 Sent: Tuesday, June 20, 2006 1:54 AM To: Zhang Renhai; pce@ietf.org Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp =20 Hi Zhang, =20 Please see inline, =20 _____ =20 De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 Envoy=C3=A9 : mardi 20 juin 2006 05:26 =C3=80 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org Objet : Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp Hi, Jean-Louis =20 See inline, please. ----- Original Message -----=20 From: LE ROUX Jean-Louis RD-CORE-LAN = =20 To: Zhang Renhai ; pce@ietf.org=20 Sent: Monday, June 19, 2006 4:23 PM Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp =20 Hi Zhang =20 Thanks for your comments =20 Please see inline, =20 _____ =20 De : Zhang Renhai [mailto:zhangrenhai@huawei.com]=20 Envoy=C3=A9 : mardi 13 juin 2006 09:07 =C3=80 : pce@ietf.org Objet : [Pce] Comments on draft-ietf-pce-disco-proto-igp Hi, all =20 I recently read the draft draft-ietf-pce-disco-proto-igp again, here are = some comments=E3=80=82 =20 When IGP is used as a PCED protocol, the capabilities of pce will be = advertised periodicly along with other lsa/lsp information. In my = opinion, unless the PCE's capabilities change, there is no need for the = PCC to receive and handle the information again. =20 =20 JLLR: But these are standard IGP procedures. This is the same for link = states, they are refreshed even if there is not change. By the way the = refresh interval can be quite large (e.g. 18 hours for IS-IS). =20 =20 =20 Furthermore, if most of the routers in a domain will always have no = request to a PCE, there is also no need for them to maintain the = information. =20 =20 JLLR: In this case PCE discovery is deactivated on these routers and = they will not process the PCED and PCES TLVs... But I don't know if it is possible for a router to be re-configured as a = PCC or have some path computation request after it receives these TLVs = and not processes them, =20 =20 Now if a router is configured as PCC at some point in time, then it = starts processing information carried in PCED and PCES TLVs...(Before = you activate PCE discovery on the PCC the information is stored but not = processed). =20 =20 =20 My concern to PCE-DEST-DOMAINS sub-TLV is that we can't anticipate how = many destination domains a PCE can computate path towards, as a = result,the length of space taken by this capality in the message can't = be controlled. =20 =20 JLLR: Actually you have the same problem with the number of TE-links = advertised by an LSR or the number of reacheable prefixes advertised by = an ABR.=20 One may limit by configuration the number of dest domains advertised. But I still doubt that if it's needed for the PCE to maintain such = information and how a PCE obtains these info?=20 As discussed latter this is a really useful feature that helps PCE = selection and load balancing. In the inter-area case, the can learn this info both via config and via = the IGP (e.g. if the PCE is an ABR, it can easily know attached areas). In the inter-AS case, the PCE can learn this information both via config = and via BGP.=20 =20 =20 So I think if the PCC send a request to a PCE which can't compute the = path for the reason of the destination domain, the PCE can tell the PCC = in the PCrep message the right PCE. =20 =20 JLLR: But how the PCE will have the information? =20 One additional quesion: is it suitable for the PCE to have such ability = to know exactly the destination domain it can compute towards?=20 =20 JLLR: This is actually required. For instance in an inter-AS case, an AS = may be connected to multiple ASs, and there may be multiple PCEs in this = AS (e.g. ASBRs), each responsible for computing path towards a given = neighbord AS. Here you said the neighboring AS, but not the destination AS.=20 =20 It was an example where the destination is located in the neighboring = AS... But the same applies when the destination is located farther. =20 Thanks=20 =20 JL =20 Some functions specified in the PATH-CAMP-CAP sub-TLV are also defined = in the PCEP, a clear division should be made. =20 =20 JLLR: Actually, at the time being the PCEP spec does not define any = capability information. In current PCEP spec, we only mention that detailed capabilites could be = carried in optional sub-TLVs of the Open object (carried in the Open = message). But you are right such capability information may be carried in PCEP. =20 The idea would be to carry simple capabilities in the IGP and more = complex capabilities in PCEP. =20 Anyway I don't really see any issue if we define two ways to carry some = pieces of information: -IGP-based capability discovery is useful for PCCs that don't have a = PCEP session with the PCE. -PCEP-based capability discovery is useful when IGP based discovery is = not activated.=20 This sounds fine to me. =20 Regards, Zhang=20 =20 =20 Thanks for these comments, =20 Regards, =20 JL=20 =20 =20 =20 =20 Cheers, =20 Zhang Renhai _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 --Boundary_(ID_wE6enVrFD2s+bkQPNVlSEA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable

Hi = JP,

 

Does that mean all PCCs and PCEs = under one IGP? How about PCE partitioning? Does a PCC get PCE announcement = from only PCEs it discovers, or from all PCEs within IGP.

 

Looks like I miss = something.

 

Best = Regards,

Lucy

 

From: JP = Vasseur [mailto:jvasseur@cisco.com]
Sent: Wednesday, June 21, = 2006 7:08 PM
To: Lucy Yong
Cc: 'LE ROUX Jean-Louis RD-CORE-LAN'; 'Zhang Renhai'; pce@ietf.org
Subject: Re: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

 

Hi,

 

On Jun 21, 2006, at 1:21 PM, Lucy = Yong wrote:



Hello JLLR,

 

The draft covers various discovery requirements as mentioned = in section 4.2. Good work.

Once thing I would like to get clarification is that the = draft focus on the discovery between a PCC and a PCE, a PCE and domains that = the PCE has visibility and can compute paths, and a PCE and domains that the PCE = can compute paths toward. The draft also mentions that PCE information is = disclosed to PCC.

 

From these set of discoveries, I could not see if the = discoveries also include the discovery between PCEs and information changes between = PCEs. Maybe I miss them in context. Could you help to clarify? =  



yes it does. PCE originates = IGP updates announcing their capabilities that can be processed by the PCCs = or PCEs (acting a PCCs).

 

JP.

 

Best Regards,

Lucy

 

From: LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux@or= ange-ft.com]
Sent: Tuesday, June 20, = 2006 1:54 AM
To: Zhang Renhai; pce@ietf.org
Subject: RE: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

 

=

Hi Zhang,

 

=

Please see inline,

 

=

De : Zhang Renhai = [mailto:zhangrenhai@huawei.com]=
Envoy=C3=A9 : mardi = 20 juin 2006 05:26
=C3=80 : LE ROUX = Jean-Louis RD-CORE-LAN; pce@ietf.org
Objet : Re: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

Hi, = Jean-Louis

 

=

See inline, = please.

----- Original Message -----

From:<= font size=3D1 face=3D=E5=AE=8B=E4=BD=93> LE ROUX Jean-Louis = RD-CORE-LAN

Sent: Monday, June = 19, 2006 4:23 PM

Subject: RE: [Pce] = Comments on = draft-ietf-pce-disco-proto-igp

 

=

Hi Zhang

 

=

Thanks for your = comments

 

=

Please see inline,

 

=

De : Zhang Renhai = [mailto:zhangrenhai@huawei.com]=
Envoy=C3=A9 : mardi = 13 juin 2006 09:07
=C3=80 : pce@ietf.org
Objet : [Pce] = Comments on draft-ietf-pce-disco-proto-igp

Hi, = all

 

=

I recently read the draft draft-ietf-pce-disco-proto-igp again, here are = some comments=E3=80=82

 

=

When IGP is used as a PCED protocol, the capabilities of pce will be = advertised periodicly along with other lsa/lsp information. In my opinion, unless = the PCE's capabilities change,  there is no need for the PCC to receive and handle the information again.  

 

=

JLLR: But these are standard IGP procedures. This is the = same for link states, they are refreshed even if there is not change. By the way = the refresh interval can be quite large (e.g. 18 hours for = IS-IS).

 

=

 

=

 

=

 Furthermore, if most of the routers in a domain will always have no request to a PCE, = there is also no need for them to maintain the = information.  

 

=

JLLR: In this case PCE discovery is deactivated on these = routers and they will not process the PCED and PCES = TLVs...

But I don't know if it is possible for a router to be re-configured as a PCC or have some path computation request after it receives these TLVs and not processes = them,  

 

Now if a router is configured as PCC at some point in time, then it starts processing information carried in PCED and = PCES TLVs...(Before you activate PCE discovery on the PCC the information is = stored but not processed).

 

 

=

 

=

My concern to PCE-DEST-DOMAINS sub-TLV is that we can't anticipate how = many destination domains a PCE can  computate path towards, as a = result,the length of space taken by this capality in the message can't be controlled.  

 

=

JLLR: Actually you have the same problem with the number of TE-links advertised by an LSR or the number of reacheable prefixes advertised by an ABR.

One may limit by configuration the number of dest domains advertised.

But I still doubt that if it's needed for the PCE to maintain such information and = how a PCE obtains these info? 

As discussed latter this is a really useful feature that = helps PCE selection and load balancing.

In the inter-area case, the can learn this info both = via config and via the IGP (e.g. if the PCE is an ABR, it can easily know = attached areas).

In the inter-AS case, the PCE can learn this information both via config and via BGP. 

 

=

 

=

 So I think if the PCC send a request to a PCE which can't compute the path = for the reason of the destination domain, the PCE can tell the PCC in the PCrep message the right PCE.  

 

=

JLLR: But how the PCE will have the = information?

 

=

 One additional quesion: is it suitable for the PCE to have such ability to = know exactly the destination domain it can compute = towards? 

 

=

JLLR: This is actually required. For instance in an = inter-AS case, an AS may be connected to multiple ASs, and there may be = multiple PCEs in this AS (e.g. ASBRs), each responsible for computing path = towards a given neighbord AS.

Here you said the neighboring AS, but not the destination AS. 

 

=

It was an example where the destination is located in the neighboring AS... But the same applies when the destination is located = farther.

 

=

Thanks

 

=

JL

 

=

Some functions specified in the PATH-CAMP-CAP sub-TLV are = also defined in the PCEP,  a clear division should be = made.  

 

=

 JLLR:  Actually, at the time being the PCEP spec = does not define any capability = information.

In current PCEP spec, we only mention that detailed = capabilites could be carried in optional sub-TLVs of the Open object (carried in the = Open message).

But you are right such capability information may be carried = in PCEP.

 

=

The idea would be to carry simple capabilities in the IGP and more complex capabilities in = PCEP.

 

=

Anyway I don't really see any issue if we define two ways to carry some pieces of = information:

-IGP-based capability discovery is useful for PCCs that = don't have a PCEP session with the PCE.

-PCEP-based capability discovery is useful when IGP based = discovery is not activated. 

This sounds fine to me.

 

=

Regards,<= /O:P>

Zhang =

 

=

 

=

Thanks for these = comments,

 

=

Regards,

 

=

JL 

 

=

 

=

 

=

 

=

Cheers,=

 

=

Zhang Renhai

_______________________________= ________________

Pce mailing list

 

--Boundary_(ID_wE6enVrFD2s+bkQPNVlSEA)-- --===============1805794687== 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 --===============1805794687==-- From pce-bounces@lists.ietf.org Thu Jun 22 15:32:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUub-000139-Lb; Thu, 22 Jun 2006 15:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUrq-0006Te-Pp for pce@ietf.org; Thu, 22 Jun 2006 15:29:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUro-0002ry-4A for pce@ietf.org; Thu, 22 Jun 2006 15:29:30 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2006 15:29:28 -0400 X-IronPort-AV: i="4.06,166,1149480000"; d="scan'208,217"; a="90811902:sNHT93359910" 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 k5MJTRYL000109; Thu, 22 Jun 2006 15:29:27 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 15:29:27 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Jun 2006 15:29:22 -0400 In-Reply-To: <002e01c69617$5d5edcb0$d4087c0a@china.huawei.com> References: <002e01c69617$5d5edcb0$d4087c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v750) Message-Id: From: JP Vasseur Subject: Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp Date: Thu, 22 Jun 2006 15:29:02 -0400 To: Lucy Yong X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 Jun 2006 19:29:23.0020 (UTC) FILETIME=[2A6178C0:01C69632] X-Spam-Score: 0.2 (/) X-Scan-Signature: c5add04f47c64532659e0648dc6f4a6c X-Mailman-Approved-At: Thu, 22 Jun 2006 15:32:20 -0400 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="===============0045610990==" Errors-To: pce-bounces@lists.ietf.org --===============0045610990== Content-Type: multipart/alternative; boundary=Apple-Mail-40-898650352 --Apple-Mail-40-898650352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Hi Lucy, On Jun 22, 2006, at 12:17 PM, Lucy Yong wrote: > Hi JP, > > > > Does that mean all PCCs and PCEs under one IGP? How about PCE =20 > partitioning? Does a PCC get PCE announcement from only PCEs it =20 > discovers, or from all PCEs within IGP. > > > > Looks like I miss something. Yes. Not sure how to help you there since the formulation of your question =20= is quite confusing. Let me try to restate what I said: this ID =20 defines a PCE discovery mechanisms based on IGP (compliant with the =20 requirement ID on PCE discovery). All PCC and PCE acting as PCC will =20 discover PCEs thanks to these IGP extensions wherever the LSA/LSP is =20 flooded (see the ID for details). JP. > > > Best Regards, > > Lucy > > > > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Wednesday, June 21, 2006 7:08 PM > To: Lucy Yong > Cc: 'LE ROUX Jean-Louis RD-CORE-LAN'; 'Zhang Renhai'; pce@ietf.org > Subject: Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp > > > > Hi, > > > > On Jun 21, 2006, at 1:21 PM, Lucy Yong wrote: > > > > > Hello JLLR, > > > > The draft covers various discovery requirements as mentioned in =20 > section 4.2. Good work. > > Once thing I would like to get clarification is that the draft =20 > focus on the discovery between a PCC and a PCE, a PCE and domains =20 > that the PCE has visibility and can compute paths, and a PCE and =20 > domains that the PCE can compute paths toward. The draft also =20 > mentions that PCE information is disclosed to PCC. > > > > =46rom these set of discoveries, I could not see if the discoveries =20= > also include the discovery between PCEs and information changes =20 > between PCEs. Maybe I miss them in context. Could you help to clarify? > > > > > yes it does. PCE originates IGP updates announcing their =20 > capabilities that can be processed by the PCCs or PCEs (acting a =20 > PCCs). > > > > JP. > > > > > Best Regards, > > Lucy > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@orange-ft.com] > Sent: Tuesday, June 20, 2006 1:54 AM > To: Zhang Renhai; pce@ietf.org > Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp > > > > Hi Zhang, > > > > Please see inline, > > > > De : Zhang Renhai [mailto:zhangrenhai@huawei.com] > Envoy=C3=A9 : mardi 20 juin 2006 05:26 > =C3=80 : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org > Objet : Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp > > Hi, Jean-Louis > > > > See inline, please. > > ----- Original Message ----- > > From: LE ROUX Jean-Louis RD-CORE-LAN > > To: Zhang Renhai ; pce@ietf.org > > Sent: Monday, June 19, 2006 4:23 PM > > Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp > > > > Hi Zhang > > > > Thanks for your comments > > > > Please see inline, > > > > De : Zhang Renhai [mailto:zhangrenhai@huawei.com] > Envoy=C3=A9 : mardi 13 juin 2006 09:07 > =C3=80 : pce@ietf.org > Objet : [Pce] Comments on draft-ietf-pce-disco-proto-igp > > Hi, all > > > > I recently read the draft draft-ietf-pce-disco-proto-igp again, =20 > here are some comments=E3=80=82 > > > > When IGP is used as a PCED protocol, the capabilities of pce will =20 > be advertised periodicly along with other lsa/lsp information. In =20 > my opinion, unless the PCE's capabilities change, there is no need =20= > for the PCC to receive and handle the information again. > > > > JLLR: But these are standard IGP procedures. This is the same for =20 > link states, they are refreshed even if there is not change. By the =20= > way the refresh interval can be quite large (e.g. 18 hours for IS-IS). > > > > > > > > Furthermore, if most of the routers in a domain will always have =20 > no request to a PCE, there is also no need for them to maintain the =20= > information. > > > > JLLR: In this case PCE discovery is deactivated on these routers =20 > and they will not process the PCED and PCES TLVs... > > But I don't know if it is possible for a router to be re-configured =20= > as a PCC or have some path computation request after it receives =20 > these TLVs and not processes them, > > > > Now if a router is configured as PCC at some point in time, then it =20= > starts processing information carried in PCED and PCES TLVs...=20 > (Before you activate PCE discovery on the PCC the information is =20 > stored but not processed). > > > > > > > > My concern to PCE-DEST-DOMAINS sub-TLV is that we can't anticipate =20 > how many destination domains a PCE can computate path towards, as =20 > a result,the length of space taken by this capality in the message =20 > can't be controlled. > > > > JLLR: Actually you have the same problem with the number of TE-=20 > links advertised by an LSR or the number of reacheable prefixes =20 > advertised by an ABR. > > One may limit by configuration the number of dest domains advertised. > > But I still doubt that if it's needed for the PCE to maintain such =20 > information and how a PCE obtains these info? > > As discussed latter this is a really useful feature that helps PCE =20 > selection and load balancing. > > In the inter-area case, the can learn this info both via config and =20= > via the IGP (e.g. if the PCE is an ABR, it can easily know attached =20= > areas). > > In the inter-AS case, the PCE can learn this information both via =20 > config and via BGP. > > > > > > So I think if the PCC send a request to a PCE which can't compute =20 > the path for the reason of the destination domain, the PCE can tell =20= > the PCC in the PCrep message the right PCE. > > > > JLLR: But how the PCE will have the information? > > > > One additional quesion: is it suitable for the PCE to have such =20 > ability to know exactly the destination domain it can compute towards? > > > > JLLR: This is actually required. For instance in an inter-AS case, =20 > an AS may be connected to multiple ASs, and there may be multiple =20 > PCEs in this AS (e.g. ASBRs), each responsible for computing path =20 > towards a given neighbord AS. > > Here you said the neighboring AS, but not the destination AS. > > > > It was an example where the destination is located in the =20 > neighboring AS... But the same applies when the destination is =20 > located farther. > > > > Thanks > > > > JL > > > > Some functions specified in the PATH-CAMP-CAP sub-TLV are also =20 > defined in the PCEP, a clear division should be made. > > > > JLLR: Actually, at the time being the PCEP spec does not define =20 > any capability information. > > In current PCEP spec, we only mention that detailed capabilites =20 > could be carried in optional sub-TLVs of the Open object (carried =20 > in the Open message). > > But you are right such capability information may be carried in PCEP. > > > > The idea would be to carry simple capabilities in the IGP and more =20 > complex capabilities in PCEP. > > > > Anyway I don't really see any issue if we define two ways to carry =20 > some pieces of information: > > -IGP-based capability discovery is useful for PCCs that don't have =20 > a PCEP session with the PCE. > > -PCEP-based capability discovery is useful when IGP based discovery =20= > is not activated. > > This sounds fine to me. > > > > Regards, > > Zhang > > > > > > Thanks for these comments, > > > > Regards, > > > > JL > > > > > > > > > > Cheers, > > > > Zhang Renhai > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > --Apple-Mail-40-898650352 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Lucy,

On = Jun 22, 2006, at 12:17 PM, Lucy Yong wrote:

Hi JP,

Does that mean all = PCCs and PCEs under one IGP? How about PCE partitioning? Does a PCC get = PCE announcement from only PCEs it discovers, or from all PCEs within = IGP.

=C2=A0

Looks like I miss = something.

Yes.

Not sure how to help you = there since the formulation of your question is quite confusing. Let me = try to restate what I said: this ID defines a PCE discovery mechanisms = based on IGP (compliant with the requirement ID on PCE discovery). All = PCC and PCE acting as PCC will discover PCEs thanks to these IGP = extensions wherever the LSA/LSP is flooded (see the ID for = details).=C2=A0

JP.

=C2=A0

Best Regards,

Lucy

From: JP Vasseur [mailto:jvasseur@cisco.com] =
Wednesday, June = 21, 2006 7:08 PM
= Lucy = Yong
'LE ROUX = Jean-Louis RD-CORE-LAN'; 'Zhang Renhai'; pce@ietf.org
Re: [Pce] = Comments on draft-ietf-pce-disco-proto-igp=C2=A0

<= P class=3D"MsoNormal">Hi,

=C2=A0

<= P class=3D"MsoNormal">On Jun 21, 2006, at 1:21 PM, = Lucy = Yong = wrote:



Hello = JLLR,

=C2=A0

The draft covers various discovery requirements as = mentioned in section 4.2. Good work.

Once thing I would like to get clarification is that the = draft focus on the discovery between a PCC and a PCE, a PCE and domains = that the PCE has visibility and can compute paths, and a PCE and domains = that the PCE can compute paths toward. The draft also mentions that PCE = information is disclosed to PCC.

=C2=A0

=46rom these set of discoveries, I could not see if the = discoveries also include the discovery between PCEs and information = changes between PCEs. Maybe I miss them in context. Could you help to = clarify? =C2=A0



yes it does. = PCE originates IGP updates announcing their capabilities that can be = processed by the PCCs or PCEs (acting a PCCs).=C2=A0

JP.

Best Regards,

Lucy

=C2=A0

LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux@orange-ft.com]
Tuesday, June 20, = 2006 1:54 AM
Zhang Renhai; = RE: [Pce] = Comments on draft-ietf-pce-disco-proto-igp

Hi Zhang,

=C2=A0Please see inline,=

Zhang Renhai []
mardi 20 juin = 2006 05:26
LE ROUX = Jean-Louis RD-CORE-LAN; pce@ietf.org
Objet=C2=A0: Re: [Pce] Comments on = draft-ietf-pce-disco-proto-igpHi, = Jean-Louis

=C2=A0See inline, = please.

=

----- Original Message -----

Monday, June 19, 2006 4:23 = PM

RE: [Pce] Comments on = draft-ietf-pce-disco-proto-igp

Hi Zhang

=C2=A0Thanks for your comments

=C2=A0Please see inline,=

Zhang Renhai []
mardi 13 juin = 2006 09:07
 [Pce] Comments on = draft-ietf-pce-disco-proto-igpHi, all=C2=A0I recently read the draft = draft-ietf-pce-disco-proto-igp again, here are some = comments=E3=80=82=C2=A0When IGP is used=C2=A0as a PCED protocol, = the capabilities of pce will be advertised periodicly along with other = lsa/lsp information. In my opinion, unless the PCE's capabilities = change,=C2=A0 there is no need for the PCC to receive and=C2=A0handle = the information again.=C2=A0=C2=A0

=C2=A0JLLR: In this case PCE discovery is deactivated on these = routers and they will not process the PCED and PCES = TLVs...But I don't know if it is possible for a = router to be re-configured=C2=A0as a PCC or have some=C2=A0path = computation request=C2=A0after=C2=A0it receives these TLVs and not = processes them,=C2=A0=C2=A0Now if a router is configured as PCC at some point in time, = then=C2=A0it=C2=A0starts processing=C2=A0information carried in PCED and = PCES TLVs...(Before you activate PCE discovery on the PCC the = information is stored but not processed).=

=

=C2=A0=C2=A0My concern to PCE-DEST-DOMAINS sub-TLV=C2=A0is= that we can't anticipate how many destination domains a PCE can = =C2=A0computate path towards,=C2=A0as a result,the length of space taken = by this capality in the message can't be = controlled.=C2=A0=C2=A0

=C2=A0JLLR: Actually you have the same problem with the number of = TE-links advertised by=C2=A0an LSR or the number of reacheable prefixes = advertised by an ABR.

One may limit by configuration the number of dest domains = advertised.But I still doubt = that if it's needed for the PCE to maintain such information and how a = PCE obtains these info?

As discussed latter this is a really useful feature that = helps PCE selection and load balancing.In=C2=A0the inter-area case, the can learn this info both = via config and via the IGP (e.g. if the PCE is an ABR, it can easily = know attached areas).


In the inter-AS case, the PCE can learn this information = both=C2=A0via=C2=A0config=C2=A0and via BGP.=C2=A0=

=

=C2=A0=C2=A0=C2=A0So I think if the PCC send a request = to a PCE which can't compute the path for the reason of the destination = domain, the PCE can tell the PCC in the PCrep message=C2=A0the right = PCE.=C2=A0=C2=A0

=C2=A0JLLR: But how the PCE will have the = information?

=C2=A0=C2=A0One additional quesion: is it suitable = for the PCE to have such ability to know exactly the destination domain = it can compute towards?=C2=A0

=C2=A0JLLR: This is actually=C2=A0required. For instance in an = inter-AS case, an AS may be connected to multiple ASs, and=C2=A0there = may be multiple PCEs in this AS (e.g. ASBRs), each responsible for = computing path towards a given neighbord AS.Here you said the = neighboring AS, but not the destination AS.=C2=A0=C2=A0It was an example where the destination is located in the = neighboring AS... But the same applies when the destination is located = farther.

=C2=A0Thanks

=C2=A0JL

=
=

=C2=A0Some functions specified in the = PATH-CAMP-CAP sub-TLV are also=C2=A0defined=C2=A0in the PCEP,=C2=A0 a = clear division should be made.=C2=A0=C2=A0

=C2=A0=C2=A0JLLR: =C2=A0Actually, at the time being the PCEP spec = does not define any capability information.In current PCEP spec, we only mention that detailed = capabilites could be carried in optional sub-TLVs of the Open object = (carried in the Open message).But you are right such capability information may be = carried in PCEP.

=C2=A0The idea=C2=A0would be=C2=A0to carry=C2=A0simple = capabilities=C2=A0in the IGP and=C2=A0more complex capabilities in = PCEP.

=C2=A0Anyway I don't really see any issue if we define two ways = to=C2=A0carry=C2=A0some pieces of information:-IGP-based capability discovery is useful for PCCs that = don't have a PCEP session with the PCE.-PCEP-based capability discovery is useful when IGP based = discovery is not activated.=C2=A0This sounds fine to = me.

=C2=A0

=
=

=C2=A0=C2=A0Thanks for these comments,=C2=A0Regards,

=C2=A0JL=C2=A0

= --Apple-Mail-40-898650352-- --===============0045610990== 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 --===============0045610990==-- From pce-bounces@lists.ietf.org Fri Jun 23 08:09:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtkTX-0003Ss-6L; Fri, 23 Jun 2006 08:09:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtagS-0002xj-So for pce@ietf.org; Thu, 22 Jun 2006 21:42:08 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtagR-00034f-7i for pce@ietf.org; Thu, 22 Jun 2006 21:42:08 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 19:31:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp Date: Wed, 21 Jun 2006 19:31:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comments on draft-ietf-pce-disco-proto-igp Thread-Index: AcaUHWB0qx9ZyqXOSBKUfPHjK+w2XAAFm2rwAEgxYnAAALqUQA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Lucy Yong" , "Zhang Renhai" , X-OriginalArrivalTime: 21 Jun 2006 17:31:51.0365 (UTC) FILETIME=[94DA8F50:01C69558] X-Spam-Score: 0.0 (/) X-Scan-Signature: cadb9ba0ba1c1ba4f99ac017158fabc3 X-Mailman-Approved-At: Fri, 23 Jun 2006 08:09:25 -0400 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="===============0564314370==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0564314370== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69558.9478BE28" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69558.9478BE28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgTHVjeSwNCiANClRoYW5rcyBmb3IgdGhpcyBmZWVkYmFjaywNCiANCkEgUENFIHRoYXQgc2Vu ZHMgYSByZXF1ZXN0IHRvIGFub3RoZXIgUENFIGNhbiBiZSBjb25zaWRlcmVkIGFzIGEgUENDLCBp dCBpcyBhY3R1YWxseSBhY3RpbmcgYXMgYSBQQ0MuIEhlbmNlLCBhcyBkaXNjdXNzZWQgaW4gdGhl IHJlcXVpcmVtZW50IElELCB0aGVyZSBpcyBubyBuZWVkIHRvLCBhbmQgd2UgZG8gbm90LCBtYWtl IHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIGRpc2NvdmVyeSBieSBQQ0NzIGFuZCBkaXNjb3Zlcnkg YnkgUENFcy4uLg0KQSBQQ0UgdGhhdCB3YW50cyB0byBkaXNjb3ZlciBvdGhlciBQQ0VzIGluIHRo ZSBJR1AgZG9tYWluIHNpbXBseSBuZWVkcyB0byBsaXN0ZW4gdG8gSUdQIGFkdmVydGlzZW1lbnRz IGRlZmluZWQgaW4gdGhpcyBkcmFmdCAgKGkuZS4gaXQgYWN0cyBhcyBhIFBDQykuDQogDQpIb3Bl IHRoaXMgY2xhcmlmaWVzDQogDQpCZXN0IFJlZ2FyZHMsDQogDQpKTA0KIA0KIA0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCglEZSA6IEx1Y3kgWW9uZyBbbWFpbHRvOmx1 Y3l5b25nQGh1YXdlaS5jb21dIA0KCUVudm95w6kgOiBtZXJjcmVkaSAyMSBqdWluIDIwMDYgMTk6 MjENCgnDgCA6IExFIFJPVVggSmVhbi1Mb3VpcyBSRC1DT1JFLUxBTjsgJ1poYW5nIFJlbmhhaSc7 IHBjZUBpZXRmLm9yZw0KCU9iamV0IDogUkU6IFtQY2VdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYt cGNlLWRpc2NvLXByb3RvLWlncA0KCQ0KCQ0KDQoJSGVsbG8gSkxMUiwNCg0KCSANCg0KCVRoZSBk cmFmdCBjb3ZlcnMgdmFyaW91cyBkaXNjb3ZlcnkgcmVxdWlyZW1lbnRzIGFzIG1lbnRpb25lZCBp biBzZWN0aW9uIDQuMi4gR29vZCB3b3JrLg0KDQoJT25jZSB0aGluZyBJIHdvdWxkIGxpa2UgdG8g Z2V0IGNsYXJpZmljYXRpb24gaXMgdGhhdCB0aGUgZHJhZnQgZm9jdXMgb24gdGhlIGRpc2NvdmVy eSBiZXR3ZWVuIGEgUENDIGFuZCBhIFBDRSwgYSBQQ0UgYW5kIGRvbWFpbnMgdGhhdCB0aGUgUENF IGhhcyB2aXNpYmlsaXR5IGFuZCBjYW4gY29tcHV0ZSBwYXRocywgYW5kIGEgUENFIGFuZCBkb21h aW5zIHRoYXQgdGhlIFBDRSBjYW4gY29tcHV0ZSBwYXRocyB0b3dhcmQuIFRoZSBkcmFmdCBhbHNv IG1lbnRpb25zIHRoYXQgUENFIGluZm9ybWF0aW9uIGlzIGRpc2Nsb3NlZCB0byBQQ0MuDQoNCgkg DQoNCglGcm9tIHRoZXNlIHNldCBvZiBkaXNjb3ZlcmllcywgSSBjb3VsZCBub3Qgc2VlIGlmIHRo ZSBkaXNjb3ZlcmllcyBhbHNvIGluY2x1ZGUgdGhlIGRpc2NvdmVyeSBiZXR3ZWVuIFBDRXMgYW5k IGluZm9ybWF0aW9uIGNoYW5nZXMgYmV0d2VlbiBQQ0VzLiBNYXliZSBJIG1pc3MgdGhlbSBpbiBj b250ZXh0LiBDb3VsZCB5b3UgaGVscCB0byBjbGFyaWZ5PyAgDQoNCgkgDQoNCglCZXN0IFJlZ2Fy ZHMsDQoNCglMdWN5IA0KDQoJIA0KDQoJDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQoNCglGcm9tOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4gW21haWx0bzpqZWFu bG91aXMubGVyb3V4QG9yYW5nZS1mdC5jb21dIA0KCVNlbnQ6IFR1ZXNkYXksIEp1bmUgMjAsIDIw MDYgMTo1NCBBTQ0KCVRvOiBaaGFuZyBSZW5oYWk7IHBjZUBpZXRmLm9yZw0KCVN1YmplY3Q6IFJF OiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3ANCg0KCSAN Cg0KCUhpIFpoYW5nLA0KDQoJIA0KDQoJUGxlYXNlIHNlZSBpbmxpbmUsDQoNCgkJIA0KDQoJCQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoJCURlIDogWmhhbmcgUmVuaGFp IFttYWlsdG86emhhbmdyZW5oYWlAaHVhd2VpLmNvbV0gDQoJCUVudm95w6kgOiBtYXJkaSAyMCBq dWluIDIwMDYgMDU6MjYNCgkJw4AgOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU47IHBj ZUBpZXRmLm9yZw0KCQlPYmpldCA6IFJlOiBbUGNlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXBj ZS1kaXNjby1wcm90by1pZ3ANCg0KCQlIaSwgSmVhbi1Mb3Vpcw0KDQoJCSANCg0KCQlTZWUgaW5s aW5lLCBwbGVhc2UuDQoNCgkJCS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQoNCgkJCUZy b206IExFIFJPVVggSmVhbi1Mb3VpcyBSRC1DT1JFLUxBTiA8bWFpbHRvOmplYW5sb3Vpcy5sZXJv dXhAb3JhbmdlLWZ0LmNvbT4gIA0KDQoJCQlUbzogWmhhbmcgUmVuaGFpIDxtYWlsdG86emhhbmdy ZW5oYWlAaHVhd2VpLmNvbT4gIDsgcGNlQGlldGYub3JnIA0KDQoJCQlTZW50OiBNb25kYXksIEp1 bmUgMTksIDIwMDYgNDoyMyBQTQ0KDQoJCQlTdWJqZWN0OiBSRTogW1BjZV0gQ29tbWVudHMgb24g ZHJhZnQtaWV0Zi1wY2UtZGlzY28tcHJvdG8taWdwDQoNCgkJCSANCg0KCQkJSGkgWmhhbmcNCg0K CQkJIA0KDQoJCQlUaGFua3MgZm9yIHlvdXIgY29tbWVudHMNCg0KCQkJIA0KDQoJCQlQbGVhc2Ug c2VlIGlubGluZSwNCg0KCQkJCSANCg0KCQkJCQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KDQoJCQkJRGUgOiBaaGFuZyBSZW5oYWkgW21haWx0bzp6aGFuZ3JlbmhhaUBodWF3 ZWkuY29tXSANCgkJCQlFbnZvecOpIDogbWFyZGkgMTMganVpbiAyMDA2IDA5OjA3DQoJCQkJw4Ag OiBwY2VAaWV0Zi5vcmcNCgkJCQlPYmpldCA6IFtQY2VdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYt cGNlLWRpc2NvLXByb3RvLWlncA0KDQoJCQkJSGksIGFsbA0KDQoJCQkJIA0KDQoJCQkJSSByZWNl bnRseSByZWFkIHRoZSBkcmFmdCBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3AgYWdhaW4s IGhlcmUgYXJlIHNvbWUgY29tbWVudHPjgIINCg0KCQkJCSANCg0KCQkJCVdoZW4gSUdQIGlzIHVz ZWQgYXMgYSBQQ0VEIHByb3RvY29sLCB0aGUgY2FwYWJpbGl0aWVzIG9mIHBjZSB3aWxsIGJlIGFk dmVydGlzZWQgcGVyaW9kaWNseSBhbG9uZyB3aXRoIG90aGVyIGxzYS9sc3AgaW5mb3JtYXRpb24u IEluIG15IG9waW5pb24sIHVubGVzcyB0aGUgUENFJ3MgY2FwYWJpbGl0aWVzIGNoYW5nZSwgIHRo ZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBQQ0MgdG8gcmVjZWl2ZSBhbmQgaGFuZGxlIHRoZSBpbmZv cm1hdGlvbiBhZ2Fpbi4gIA0KDQoJCQkJIA0KDQoJCQkJSkxMUjogQnV0IHRoZXNlIGFyZSBzdGFu ZGFyZCBJR1AgcHJvY2VkdXJlcy4gVGhpcyBpcyB0aGUgc2FtZSBmb3IgbGluayBzdGF0ZXMsIHRo ZXkgYXJlIHJlZnJlc2hlZCBldmVuIGlmIHRoZXJlIGlzIG5vdCBjaGFuZ2UuIEJ5IHRoZSB3YXkg dGhlIHJlZnJlc2ggaW50ZXJ2YWwgY2FuIGJlIHF1aXRlIGxhcmdlIChlLmcuIDE4IGhvdXJzIGZv ciBJUy1JUykuDQoNCgkJCQkgDQoNCgkJCQkgDQoNCgkJCQkgDQoNCgkJCQkgRnVydGhlcm1vcmUs IGlmIG1vc3Qgb2YgdGhlIHJvdXRlcnMgaW4gYSBkb21haW4gd2lsbCBhbHdheXMgaGF2ZSBubyBy ZXF1ZXN0IHRvIGEgUENFLCB0aGVyZSBpcyBhbHNvIG5vIG5lZWQgZm9yIHRoZW0gdG8gbWFpbnRh aW4gdGhlIGluZm9ybWF0aW9uLiAgDQoNCgkJCQkgDQoNCgkJCQlKTExSOiBJbiB0aGlzIGNhc2Ug UENFIGRpc2NvdmVyeSBpcyBkZWFjdGl2YXRlZCBvbiB0aGVzZSByb3V0ZXJzIGFuZCB0aGV5IHdp bGwgbm90IHByb2Nlc3MgdGhlIFBDRUQgYW5kIFBDRVMgVExWcy4uLg0KDQoJCUJ1dCBJIGRvbid0 IGtub3cgaWYgaXQgaXMgcG9zc2libGUgZm9yIGEgcm91dGVyIHRvIGJlIHJlLWNvbmZpZ3VyZWQg YXMgYSBQQ0Mgb3IgaGF2ZSBzb21lIHBhdGggY29tcHV0YXRpb24gcmVxdWVzdCBhZnRlciBpdCBy ZWNlaXZlcyB0aGVzZSBUTFZzIGFuZCBub3QgcHJvY2Vzc2VzIHRoZW0sICANCg0KCQkgDQoNCgkJ Tm93IGlmIGEgcm91dGVyIGlzIGNvbmZpZ3VyZWQgYXMgUENDIGF0IHNvbWUgcG9pbnQgaW4gdGlt ZSwgdGhlbiBpdCBzdGFydHMgcHJvY2Vzc2luZyBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIFBDRUQg YW5kIFBDRVMgVExWcy4uLihCZWZvcmUgeW91IGFjdGl2YXRlIFBDRSBkaXNjb3Zlcnkgb24gdGhl IFBDQyB0aGUgaW5mb3JtYXRpb24gaXMgc3RvcmVkIGJ1dCBub3QgcHJvY2Vzc2VkKS4NCg0KCQkg DQoNCgkJCQkgDQoNCgkJCQkgDQoNCgkJCQlNeSBjb25jZXJuIHRvIFBDRS1ERVNULURPTUFJTlMg c3ViLVRMViBpcyB0aGF0IHdlIGNhbid0IGFudGljaXBhdGUgaG93IG1hbnkgZGVzdGluYXRpb24g ZG9tYWlucyBhIFBDRSBjYW4gIGNvbXB1dGF0ZSBwYXRoIHRvd2FyZHMsIGFzIGEgcmVzdWx0LHRo ZSBsZW5ndGggb2Ygc3BhY2UgdGFrZW4gYnkgdGhpcyBjYXBhbGl0eSBpbiB0aGUgbWVzc2FnZSBj YW4ndCBiZSBjb250cm9sbGVkLiAgDQoNCgkJCQkgDQoNCgkJCQlKTExSOiBBY3R1YWxseSB5b3Ug aGF2ZSB0aGUgc2FtZSBwcm9ibGVtIHdpdGggdGhlIG51bWJlciBvZiBURS1saW5rcyBhZHZlcnRp c2VkIGJ5IGFuIExTUiBvciB0aGUgbnVtYmVyIG9mIHJlYWNoZWFibGUgcHJlZml4ZXMgYWR2ZXJ0 aXNlZCBieSBhbiBBQlIuIA0KDQoJCQkJT25lIG1heSBsaW1pdCBieSBjb25maWd1cmF0aW9uIHRo ZSBudW1iZXIgb2YgZGVzdCBkb21haW5zIGFkdmVydGlzZWQuDQoNCgkJQnV0IEkgc3RpbGwgZG91 YnQgdGhhdCBpZiBpdCdzIG5lZWRlZCBmb3IgdGhlIFBDRSB0byBtYWludGFpbiBzdWNoIGluZm9y bWF0aW9uIGFuZCBob3cgYSBQQ0Ugb2J0YWlucyB0aGVzZSBpbmZvPyANCg0KCQlBcyBkaXNjdXNz ZWQgbGF0dGVyIHRoaXMgaXMgYSByZWFsbHkgdXNlZnVsIGZlYXR1cmUgdGhhdCBoZWxwcyBQQ0Ug c2VsZWN0aW9uIGFuZCBsb2FkIGJhbGFuY2luZy4NCg0KCQlJbiB0aGUgaW50ZXItYXJlYSBjYXNl LCB0aGUgY2FuIGxlYXJuIHRoaXMgaW5mbyBib3RoIHZpYSBjb25maWcgYW5kIHZpYSB0aGUgSUdQ IChlLmcuIGlmIHRoZSBQQ0UgaXMgYW4gQUJSLCBpdCBjYW4gZWFzaWx5IGtub3cgYXR0YWNoZWQg YXJlYXMpLg0KDQoJCUluIHRoZSBpbnRlci1BUyBjYXNlLCB0aGUgUENFIGNhbiBsZWFybiB0aGlz IGluZm9ybWF0aW9uIGJvdGggdmlhIGNvbmZpZyBhbmQgdmlhIEJHUC4gDQoNCgkJCQkgDQoNCgkJ CQkgDQoNCgkJCQkgU28gSSB0aGluayBpZiB0aGUgUENDIHNlbmQgYSByZXF1ZXN0IHRvIGEgUENF IHdoaWNoIGNhbid0IGNvbXB1dGUgdGhlIHBhdGggZm9yIHRoZSByZWFzb24gb2YgdGhlIGRlc3Rp bmF0aW9uIGRvbWFpbiwgdGhlIFBDRSBjYW4gdGVsbCB0aGUgUENDIGluIHRoZSBQQ3JlcCBtZXNz YWdlIHRoZSByaWdodCBQQ0UuICANCg0KCQkJCSANCg0KCQkJCUpMTFI6IEJ1dCBob3cgdGhlIFBD RSB3aWxsIGhhdmUgdGhlIGluZm9ybWF0aW9uPw0KDQoJCQkJIA0KDQoJCQkJIE9uZSBhZGRpdGlv bmFsIHF1ZXNpb246IGlzIGl0IHN1aXRhYmxlIGZvciB0aGUgUENFIHRvIGhhdmUgc3VjaCBhYmls aXR5IHRvIGtub3cgZXhhY3RseSB0aGUgZGVzdGluYXRpb24gZG9tYWluIGl0IGNhbiBjb21wdXRl IHRvd2FyZHM/IA0KDQoJCQkJIA0KDQoJCQkJSkxMUjogVGhpcyBpcyBhY3R1YWxseSByZXF1aXJl ZC4gRm9yIGluc3RhbmNlIGluIGFuIGludGVyLUFTIGNhc2UsIGFuIEFTIG1heSBiZSBjb25uZWN0 ZWQgdG8gbXVsdGlwbGUgQVNzLCBhbmQgdGhlcmUgbWF5IGJlIG11bHRpcGxlIFBDRXMgaW4gdGhp cyBBUyAoZS5nLiBBU0JScyksIGVhY2ggcmVzcG9uc2libGUgZm9yIGNvbXB1dGluZyBwYXRoIHRv d2FyZHMgYSBnaXZlbiBuZWlnaGJvcmQgQVMuDQoNCgkJSGVyZSB5b3Ugc2FpZCB0aGUgbmVpZ2hi b3JpbmcgQVMsIGJ1dCBub3QgdGhlIGRlc3RpbmF0aW9uIEFTLiANCg0KCQkgDQoNCgkJSXQgd2Fz IGFuIGV4YW1wbGUgd2hlcmUgdGhlIGRlc3RpbmF0aW9uIGlzIGxvY2F0ZWQgaW4gdGhlIG5laWdo Ym9yaW5nIEFTLi4uIEJ1dCB0aGUgc2FtZSBhcHBsaWVzIHdoZW4gdGhlIGRlc3RpbmF0aW9uIGlz IGxvY2F0ZWQgZmFydGhlci4NCg0KCQkgDQoNCgkJVGhhbmtzIA0KDQoJCSANCg0KCQlKTA0KDQoJ CQkJIA0KDQoJCQkJU29tZSBmdW5jdGlvbnMgc3BlY2lmaWVkIGluIHRoZSBQQVRILUNBTVAtQ0FQ IHN1Yi1UTFYgYXJlIGFsc28gZGVmaW5lZCBpbiB0aGUgUENFUCwgIGEgY2xlYXIgZGl2aXNpb24g c2hvdWxkIGJlIG1hZGUuICANCg0KCQkJCSANCg0KCQkJCSBKTExSOiAgQWN0dWFsbHksIGF0IHRo ZSB0aW1lIGJlaW5nIHRoZSBQQ0VQIHNwZWMgZG9lcyBub3QgZGVmaW5lIGFueSBjYXBhYmlsaXR5 IGluZm9ybWF0aW9uLg0KDQoJCQkJSW4gY3VycmVudCBQQ0VQIHNwZWMsIHdlIG9ubHkgbWVudGlv biB0aGF0IGRldGFpbGVkIGNhcGFiaWxpdGVzIGNvdWxkIGJlIGNhcnJpZWQgaW4gb3B0aW9uYWwg c3ViLVRMVnMgb2YgdGhlIE9wZW4gb2JqZWN0IChjYXJyaWVkIGluIHRoZSBPcGVuIG1lc3NhZ2Up Lg0KDQoJCQkJQnV0IHlvdSBhcmUgcmlnaHQgc3VjaCBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIG1h eSBiZSBjYXJyaWVkIGluIFBDRVAuDQoNCgkJCQkgDQoNCgkJCQlUaGUgaWRlYSB3b3VsZCBiZSB0 byBjYXJyeSBzaW1wbGUgY2FwYWJpbGl0aWVzIGluIHRoZSBJR1AgYW5kIG1vcmUgY29tcGxleCBj YXBhYmlsaXRpZXMgaW4gUENFUC4NCg0KCQkJCSANCg0KCQkJCUFueXdheSBJIGRvbid0IHJlYWxs eSBzZWUgYW55IGlzc3VlIGlmIHdlIGRlZmluZSB0d28gd2F5cyB0byBjYXJyeSBzb21lIHBpZWNl cyBvZiBpbmZvcm1hdGlvbjoNCg0KCQkJCS1JR1AtYmFzZWQgY2FwYWJpbGl0eSBkaXNjb3Zlcnkg aXMgdXNlZnVsIGZvciBQQ0NzIHRoYXQgZG9uJ3QgaGF2ZSBhIFBDRVAgc2Vzc2lvbiB3aXRoIHRo ZSBQQ0UuDQoNCgkJCQktUENFUC1iYXNlZCBjYXBhYmlsaXR5IGRpc2NvdmVyeSBpcyB1c2VmdWwg d2hlbiBJR1AgYmFzZWQgZGlzY292ZXJ5IGlzIG5vdCBhY3RpdmF0ZWQuIA0KDQoJCVRoaXMgc291 bmRzIGZpbmUgdG8gbWUuDQoNCgkJIA0KDQoJCVJlZ2FyZHMsDQoNCgkJWmhhbmcgDQoNCgkJCQkg DQoNCgkJCQkgDQoNCgkJCQlUaGFua3MgZm9yIHRoZXNlIGNvbW1lbnRzLA0KDQoJCQkJIA0KDQoJ CQkJUmVnYXJkcywNCg0KCQkJCSANCg0KCQkJCUpMIA0KDQoJCQkJIA0KDQoJCQkJIA0KDQoJCQkJ IA0KDQoJCQkJIA0KDQoJCQkJQ2hlZXJzLA0KDQoJCQkJIA0KDQoJCQkJWmhhbmcgUmVuaGFpDQoN Cg== ------_=_NextPart_001_01C69558.9478BE28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4 bWxuczp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1l cXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxN RVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMjg3MyIgbmFtZT1HRU5FUkFUT1I+PCEtLVtp ZiAhbXNvXT4NCjxTVFlMRT52XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0N Cm9cOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kd1w6KiB7DQoJQkVIQVZJ T1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQouc2hhcGUgew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1 bHQjVk1MKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZSBuYW1lPSJT dHJlZXQiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpz bWFydHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PG86U21hcnRUYWdUeXBlIA0KbmFtZT0iYWRkcmVz cyIgDQpuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0 dGFncyI+PC9vOlNtYXJ0VGFnVHlwZT48IS0tW2lmICFtc29dPg0KPFNUWUxFPnN0MVw6KiB7DQoJ QkVIQVZJT1I6IHVybCgjZGVmYXVsdCNpZW9vdWkpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+ DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IENvdXJpZXI7DQp9DQpAZm9udC1m YWNlIHsNCglmb250LWZhbWlseTog5a6L5L2TOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1p bHk6IFRhaG9tYTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0K QHBhZ2UgU2VjdGlvbjEge3NpemU6IDguNWluIDExLjBpbjsgbWFyZ2luOiAxLjBpbiAxLjI1aW4g MS4waW4gMS4yNWluOyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46 IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiINCn0NCkxJLk1zb05v cm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlM WTogIlRpbWVzIE5ldyBSb21hbiINCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJw dDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9 DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0K U1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBibHVlOyBURVhU LURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZPTlQtV0VJ R0hUOiBub3JtYWw7IENPTE9SOiBibHVlOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtRkFNSUxZ OiBDb3VyaWVyOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10eXBlOiBwZXJzb25h bC1yZXBseQ0KfQ0KRElWLlNlY3Rpb24xIHsNCglwYWdlOiBTZWN0aW9uMQ0KfQ0KPC9TVFlMRT4N CjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L0hF QUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZMaW5rPWJsdWUgbGluaz1ibHVlIGJnQ29sb3I9d2hpdGU+ DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+ PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpIEx1Y3ksPC9GT05UPjwv U1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQ2ODAzMjQx Ny0yMTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05U PjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNz PTQ2ODAzMjQxNy0yMTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXpl PTI+VGhhbmtzIGZvciB0aGlzIGZlZWRiYWNrLDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFj ZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+ DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+ PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkEmbmJzcDtQQ0UgdGhhdCBz ZW5kcyBhIHJlcXVlc3QgdG8gYW5vdGhlciBQQ0UgY2FuIGJlIA0KY29uc2lkZXJlZCBhcyBhIFBD QywgaXQgaXMgYWN0dWFsbHkgYWN0aW5nIGFzIGEgUENDLiBIZW5jZSwgYXMgZGlzY3Vzc2VkIGlu IHRoZSANCnJlcXVpcmVtZW50IElELCZuYnNwO3RoZXJlIGlzIG5vIG5lZWQgdG8sIGFuZCB3ZSBk byBub3QsIG1ha2UgdGhlIGRpc3RpbmN0aW9uIA0KYmV0d2VlbiBkaXNjb3ZlcnkgYnkgUENDcyBh bmQgZGlzY292ZXJ5IGJ5IFBDRXMuLi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDY4MDMyNDE3LTIxMDYyMDA2PjxGT05UIGZhY2U9QXJp YWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj5BIFBDRSB0aGF0IHdhbnRzIHRvIGRpc2NvdmVyIG90 aGVyIFBDRXMgaW4gdGhlIElHUCBkb21haW4gDQpzaW1wbHkgbmVlZHMgdG8gbGlzdGVuIHRvIElH UCBhZHZlcnRpc2VtZW50cyBkZWZpbmVkIGluIHRoaXMgDQpkcmFmdCZuYnNwOyZuYnNwOyhpLmUu IGl0IGFjdHMgYXMgYSBQQ0MpLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFjZT1BcmlhbCAN CmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NjgwMzI0MTctMjEwNjIwMDY+PEZPTlQgZmFj ZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhvcGUgdGhpcyBjbGFyaWZpZXM8L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDY4MDMy NDE3LTIxMDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZP TlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9NDY4MDMyNDE3LTIxMDYyMDA2PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNp emU9Mj5CZXN0IFJlZ2FyZHMsPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGln bj1sZWZ0PjxTUEFOIGNsYXNzPTQ2ODAzMjQxNy0yMTA2MjAwNj48Rk9OVCBmYWNlPUFyaWFsIA0K Y29sb3I9IzAwMDBmZiBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQ2ODAzMjQxNy0yMTA2MjAwNj48Rk9OVCBmYWNl PUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+Skw8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJ ViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDY4MDMyNDE3LTIxMDYyMDA2PjxGT05U IGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDY4MDMyNDE3LTIxMDYy MDA2PjxGT05UIGZhY2U9QXJpYWwgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFO PiZuYnNwOzwvRElWPjxCUj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xp ZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVy IGxhbmc9ZnIgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICA8SFIgdGFiSW5kZXg9LTE+DQogIDxGT05U IGZhY2U9VGFob21hIHNpemU9Mj48Qj5EZSZuYnNwOzo8L0I+IEx1Y3kgWW9uZyANCiAgW21haWx0 bzpsdWN5eW9uZ0BodWF3ZWkuY29tXSA8QlI+PEI+RW52b3nDqSZuYnNwOzo8L0I+IG1lcmNyZWRp IDIxIGp1aW4gMjAwNiANCiAgMTk6MjE8QlI+PEI+w4AmbmJzcDs6PC9CPiBMRSBST1VYIEplYW4t TG91aXMgUkQtQ09SRS1MQU47ICdaaGFuZyBSZW5oYWknOyANCiAgcGNlQGlldGYub3JnPEJSPjxC Pk9iamV0Jm5ic3A7OjwvQj4gUkU6IFtQY2VdIENvbW1lbnRzIG9uIA0KICBkcmFmdC1pZXRmLXBj ZS1kaXNjby1wcm90by1pZ3A8QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAg PERJViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q291 cmllciBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj5IZWxsbyANCiAgSkxMUiw8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1D b3VyaWVyIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNvdXJpZXIg Y29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBibHVlOyBGT05ULUZBTUlMWTogQ291cmllciI+VGhlIGRyYWZ0IGNvdmVycyANCiAgdmFyaW91 cyBkaXNjb3ZlcnkgcmVxdWlyZW1lbnRzIGFzIG1lbnRpb25lZCBpbiBzZWN0aW9uIDQuMi4gR29v ZCANCiAgd29yay48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1Db3VyaWVyIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPk9u Y2UgdGhpbmcgSSB3b3VsZCANCiAgbGlrZSB0byBnZXQgY2xhcmlmaWNhdGlvbiBpcyB0aGF0IHRo ZSBkcmFmdCBmb2N1cyBvbiB0aGUgZGlzY292ZXJ5IGJldHdlZW4gYSANCiAgUENDIGFuZCBhIFBD RSwgYSBQQ0UgYW5kIGRvbWFpbnMgdGhhdCB0aGUgUENFIGhhcyB2aXNpYmlsaXR5IGFuZCBjYW4g Y29tcHV0ZSANCiAgcGF0aHMsIGFuZCBhIFBDRSBhbmQgZG9tYWlucyB0aGF0IHRoZSBQQ0UgY2Fu IGNvbXB1dGUgcGF0aHMgdG93YXJkLiBUaGUgZHJhZnQgDQogIGFsc28gbWVudGlvbnMgdGhhdCBQ Q0UgaW5mb3JtYXRpb24gaXMgZGlzY2xvc2VkIHRvIA0KICBQQ0MuPG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q291cmllciBjb2xv cj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJs dWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Db3VyaWVyIGNvbG9yPWJsdWUg c2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9O VC1GQU1JTFk6IENvdXJpZXIiPkZyb20gdGhlc2Ugc2V0IG9mIA0KICBkaXNjb3ZlcmllcywgSSBj b3VsZCBub3Qgc2VlIGlmIHRoZSBkaXNjb3ZlcmllcyBhbHNvIGluY2x1ZGUgdGhlIGRpc2NvdmVy eSANCiAgYmV0d2VlbiBQQ0VzIGFuZCBpbmZvcm1hdGlvbiBjaGFuZ2VzIGJldHdlZW4gUENFcy4g TWF5YmUgSSBtaXNzIHRoZW0gaW4gDQogIGNvbnRleHQuIENvdWxkIHlvdSBoZWxwIHRvIGNsYXJp Znk/ICZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQ291cmllciI+PG86 cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9Q291cmllciBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj5CZXN0IA0KICBS ZWdhcmRzLDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPUNvdXJpZXIgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQ291cmllciI+THVjeSAN CiAgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9Q291cmllciBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj48bzpwPiZuYnNw OzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8RElWPg0KICA8RElWIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+PEZPTlQgDQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPg0K ICA8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpFPTI+DQogIDwv U1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9OVCBmYWNlPVRh aG9tYSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05U IA0KICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IFRhaG9tYSI+IA0KICA8c3QxOlN0cmVldCB3OnN0PSJvbiI+PHN0MTphZGRyZXNz IHc6c3Q9Im9uIj5MRSBST1VYIEplYW4tTG91aXMgDQogIFJEPC9zdDE6YWRkcmVzcz48L3N0MTpT dHJlZXQ+LUNPUkUtTEFOIFttYWlsdG86amVhbmxvdWlzLmxlcm91eEBvcmFuZ2UtZnQuY29tXSAN CiAgPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U2VudDo8L1NQQU4+PC9C PiBUdWVzZGF5LCBKdW5lIDIwLCAyMDA2IA0KICAxOjU0IEFNPEJSPjxCPjxTUEFOIHN0eWxlPSJG T05ULVdFSUdIVDogYm9sZCI+VG86PC9TUEFOPjwvQj4gWmhhbmcgUmVuaGFpOyANCiAgcGNlQGll dGYub3JnPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDo8L1NQ QU4+PC9CPiBSRTogDQogIFtQY2VdIENvbW1lbnRzIG9uIA0KICBkcmFmdC1pZXRmLXBjZS1kaXNj by1wcm90by1pZ3A8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5IaSANCiAgWmhhbmcsPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0z PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJs dWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+UGxlYXNlIHNlZSANCiAgaW5saW5lLDwvU1BBTj48L0ZP TlQ+PG86cD48L286cD48L1A+DQogIDxCTE9DS1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9u ZTsgUEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBp biA1cHQgMy43NXB0OyBCT1JERVItTEVGVDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6 IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg IDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBjZW50ZXIiIGFsaWduPWNl bnRlcj48Rk9OVCANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiBsYW5n PUZSIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPg0KICAgIDxIUiB0YWJJbmRleD0tMSBhbGlnbj1j ZW50ZXIgd2lkdGg9IjEwMCUiIFNJWkU9Mj4NCiAgICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCI+PEI+PEZPTlQg ZmFjZT1UYWhvbWEgDQogICAgc2l6ZT0yPjxTUEFOIGxhbmc9RlIgDQogICAgc3R5bGU9IkZPTlQt V0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPkRlJm5i c3A7OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgIGZhY2U9VGFob21hIHNpemU9Mj48U1BB TiBsYW5nPUZSIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhv bWEiPiBaaGFuZyBSZW5oYWkgDQogICAgW21haWx0bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29tXSA8 QlI+PEI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5FbnZvecOpJm5ic3A7 OjwvU1BBTj48L0I+IG1hcmRpIDIwIGp1aW4gMjAwNiANCiAgICAwNToyNjxCUj48Qj48U1BBTiBz dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPsOAJm5ic3A7OjwvU1BBTj48L0I+IExFIFJPVVggDQog ICAgSmVhbi1Mb3VpcyBSRC1DT1JFLUxBTjsgcGNlQGlldGYub3JnPEJSPjxCPjxTUEFOIA0KICAg IHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+T2JqZXQmbmJzcDs6PC9TUEFOPjwvQj4gUmU6IFtQ Y2VdIENvbW1lbnRzIG9uIA0KICAgIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncDwvU1BB Tj48L0ZPTlQ+PFNQQU4gDQogICAgbGFuZz1GUj48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogICAg PERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPjxT UEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPkhp LCANCiAgICBKZWFuLUxvdWlzPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAg ICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog5a6L5L2TIj5TZWUgaW5saW5lLCANCiAgICBwbGVh c2UuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICA8QkxPQ0tRVU9URSAN CiAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGlu OyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9U VE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1cHQgMy43NXB0OyBCT1JERVItTEVGVDogYmxhY2sg MS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l Ij4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT3lrovk vZMgc2l6ZT0xPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlM WTog5a6L5L2TIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICAgICAgPG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgIDxESVYgc3R5bGU9ImZvbnQtY29sb3I6 IGJsYWNrIj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iQkFDS0dST1VORDogI2U0 ZTRlNCI+PEI+PEZPTlQgZmFjZT3lrovkvZMgDQogICAgICBzaXplPTE+PFNQQU4gDQogICAgICBz dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTog5a6L 5L2TIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgICAgZmFjZT3lrovkvZMgc2l6 ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IOWui+S9kyI+IDxB IA0KICAgICAgdGl0bGU9amVhbmxvdWlzLmxlcm91eEBvcmFuZ2UtZnQuY29tIA0KICAgICAgaHJl Zj0ibWFpbHRvOmplYW5sb3Vpcy5sZXJvdXhAb3JhbmdlLWZ0LmNvbSI+TEUgUk9VWCBKZWFuLUxv dWlzIA0KICAgICAgUkQtQ09SRS1MQU48L0E+IDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZh Y2U95a6L5L2TIHNpemU9MT48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsg Rk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPlRvOjwvU1BBTj48L0ZPTlQ+PC9C PjxGT05UIA0KICAgICAgZmFjZT3lrovkvZMgc2l6ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6 IDlwdDsgRk9OVC1GQU1JTFk6IOWui+S9kyI+IDxBIA0KICAgICAgdGl0bGU9emhhbmdyZW5oYWlA aHVhd2VpLmNvbSBocmVmPSJtYWlsdG86emhhbmdyZW5oYWlAaHVhd2VpLmNvbSI+WmhhbmcgDQog ICAgICBSZW5oYWk8L0E+IDsgPEEgdGl0bGU9cGNlQGlldGYub3JnIA0KICAgICAgaHJlZj0ibWFp bHRvOnBjZUBpZXRmLm9yZyI+cGNlQGlldGYub3JnPC9BPiANCiAgICAgIDxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxCPjxGT05UIGZhY2U95a6L5L2TIHNpemU9MT48U1BBTiANCiAgICAgIHN0eWxlPSJGT05U LVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPlNlbnQ6 PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgICBmYWNlPeWui+S9kyBzaXplPTE+PFNQQU4g c3R5bGU9IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTog5a6L5L2TIj4gTW9uZGF5LCBKdW5l IA0KICAgICAgMTksIDIwMDYgNDoyMyBQTTxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9E SVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9 5a6L5L2TIHNpemU9MT48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9O VC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiDlrovkvZMiPlN1YmplY3Q6PC9TUEFOPjwvRk9OVD48 L0I+PEZPTlQgDQogICAgICBmYWNlPeWui+S9kyBzaXplPTE+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogOXB0OyBGT05ULUZBTUlMWTog5a6L5L2TIj4gUkU6IFtQY2VdIA0KICAgICAgQ29tbWVudHMg b24gDQogICAgICBkcmFmdC1pZXRmLXBjZS1kaXNjby1wcm90by1pZ3A8bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgIHN0eWxl PSJGT05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9E SVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVl IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVl OyBGT05ULUZBTUlMWTogQXJpYWwiPkhpIA0KICAgICAgWmhhbmc8L1NQQU4+PC9GT05UPjxvOnA+ PC9vOnA+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5i c3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+VGhhbmtz IGZvciB5b3VyIA0KICAgICAgY29tbWVudHM8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0K ICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6 ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+UGxlYXNlIHNlZSANCiAgICAg IGlubGluZSw8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICAgICAgPEJMT0NLUVVPVEUg DQogICAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDog MGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkct Qk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1cHQgMy43NXB0OyBCT1JERVItTEVGVDogYmx1 ZSAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmUiPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICAgIDxESVYgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSJURVhULUFMSUdOOiBjZW50ZXIiIGFsaWduPWNlbnRlcj48Rk9OVCANCiAgICAg ICAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gbGFuZz1GUiBzdHlsZT0iRk9O VC1TSVpFOiAxMnB0Ij4NCiAgICAgICAgPEhSIHRhYkluZGV4PS0xIGFsaWduPWNlbnRlciB3aWR0 aD0iMTAwJSIgU0laRT0yPg0KICAgICAgICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgICA8 UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxCPjxGT05UIGZh Y2U9VGFob21hIA0KICAgICAgICBzaXplPTI+PFNQQU4gbGFuZz1GUiANCiAgICAgICAgc3R5bGU9 IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEi PkRlJm5ic3A7OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgICAgICBmYWNlPVRhaG9tYSBz aXplPTI+PFNQQU4gbGFuZz1GUiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IFRhaG9tYSI+IFpoYW5nIFJlbmhhaSANCiAgICAgICAgW21haWx0bzp6aGFuZ3Jl bmhhaUBodWF3ZWkuY29tXSA8QlI+PEI+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVdFSUdI VDogYm9sZCI+RW52b3nDqSZuYnNwOzo8L1NQQU4+PC9CPiBtYXJkaSAxMyBqdWluIDIwMDYgDQog ICAgICAgIDA5OjA3PEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+w4AmbmJz cDs6PC9TUEFOPjwvQj4gPEEgDQogICAgICAgIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBj ZUBpZXRmLm9yZzwvQT48QlI+PEI+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVdFSUdIVDog Ym9sZCI+T2JqZXQmbmJzcDs6PC9TUEFOPjwvQj4gW1BjZV0gQ29tbWVudHMgb24gDQogICAgICAg IGRyYWZ0LWlldGYtcGNlLWRpc2NvLXByb3RvLWlncDwvU1BBTj48L0ZPTlQ+PFNQQU4gDQogICAg ICAgIGxhbmc9RlI+PG86cD48L286cD48L1NQQU4+PC9QPg0KICAgICAgICA8RElWPg0KICAgICAg ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mz48U1BBTiANCiAg ICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPkhpLCAN CiAgICAgICAgYWxsPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAg PERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAg ICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mz48U1BBTiAN CiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPkkg cmVjZW50bHkgcmVhZCB0aGUgZHJhZnQgDQogICAgICAgIGRyYWZ0LWlldGYtcGNlLWRpc2NvLXBy b3RvLWlncCBhZ2FpbiwgaGVyZSBhcmUgc29tZSANCiAgICAgICAgY29tbWVudHM8L1NQQU4+PC9G T05UPjxGT05UIGZhY2U95a6L5L2TPjxTUEFOIGxhbmc9WkgtQ04gDQogICAgICAgIHN0eWxlPSJG T05ULUZBTUlMWTog5a6L5L2TIj7jgII8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElW Pg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAg IDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6 ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog Q291cmllciI+V2hlbiBJR1AgaXMgdXNlZCZuYnNwO2FzIGEgDQogICAgICAgIFBDRUQgcHJvdG9j b2wsIHRoZSBjYXBhYmlsaXRpZXMgb2YgcGNlIHdpbGwgYmUgYWR2ZXJ0aXNlZCBwZXJpb2RpY2x5 IA0KICAgICAgICBhbG9uZyB3aXRoIG90aGVyIGxzYS9sc3AgaW5mb3JtYXRpb24uIEluIG15IG9w aW5pb24sIHVubGVzcyB0aGUgUENFJ3MgDQogICAgICAgIGNhcGFiaWxpdGllcyBjaGFuZ2UsJm5i c3A7IHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBQQ0MgdG8gcmVjZWl2ZSANCiAgICAgICAgYW5k Jm5ic3A7aGFuZGxlIHRoZSBpbmZvcm1hdGlvbiBhZ2Fpbi4mbmJzcDs8L1NQQU4+PC9GT05UPjxG T05UIA0KICAgICAgICBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij4mbmJzcDs8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICA8RElW Pg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxT UEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5KTExSOiBCdXQgdGhlc2UgDQogICAgICAgIGFyZSBzdGFuZGFyZCBJR1Ag cHJvY2VkdXJlcy4gVGhpcyBpcyB0aGUgc2FtZSBmb3IgbGluayBzdGF0ZXMsIHRoZXkgYXJlIA0K ICAgICAgICByZWZyZXNoZWQgZXZlbiBpZiB0aGVyZSBpcyBub3QgY2hhbmdlLiBCeSB0aGUgd2F5 IHRoZSByZWZyZXNoIGludGVydmFsIA0KICAgICAgICBjYW4gYmUgcXVpdGUgbGFyZ2UgKGUuZy4g MTggaG91cnMgZm9yIA0KICAgICAgICBJUy1JUykuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwv UD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0K ICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEy cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxE SVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9Mz48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAg ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9Q291cmllciBzaXplPTM+PFNQQU4gDQog ICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj4mbmJz cDtGdXJ0aGVybW9yZSwgaWYgbW9zdCANCiAgICAgICAgb2YgdGhlIHJvdXRlcnMgaW4gYSBkb21h aW4gd2lsbCBhbHdheXMgaGF2ZSBubyByZXF1ZXN0IHRvIGEgUENFLCB0aGVyZSANCiAgICAgICAg aXMgYWxzbyBubyBuZWVkIGZvciB0aGVtIHRvIG1haW50YWluIHRoZSANCiAgICAgICAgaW5mb3Jt YXRpb24uJm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6 ZT0yPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwv RElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAg ICAgIDxESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5KTExSOiBJbiB0 aGlzIA0KICAgICAgICBjYXNlIFBDRSBkaXNjb3ZlcnkgaXMgZGVhY3RpdmF0ZWQgb24gdGhlc2Ug cm91dGVycyBhbmQgdGhleSB3aWxsIG5vdCANCiAgICAgICAgcHJvY2VzcyB0aGUgUENFRCBhbmQg UENFUyBUTFZzLi4uPC9TUEFOPjwvRk9OVD48Rk9OVCBjb2xvcj1ibHVlPjxTUEFOIA0KICAgICAg ICBzdHlsZT0iQ09MT1I6IGJsdWUiPjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+ PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCiAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlh bCI+QnV0IEkgZG9uJ3Qga25vdyANCiAgICBpZiBpdCBpcyBwb3NzaWJsZSBmb3IgYSByb3V0ZXIg dG8gYmUgcmUtY29uZmlndXJlZCZuYnNwO2FzIGEgUENDIG9yIGhhdmUgDQogICAgc29tZSZuYnNw O3BhdGggY29tcHV0YXRpb24gcmVxdWVzdCZuYnNwO2FmdGVyJm5ic3A7aXQgcmVjZWl2ZXMgdGhl c2UgVExWcyANCiAgICBhbmQgbm90IHByb2Nlc3NlcyB0aGVtLDwvU1BBTj48L0ZPTlQ+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1ibHVlIA0KICAgIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsmbmJz cDs8L1NQQU4+PC9GT05UPjxGT05UIA0KICAgIGNvbG9yPWJsdWU+PFNQQU4gc3R5bGU9IkNPTE9S OiBibHVlIj48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQog ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9 Ymx1ZSBzaXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgQ09MT1I6IGJs dWUiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPERJVj4N CiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9 Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5Ob3cgaWYgYSByb3V0ZXIgaXMgDQogICAgY29uZmlndXJlZCBhcyBQQ0Mg YXQgc29tZSBwb2ludCBpbiB0aW1lLCB0aGVuJm5ic3A7aXQmbmJzcDtzdGFydHMgDQogICAgcHJv Y2Vzc2luZyZuYnNwO2luZm9ybWF0aW9uIGNhcnJpZWQgaW4gUENFRCBhbmQgUENFUyBUTFZzLi4u KEJlZm9yZSB5b3UgDQogICAgYWN0aXZhdGUgUENFIGRpc2NvdmVyeSBvbiB0aGUgUENDIHRoZSBp bmZvcm1hdGlvbiBpcyBzdG9yZWQgYnV0IG5vdCANCiAgICBwcm9jZXNzZWQpLjwvU1BBTj48L0ZP TlQ+PEZPTlQgY29sb3I9Ymx1ZT48U1BBTiANCiAgICBzdHlsZT0iQ09MT1I6IGJsdWUiPjxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibHVlIHNpemU9Mz48 U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xPUjogYmx1ZSI+Jm5ic3A7PG86 cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBz dHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JE RVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAw aW47IE1BUkdJTjogNXB0IDBpbiA1cHQgMy43NXB0OyBCT1JERVItTEVGVDogYmxhY2sgMS41cHQg c29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAg ICAgIDxCTE9DS1FVT1RFIA0KICAgICAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVG VDogNHB0OyBQQURESU5HLUJPVFRPTTogMGluOyBNQVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsg Qk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1C T1RUT006IG1lZGl1bSBub25lIj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+ DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUNv dXJpZXIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05U LUZBTUlMWTogQ291cmllciI+TXkgY29uY2VybiB0byANCiAgICAgICAgUENFLURFU1QtRE9NQUlO UyBzdWItVExWJm5ic3A7aXMgdGhhdCB3ZSBjYW4ndCBhbnRpY2lwYXRlIGhvdyBtYW55IA0KICAg ICAgICBkZXN0aW5hdGlvbiBkb21haW5zIGEgUENFIGNhbiAmbmJzcDtjb21wdXRhdGUgcGF0aCB0 b3dhcmRzLCZuYnNwO2FzIGEgDQogICAgICAgIHJlc3VsdCx0aGUgbGVuZ3RoIG9mIHNwYWNlIHRh a2VuIGJ5IHRoaXMgY2FwYWxpdHkgaW4gdGhlIG1lc3NhZ2UgY2FuJ3QgDQogICAgICAgIGJlIGNv bnRyb2xsZWQuJm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUg DQogICAgICAgIHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48bzpw PjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q PjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SkxMUjogQWN0dWFs bHkgDQogICAgICAgIHlvdSBoYXZlIHRoZSBzYW1lIHByb2JsZW0gd2l0aCB0aGUgbnVtYmVyIG9m IFRFLWxpbmtzIGFkdmVydGlzZWQgDQogICAgICAgIGJ5Jm5ic3A7YW4gTFNSIG9yIHRoZSBudW1i ZXIgb2YgcmVhY2hlYWJsZSBwcmVmaXhlcyBhZHZlcnRpc2VkIGJ5IGFuIA0KICAgICAgICBBQlIu IDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAg ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0y PjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9O VC1GQU1JTFk6IEFyaWFsIj5PbmUgbWF5IGxpbWl0IA0KICAgICAgICBieSBjb25maWd1cmF0aW9u IHRoZSBudW1iZXIgb2YgZGVzdCBkb21haW5zIA0KICAgICAgICBhZHZlcnRpc2VkLjwvU1BBTj48 L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAg ICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48 U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPkJ1 dCBJIHN0aWxsIGRvdWJ0IHRoYXQgaWYgaXQncyANCiAgICBuZWVkZWQgZm9yIHRoZSBQQ0UgdG8g bWFpbnRhaW4gc3VjaCBpbmZvcm1hdGlvbiBhbmQgaG93IGEgUENFIG9idGFpbnMgdGhlc2UgDQog ICAgaW5mbz88Rk9OVCBjb2xvcj1ibHVlPjxTUEFOIA0KICAgIHN0eWxlPSJDT0xPUjogYmx1ZSI+ Jm5ic3A7PC9TUEFOPjwvRk9OVD48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0K ICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJs dWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QXMgZGlzY3Vzc2VkIGxhdHRlciANCiAgICB0aGlzIGlz IGEgcmVhbGx5IHVzZWZ1bCBmZWF0dXJlIHRoYXQgaGVscHMgUENFIHNlbGVjdGlvbiBhbmQgbG9h ZCANCiAgICBiYWxhbmNpbmcuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAg ICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJs dWUgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVl OyBGT05ULUZBTUlMWTogQXJpYWwiPkluJm5ic3A7dGhlIA0KICAgIGludGVyLWFyZWEgY2FzZSwg dGhlIGNhbiBsZWFybiB0aGlzIGluZm8gYm90aCB2aWEgY29uZmlnIGFuZCB2aWEgdGhlIElHUCAN CiAgICAoZS5nLiBpZiB0aGUgUENFIGlzIGFuIEFCUiwgaXQgY2FuIGVhc2lseSBrbm93IGF0dGFj aGVkIA0KICAgIGFyZWFzKS48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAg IDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1 ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+SW4gdGhlIGludGVyLUFTIA0KICAgIGNhc2UsIHRoZSBQQ0Ug Y2FuIGxlYXJuIHRoaXMgaW5mb3JtYXRpb24gYm90aCZuYnNwO3ZpYSZuYnNwO2NvbmZpZyZuYnNw O2FuZCANCiAgICB2aWEgQkdQLjwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj4m bmJzcDs8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgIDxCTE9DS1FVT1RF IA0KICAgIHN0eWxlPSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAw aW47IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1C T1RUT006IDBpbjsgTUFSR0lOOiA1cHQgMGluIDVwdCAzLjc1cHQ7IEJPUkRFUi1MRUZUOiBibGFj ayAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmUiPg0KICAgICAgPEJMT0NLUVVPVEUgDQogICAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFE RElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1cHQg My43NXB0OyBCT1JERVItTEVGVDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6IDBpbjsg Qk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4g DQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgICAg c3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwv UD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9Q291cmllciBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEy cHQ7IEZPTlQtRkFNSUxZOiBDb3VyaWVyIj4mbmJzcDtTbyBJIHRoaW5rIGlmIHRoZSANCiAgICAg ICAgUENDIHNlbmQgYSByZXF1ZXN0IHRvIGEgUENFIHdoaWNoIGNhbid0IGNvbXB1dGUgdGhlIHBh dGggZm9yIHRoZSByZWFzb24gDQogICAgICAgIG9mIHRoZSBkZXN0aW5hdGlvbiBkb21haW4sIHRo ZSBQQ0UgY2FuIHRlbGwgdGhlIFBDQyBpbiB0aGUgUENyZXAgDQogICAgICAgIG1lc3NhZ2UmbmJz cDt0aGUgcmlnaHQgUENFLiZuYnNwOzwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCANCiAg ICAgICAgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOzwvU1BBTj48L0ZP TlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAg ICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPkpMTFI6 IEJ1dCBob3cgDQogICAgICAgIHRoZSBQQ0Ugd2lsbCBoYXZlIHRoZSBpbmZvcm1hdGlvbj88L1NQ QU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQ QU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogQ291cmllciI+Jm5ic3A7T25lIGFkZGl0aW9u YWwgDQogICAgICAgIHF1ZXNpb246IGlzIGl0IHN1aXRhYmxlIGZvciB0aGUgUENFIHRvIGhhdmUg c3VjaCBhYmlsaXR5IHRvIGtub3cgZXhhY3RseSANCiAgICAgICAgdGhlIGRlc3RpbmF0aW9uIGRv bWFpbiBpdCBjYW4gY29tcHV0ZSB0b3dhcmRzPzwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogICAgICAg IGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOzwvU1BB Tj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BB TiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwi PkpMTFI6IFRoaXMgaXMgDQogICAgICAgIGFjdHVhbGx5Jm5ic3A7cmVxdWlyZWQuIEZvciBpbnN0 YW5jZSBpbiBhbiBpbnRlci1BUyBjYXNlLCBhbiBBUyBtYXkgYmUgDQogICAgICAgIGNvbm5lY3Rl ZCB0byBtdWx0aXBsZSBBU3MsIGFuZCZuYnNwO3RoZXJlIG1heSBiZSBtdWx0aXBsZSBQQ0VzIGlu IHRoaXMgDQogICAgICAgIEFTIChlLmcuIEFTQlJzKSwgZWFjaCByZXNwb25zaWJsZSBmb3IgY29t cHV0aW5nIHBhdGggdG93YXJkcyBhIGdpdmVuIA0KICAgICAgICBuZWlnaGJvcmQgQVMuPC9TUEFO PjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0K ICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ SGVyZSB5b3Ugc2FpZCB0aGUgbmVpZ2hib3JpbmcgDQogICAgQVMsIGJ1dCBub3QgdGhlIGRlc3Rp bmF0aW9uIEFTLjxGT05UIGNvbG9yPWJsdWU+PFNQQU4gDQogICAgc3R5bGU9IkNPTE9SOiBibHVl Ij4mbmJzcDs8L1NQQU4+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+ DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7 PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0K ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJp YWwiPkl0IHdhcyBhbiBleGFtcGxlIA0KICAgIHdoZXJlIHRoZSBkZXN0aW5hdGlvbiBpcyBsb2Nh dGVkIGluIHRoZSBuZWlnaGJvcmluZyBBUy4uLiBCdXQgdGhlIHNhbWUgDQogICAgYXBwbGllcyB3 aGVuIHRoZSBkZXN0aW5hdGlvbiBpcyBsb2NhdGVkIA0KICAgIGZhcnRoZXIuPC9TUEFOPjwvRk9O VD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElW Pg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+VGhhbmtzIA0KICAgIDwvU1BBTj48L0ZPTlQ+PG86 cD48L286cD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAg ICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJs dWUgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVl OyBGT05ULUZBTUlMWTogQXJpYWwiPkpMPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJ Vj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElORy1M RUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1cHQgMy43NXB0 OyBCT1JERVItTEVGVDogYmxhY2sgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lIj4NCiAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAgc3R5bGU9 IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRPTTogMGluOyBN QVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7 IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAgICAgICAg PERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAg ICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mz48U1BBTiAN CiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPlNv bWUgZnVuY3Rpb25zIHNwZWNpZmllZCANCiAgICAgICAgaW4gdGhlIFBBVEgtQ0FNUC1DQVAgc3Vi LVRMViBhcmUgYWxzbyZuYnNwO2RlZmluZWQmbmJzcDtpbiB0aGUgDQogICAgICAgIFBDRVAsJm5i c3A7IGEgY2xlYXIgZGl2aXNpb24gc2hvdWxkIGJlIG1hZGUuJm5ic3A7PC9TUEFOPjwvRk9OVD48 Rk9OVCANCiAgICAgICAgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAg ICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlh bCI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgPERJ Vj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAg ICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7SkxMUjogDQogICAgICAgICZuYnNw O0FjdHVhbGx5LCBhdCB0aGUgdGltZSBiZWluZyB0aGUgUENFUCBzcGVjIGRvZXMgbm90IGRlZmlu ZSBhbnkgDQogICAgICAgIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24uPC9TUEFOPjwvRk9OVD48bzpw PjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPklu IGN1cnJlbnQgUENFUCANCiAgICAgICAgc3BlYywgd2Ugb25seSBtZW50aW9uIHRoYXQgZGV0YWls ZWQgY2FwYWJpbGl0ZXMgY291bGQgYmUgY2FycmllZCBpbiANCiAgICAgICAgb3B0aW9uYWwgc3Vi LVRMVnMgb2YgdGhlIE9wZW4gb2JqZWN0IChjYXJyaWVkIGluIHRoZSBPcGVuIA0KICAgICAgICBt ZXNzYWdlKS48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICA8RElW Pg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVl IHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJs dWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QnV0IHlvdSBhcmUgDQogICAgICAgIHJpZ2h0IHN1Y2gg Y2FwYWJpbGl0eSBpbmZvcm1hdGlvbiBtYXkgYmUgY2FycmllZCBpbiANCiAgICAgICAgUENFUC48 L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAg ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+ PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAg ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFy aWFsIj5UaGUgDQogICAgICAgIGlkZWEmbmJzcDt3b3VsZCBiZSZuYnNwO3RvIGNhcnJ5Jm5ic3A7 c2ltcGxlIGNhcGFiaWxpdGllcyZuYnNwO2luIHRoZSANCiAgICAgICAgSUdQIGFuZCZuYnNwO21v cmUgY29tcGxleCBjYXBhYmlsaXRpZXMgaW4gDQogICAgICAgIFBDRVAuPC9TUEFOPjwvRk9OVD48 bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QW55d2F5IEkg ZG9uJ3QgDQogICAgICAgIHJlYWxseSBzZWUgYW55IGlzc3VlIGlmIHdlIGRlZmluZSB0d28gd2F5 cyB0byZuYnNwO2NhcnJ5Jm5ic3A7c29tZSANCiAgICAgICAgcGllY2VzIG9mIGluZm9ybWF0aW9u OjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAg ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0y PjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9O VC1GQU1JTFk6IEFyaWFsIj4tSUdQLWJhc2VkIA0KICAgICAgICBjYXBhYmlsaXR5IGRpc2NvdmVy eSBpcyB1c2VmdWwgZm9yIFBDQ3MgdGhhdCBkb24ndCBoYXZlIGEgUENFUCBzZXNzaW9uIA0KICAg ICAgICB3aXRoIHRoZSBQQ0UuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAg ICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPi1QQ0VQLWJhc2VkIA0KICAgICAgICBj YXBhYmlsaXR5IGRpc2NvdmVyeSBpcyB1c2VmdWwgd2hlbiBJR1AgYmFzZWQgZGlzY292ZXJ5IGlz IG5vdCANCiAgICAgICAgYWN0aXZhdGVkLiZuYnNwOzwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48 L1A+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICA8RElWPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCiAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPlRoaXMgc291bmRzIGZp bmUgdG8gDQogICAgbWUuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgICA8 RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+UmVnYXJkcyw8L1NQQU4+PC9GT05UPjxvOnA+ PC9vOnA+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBBcmlhbCI+WmhhbmcgDQogICAgPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwv UD48L0RJVj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFE RElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1cHQg My43NXB0OyBCT1JERVItTEVGVDogYmxhY2sgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAg c3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9S REVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRPTTog MGluOyBNQVJHSU46IDVwdCAwaW4gNXB0IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQg c29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAg ICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICA8RElW Pg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxT UEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5UaGFua3MgZm9yIA0KICAgICAgICB0aGVzZSBjb21tZW50cyw8L1NQQU4+ PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4g DQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5S ZWdhcmRzLDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+ DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i IHNpemU9Mz48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86 cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQ QU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZB TUlMWTogQXJpYWwiPkpMJm5ic3A7PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4N CiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICA8 RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAg ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mz48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0K ICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1Db3VyaWVyIHNpemU9Mz48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQt U0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IENvdXJpZXIiPkNoZWVycyw8L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPjwvRElWPg0KICAgICAgICA8RElWPg0KICAgICAgICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogICAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+PC9ESVY+DQogICAgICAgIDxESVY+DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUNvdXJpZXIgc2l6ZT0zPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBGT05ULUZBTUlMWTogQ291cmllciI+WmhhbmcgDQogICAgICAgIFJlbmhhaTwvU1BBTj48 L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JM T0NLUVVPVEU+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C69558.9478BE28-- --===============0564314370== 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 --===============0564314370==-- From pce-bounces@lists.ietf.org Fri Jun 23 10:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftmp3-0001AM-3g; Fri, 23 Jun 2006 10:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmOA-0006c2-CC for pce@ietf.org; Fri, 23 Jun 2006 10:12:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtmO8-000067-1C for pce@ietf.org; Fri, 23 Jun 2006 10:12:02 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Jun 2006 07:11:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,169,1149490800"; d="scan'208,217"; a="30330377:sNHT56170152" 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 k5NEBwYL024311; Fri, 23 Jun 2006 10:11:58 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 10:11:58 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 10:11:55 -0400 In-Reply-To: <02e001c68cae$d1f154d0$c2849ed9@your029b8cecfe> References: <02e001c68cae$d1f154d0$c2849ed9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Message-Id: <81769A42-39BD-499A-9501-BA3EA61F000A@cisco.com> From: JP Vasseur Date: Fri, 23 Jun 2006 10:11:53 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 23 Jun 2006 14:11:55.0671 (UTC) FILETIME=[FBB06A70:01C696CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 908e7c498db66256d5e0db08ac2f5506 X-Mailman-Approved-At: Fri, 23 Jun 2006 10:39:47 -0400 Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com Subject: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0717610250==" Errors-To: pce-bounces@lists.ietf.org --===============0717610250== Content-Type: multipart/alternative; boundary=Apple-Mail-68-966022195 --Apple-Mail-68-966022195 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Many Thanks Adrian for the comments. We incorporated the vast majority of them in the new revision (just posted). See below for the comments requesting some clarification. On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > Hi, > > Thanks for keeping these ideas alive. > > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any > issues with > the basic process. > > Thanks, > Adrian > > == > Is this I-D likely to be Informational or Standards Track? From > Appendix A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > == Status has been updated (Informational) but let's discuss this later on. FYI, it does not appear on the front page when using the xml2rfc editor (which by the way is excellent), thus the appendix addition. > It would be nice if the Abstract contained a pithy summary of brpc > and/or > gave the motivation for the draft. For example, what is the method > trying to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? Agree. Here is the new Abstract: "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 (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) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths, using a backward recursive path computation technique while fully preserving confidentiality requirements across domains. " > == > I'm assuming that section 1 is for short term information only and > will be > deleted (in the next revision?) > == Indeed, just to provide a bit of history for the ones who have been following inter-domain path computation for a while. > == > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would > argue that > reachability information (i.e. external routes) constitutes > topology and > resource information. > OK fine > == > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed > that, at > the domain boundary LSRs, there will exist some sort of local > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? > It should actually read "pre-determined". Actually the best thing to do here is to remove "off-line" > == > Section 5 > No assumption is made on the actual path computation algorithm in > use > by the PCE (it can be any variant of CSPF, algorithm based on > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! Well I'd suggest to keep it as is since the point is to differentiate the path computation procedure from the algorithm to compute each intra-domain path segment. Furthermore, we'd like to highlight the fact that the BRPC procedure does not mandate for each PCE to use CSPF, could be other algorithm. > == > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous It is actually a double tautology ;-) (fixed). > == > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." > == > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to > parse and > to my mind the definition is arse about tit. I think you could > usefully add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! This is an abstract form of representation but see below, > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P tree). > == > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) > out into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where, > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. This only works for unidirectional LSPs: indeed, the exit boundary node can flood TE-related data in its LSA/LSP for the link exit-BN (i,k)->entry-BN(i+1,k') even in the absence of any IGP running on the link but how would a node in domain (i) get the TE-related data for the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on unidirectional link. Are we in sync ? > == > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..." > is a > nascent Applicability Statement. I suggest moving this to another > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms This was (and is) planned for future revision. Note that ECMP and diversity are discussed already but we're planning the flesh out these sections in further revision. > == > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is > supposed to > respond to the path computation request saying that it does not > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. Good catch, typo: it should read "a PCErr message is returned to the upstream". The plan is to define a capability bit (IGP) in a further revision. > == > Section 8 > Metric normalisation is a great potential solution, but how does it > fit with > AS topology confidentiality? What is the solution to providing > discretion > about what TE connectivity is available within an AS, and operating > brpc? Metric normalization is handled locally by the PCE and does not impact the BRPC procedure per-say. As far as confidentiality is concerned, this only requires for the SPs to exchange metric mapping information (nothing related to the network topology or resources); for example SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 A simple metric normalization can then be performed on the PCE thanks to simple cost mapping tables. > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you > say that > "In the case where a domain has more than one BR-en or more than > one BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of > course) is not > the case - per-domain optimisation will always improve or leave the > same > end-to-end optimality (in the case where new resources are made > available > this is obvious; in the case of a network failure, *any* path is > better than > no path!) > And, lastly, the text about re-optimisation belongs in the next > section, not > in this section. > Yes I wanted to leave that text to keep track of who would read the ID, expecting reaction ;-)) Per-domain reoptimization would always improve the current path *but* in case of stitched LSPs, TE LSP segments are computed by the stitching point; thus in case of failure, they could end up following a non optimal path whereas in the case of contiguous LSP, the BRPC procedure would be called again thus leading to the optimal path again. The point that I was trying to make is "if you have a stitched LSP and rely on BRPC when first signaled in an attempt to get an optimal path, you need to consider the interaction between the local reopt mode and BRPC if the goal is to preserve an optimal path at any given time". Anyway, we're on the same page and I agree and the text should be reworded according to your proposal to avoid any misunderstanding. > == > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use > this > technique in conjunction with path cookies, which is fine. But, are > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. Indeed. > Maybe the PCE(n+1) should carefully monitor and limit > (statistically and by > policy) brpc requests so that excessive information is not divulged? Since one of objectives for using the BRPC procedure is to compute an optimal path, we need to know at least the BN (Boundary Nodes) and the cost. > == > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at > transit PCEs? > What are the implications of reporting multiple VSPT branches in > PCEP to the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of > using brpc? Absolutely ! I put a placeholder for a further revision. Fully supportive of adding such section. Many Thanks for your comments ! JP. > etc. > == > > > > > > I think Jean-Louis' email address needs updating > > > == > The document would benefit from a little care in the formatting, > and you > could usefully re-read it for missing words, etc. > == --Apple-Mail-68-966022195 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Many Thanks Adrian for the = comments.

We = incorporated the vast majority of them in the new revision (just = posted).

See = below for the comments requesting some = clarification.

On Jun 10, 2006, at 8:49 AM, = Adrian Farrel wrote:

Hi,

Thanks for keeping these ideas = alive.

Here are some picky thoughts that you may want to = include in the next
revision to make it more = robust as a document. I don't have any issues with
the basic process.

Adrian

Is this I-D likely to be = Informational or Standards Track? =46rom Appendix A,
this looks like Standards Track. Can you remove = Appendix A and put the
status in the usual place = in the header?
=3D=3D

Status has been updated = (Informational) but let's discuss this later on. FYI, it does not appear = on the front page when using the xml2rfc editor (which by the way is = excellent), thus the appendix addition.=A0

It would be nice if the Abstract = contained a pithy summary of brpc and/or
gave the = motivation for the draft. For example, what is the method trying = to
achieve that isn't achievable by other methods? = Or, what is the fundamental
element of = brpc that is not in other methods?

Agree. Here is the new = Abstract:
"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 (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) = has been identified as a key requirement . This document specifies a = procedure relying on the use of multiple Path Computation Elements = (PCEs) in order to compute such inter-domain shortest constraint paths, = using a backward recursive path computation technique while fully = preserving confidentiality requirements across domains. = "


=3D=3D
I'm assuming = that section 1 is for short term information only and will be
deleted (in the next revision?)
=3D=3D


=3D=3D
Section = 4
=A0 = - No topology or resource information is distributed between = domains
=A0 (as mandated per [RFC4105] = and [RFC4216]), which is critical to
=A0 preserve IGP/BGP scalability = and confidentiality in the case of TE
=A0 LSPs spanning multiple = domains.
You should clarify what you are = saying here, because many would argue that
resource information.


OK = fine=A0

=3D=3D
Section = 4
=A0 = - While certain constraints like bandwidth can be used = across
=A0 different domains, certain = other TE constraints like resource
=A0 affinity, color, metric, etc. = as listed in [RFC2702] could be
=A0 translated at domain = boundaries.=A0 If required, = it is assumed that, at
=A0 the domain boundary LSRs, = there will exist some sort of local mapping
=A0 based on offline policy = agreement, in order to translate such
=A0 constraints across domain = boundaries during the inter-PCE
=A0 communication = process.
Why does the policy agreement = need to be offline?
It should actually read = "pre-determined". Actually the best thing to do here is to remove = "off-line"

Section 5
=A0 No = assumption is made on the actual path computation algorithm in = use
=A0 by the PCE (it can be any = variant of CSPF, algorithm based on linear-
=A0 programming to solve = multi-constraints optimization problems and so
=A0 = on).
Suggest that you delete the text = in parenthesis because it is making
suggestions = that border on assumptions!

Well I'd suggest to keep it = as is since the point is to differentiate the path computation procedure = from the algorithm to compute each intra-domain path segment. = Furthermore, we'd like to highlight the fact that the BRPC procedure = does not mandate for each PCE to use CSPF, could be other = algorithm.

Section 5.1 and = throughout
"BRPC path computation" seems to = be tautologous

It is actually a double = tautology ;-) (fixed).=A0

=3D=3D
Section = 5.1
I like the simplicity of section = 5.1, but I think you need to point out that
if the = sequence of domains is known a priori (can you determine it a
priori?) then the path computed might not be = 'optimal' in the usual sense of
the word, but = that this is OK because the ordered list of domains
constitutes an additional constraint on the = computation so the resultant
path *is* = optimal within the constraints applied.

Can't agree more. Good = suggestion, thanks.

Updated text: "The = PCE-based BRPC procedure applies to the computation of an optimal = constrained inter-domain TE LSP. The sequence of domains to be traversed = can either be determined a priori or during the path computation = procedure. The BRPC procedure guarantees to compute the optimal path = across a specific set of traversed domains (which=A0constitutes = an=A0additional constraint). In the case of an arbitrary set of meshed = domains, the BRPC procedure can be used to compute the optimal path = across each domain set in order to get to optimal constrained path = between the source and the destination of the TE = LSP."

=3D=3D
Section 5.2


So the VSPT is still a tree, but it is an MP2P tree, = not a P2MP tree as
described.
I suspect that this is just a textual descriptive = issue rather than anything
broken in the = process.


I clarified the text to = avoid any ambiguity (VSPT defined as a MP2P tree).

=3D=3D
Section = 5.2
I suggest that you pull the note = (Note: in term of computation...) out into
a = separate section. It doesn't belong in the middle of section = 5.2.
You will probably want to = re-write the text as well since the unidirectional
limit is not necessary. Also to explain 'flood' - = flood to where, and how,
and by whom? = And you will want to add to pieces of information:
- the link to the I-D that defines how to do = this
- a description of what happens = if this process is not used.

This only works for = unidirectional LSPs: indeed, the exit boundary node can flood TE-related = data in its LSA/LSP for the link exit-BN(i,k)->entry-BN(i+1,k') even = in the absence of any IGP running on the link but how would a node in = domain (i) get the TE-related data for the link = entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on = unidirectional link. Are we in sync ?

=3D=3D
Section 5.2
The paragraph = that begins "BRPC guarantees to find the optimal..." is a
nascent Applicability Statement. I suggest moving = this to another Section
and = significantly beefing it up. You need to describe more fully:
- how ECMP works (the PCC has to request the return = of more than one path)
- how diversity works (i.e. = section 9 fits in here)
- how some = freedom of selection of domains can be offered
- how to mix the method with other = mechanisms

This was (and is) planned = for future revision. Note that ECMP and diversity are discussed already = but we're planning the flesh out these sections in further = revision.

=3D=3D
Section 7
=A0 If the BRPC procedure cannot = be completed because a PCE along the
=A0 domain path does not support = the procedure, a PCErr message is
=A0 returned by the upstream PCE = with a Error-Type "BRPC procedure
=A0 completion failure".=A0 The PCErr message MUST be = relayed to the
=A0 requesting PCC.
Not clear to me whether PCE(n) is supposed to know = that PCE(n+1) does not
support brpc, presumably = through capabilities
respond to the path computation = request saying that it does not support
bit-V of = the RP object. If the latter, presumably the PCErr comes from
PCE(n+1) and not from PCE(n) as = documented.

Good catch, typo: it should = read "a PCErr message is returned to the upstream".
The plan = is to define a capability bit (IGP) in a further = revision.

Section 8
Metric normalisation is a great potential solution, = but how does it fit with
AS topology = confidentiality? What is the solution to providing discretion
about what TE connectivity is available within an = AS, and operating brpc?

Metric normalization is = handled locally by the PCE and does not impact the BRPC procedure = per-say. As far as confidentiality is concerned, this only requires for = the SPs to exchange metric mapping information (nothing related to the = network topology or resources); for example
SP 1 = Links Cost =3D F (link_bandwidth) with F (OC192)=3D1
SP 2 = Links Cost =3D F (link_bandwidth) with F (OC192)=3D10

A simple metric = normalization can then be performed on the PCE thanks to simple cost = mapping tables.

Section 10
Some of this = text has been seen before in this I-D
Why do = you single out LSP stitching as possibly breaking end-to-end
optimality. There is functionally no difference = between stitching and
nesting in this = respect.
But further, your statement = about stitching is pejorative! If you say that
"In the case where a domain has more than one BR-en = or more than one BR-ex,
optimality = after some network change within the domain can only be
guaranteed by re-executing the full brpc = computation" then I would agree
with you. But = as phrased, it implies that making a per-domain
re-optimisation could make the path *less* optimal. = This (of course) is not
the case - = per-domain optimisation will always improve or leave the same
end-to-end optimality (in the case where new = resources are made available
this is = obvious; in the case of a network failure, *any* path is better = than
no path!)
And, lastly, the text about re-optimisation belongs = in the next section, not
in this = section.


Yes I wanted to leave that = text to keep track of who would read the ID, expecting reaction ;-)) = Per-domain reoptimization would always improve the current path *but* in = case of stitched LSPs, TE LSP segments are computed by the stitching = point; thus in case of failure, they could end up following a non = optimal path whereas in the case of contiguous LSP, the BRPC procedure = would be called again thus leading to the optimal path again. The point = that I was trying to make is "if you have a stitched LSP and rely on = BRPC when first signaled in an attempt to get an optimal path, you need = to consider the interaction between the local reopt mode and BRPC if the = goal is to preserve an optimal path at any given time". Anyway, we're on = the same page and I agree and the text should be reworded according to = your proposal to avoid any misunderstanding.=A0

=3D=3D
Section 13
I would like = you to discuss the issues of confidentiality of topology
information at greater length. It seems that you = would possibly use this
technique in = conjunction with path cookies, which is fine. But, are there
two things you cannot escape from?
- indicating which BR-en provides best = connectivity
- indicating the metric for = multiple BR-ens
Maybe there are some things that = can be done here based on policy, including
not = reporting all of the BR-ens, ranking rather than giving = absolute
metrics, etc. But these would = compromise optimality.

Indeed.

Maybe the PCE(n+1) should = carefully monitor and limit (statistically and by
policy) brpc requests so that excessive information = is not divulged?

Since one of objectives for = using the BRPC procedure is to compute an optimal path, we need to know = at least the BN (Boundary Nodes) and the cost.=A0

=3D=3D
I wouldn't mind seeing a Management Considerations = section.
Do we need to be able to examine = the pruned pieces of VSPT at transit PCEs?
What are = the implications of reporting multiple VSPT branches in PCEP to = the
MIB modules?
Is brpc support something that needs to be = configured: per PCE?; per
What are the implications on = existing protocols (IGPs? PCEP?) of using = brpc?

Absolutely ! I put a = placeholder for a further revision.

Fully supportive of adding = such section.

Many Thanks for your = comments !

JP.

etc.
=3D=3D





I think Jean-Louis' email = address needs updating

=3D=3D
The document = would benefit from a little care in the formatting, and you
could usefully re-read it for missing words, = etc.
=3D=3D
=

= --Apple-Mail-68-966022195-- --===============0717610250== 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 --===============0717610250==-- From pce-bounces@lists.ietf.org Fri Jun 23 15:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrgN-0004zP-Tn; Fri, 23 Jun 2006 15:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfI-0002MA-6p; Fri, 23 Jun 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrfG-0004uo-92; Fri, 23 Jun 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5NJo1WR012279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtrfF-0003Aj-To; Fri, 23 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-02.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 : Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-pcep-02.txt Pages : 62 Date : 2006-6-23 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-02.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-pcep-02.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-pcep-02.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-6-23125401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23125401.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Jun 23 16:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsaV-0000hS-Fs; Fri, 23 Jun 2006 16:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsaT-0000hN-IW for pce@ietf.org; Fri, 23 Jun 2006 16:49:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsaS-00035T-Mr for pce@ietf.org; Fri, 23 Jun 2006 16:49:09 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 23 Jun 2006 13:49:08 -0700 X-IronPort-AV: i="4.06,170,1149490800"; d="scan'208,217"; a="1831643935:sNHT68240236" 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 k5NKn8QU026294; Fri, 23 Jun 2006 13:49:08 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5NKn6cL003116; Fri, 23 Jun 2006 13:49:06 -0700 (PDT) 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.211); Fri, 23 Jun 2006 16:49:06 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Jun 2006 16:49:02 -0400 Mime-Version: 1.0 (Apple Message framework v750) References: Message-Id: From: JP Vasseur Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-pcep-02.txt Date: Fri, 23 Jun 2006 16:49:00 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 23 Jun 2006 20:49:02.0533 (UTC) FILETIME=[759B0750:01C69706] DKIM-Signature: a=rsa-sha1; q=dns; l=23330; t=1151095748; x=1151959748; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Fwd=3A=20[Pce]=20I-D=20ACTION=3Adraft-ietf-pce-pcep-02.txt=20; X=v=3Dcisco.com=3B=20h=3DFutNk/RV7LsAbb1U1Rk2g28/MmY=3D; b=mnHf/W3Y9l+e818IMW073iYh7ZmvbaPMIILqKGrC0ywTmZTAwysB8HgECMxQw1W76W3LH7ba R5phetOL1m+y22DyQEnJggzMZUqlRiJqCB1n0WmQJEFoccGwQYUlltpw; Authentication-Results: sj-dkim-5.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 28 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef Cc: Arthi Ayyangar 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="===============0059212800==" Errors-To: pce-bounces@lists.ietf.org --===============0059212800== Content-Type: multipart/alternative; boundary=Apple-Mail-1-989849112 --Apple-Mail-1-989849112 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, Here are the main changes that we made in the new revision of PCEP (rev -02): 1) We added an FSM 2) As discussed in Vancouver, we added a section listing the set of requirements stated in draft-ietf-pce-comm-protocol-reqs-06.txt to which the current revision is not yet compliant. 3) We added a new bit to the RP object: F bit: when set, the requesting PCC requires the computation of a new path for a TE LSP that has failed in which case the path of the existing TE LSP MUST be provided in the PCReq (except of 0-bandwidth TE LSP) message by means of an RRO object. This is to avoid double bandwidth booking should the TED not be yet updated or the corresponding resources not be yet released. Note that this was listed as a MUST requirement in the generic requirement ID: Allow indicating if computation is for LSP restoration (support inclusion of previously computed path & failed element) Of course, comments are very welcome. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 23, 2006 3:50:01 PM EDT > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working > Group of the IETF. > > Title : Path Computation Element (PCE) communication Protocol > (PCEP) - Version 1 > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-pce-pcep-02.txt > Pages : 62 > Date : 2006-6-23 > > This document specifies the Path Computation Element communication > Protocol (PCEP) for communications between a Path Computation Client > (PCC) and a Path Computation Element (PCE), or between two PCEs. > Such interactions include path computation requests and path > computation replies as well as notifications of specific states > related to the use of a PCE in the context of MPLS and GMPLS Traffic > Engineering. The PCEP protocol is designed to be flexible and > extensible so as to easily allow for the addition of further messages > and objects, should further requirements be expressed in the future. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-02.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-pcep-02.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-pcep-02.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-6-23125401.I-D@ietf.org> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-1-989849112 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dear WG,

Here are the main changes that = we made in the new revision of PCEP (rev -02):

1) We added an = FSM
2) As discussed in Vancouver, we added a section listing = the set of requirements stated in = draft-ietf-pce-comm-protocol-reqs-06.txt to which the current revision = is not yet compliant.
3) We added a new bit to the = RP object:
F bit: when set, the requesting PCC requires the = computation of a new path for a TE LSP that has failed in which case the = path of the existing TE LSP MUST be provided in the PCReq (except of = 0-bandwidth TE LSP) message by means of an RRO object. This is to avoid = double bandwidth booking should the TED not be yet updated or the = corresponding resources not be yet released.

Note that this was listed as a = MUST requirement in the generic requirement ID:

Allow indicating if = computation is for LSP restoration (support inclusion of previously = computed path & failed element)

Of course, comments are very = welcome.

Thanks.

JP.

= --Apple-Mail-1-989849112-- --===============0059212800== 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 --===============0059212800==-- From pce-bounces@lists.ietf.org Sun Jun 25 14:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuZ2D-0003R7-JO; Sun, 25 Jun 2006 14:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuZ2C-0003Qz-AG for pce@ietf.org; Sun, 25 Jun 2006 14:08:36 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuZ2B-0004oR-CI for pce@ietf.org; Sun, 25 Jun 2006 14:08:36 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5PI8ONp010367; Sun, 25 Jun 2006 20:08:24 +0200 In-Reply-To: <81769A42-39BD-499A-9501-BA3EA61F000A@cisco.com> To: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 25 Jun 2006 20:08:29 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/25/2006 20:08:24, Serialize complete at 06/25/2006 20:08:24 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: 919b3965bd46f7460d234f848680b238 Cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org the following comment was also discussed during last meeting "== Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." => in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure (only inter-domain link selection would be required) - now adrian mentions that pre- determination becomes a new constraint - well actually this is not a constraint for the TE LSP itself but a restriction on the domain set known to be (a-priori) supportive of the method such as to make the method not returning an error message hence sentence "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." should as far as i understand the method fulfill the following a) this method provides a result iff all domains traversed by the request support the proposed method b) this method provides an "optimal" result iff b1) all possible sequences of domains have been traversed (starting from the root) and are supportive of that method - as there might be an optimal path through a domain not supporting this method - b2) there is no discontinuity in the availability of the inter-AS link information on each PCE performing a given selection - indeed a domain might be supportive of the method without supporting inter-AS link flooding b3) at each step there is no PCE that has partial visibility of a given domain b4) during the selection process no network conditions changes (that would make the returned result void) JP Vasseur 23/06/2006 16:11 To: "Adrian Farrel" cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com Subject: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Many Thanks Adrian for the comments. We incorporated the vast majority of them in the new revision (just posted). See below for the comments requesting some clarification. On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: Hi, Thanks for keeping these ideas alive. Here are some picky thoughts that you may want to include in the next revision to make it more robust as a document. I don't have any issues with the basic process. Thanks, Adrian == Is this I-D likely to be Informational or Standards Track? From Appendix A, this looks like Standards Track. Can you remove Appendix A and put the status in the usual place in the header? == Status has been updated (Informational) but let's discuss this later on. FYI, it does not appear on the front page when using the xml2rfc editor (which by the way is excellent), thus the appendix addition. It would be nice if the Abstract contained a pithy summary of brpc and/or gave the motivation for the draft. For example, what is the method trying to achieve that isn't achievable by other methods? Or, what is the fundamental element of brpc that is not in other methods? Agree. Here is the new Abstract: "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 (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) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths, using a backward recursive path computation technique while fully preserving confidentiality requirements across domains. " == I'm assuming that section 1 is for short term information only and will be deleted (in the next revision?) == Indeed, just to provide a bit of history for the ones who have been following inter-domain path computation for a while. == Section 4 - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple domains. You should clarify what you are saying here, because many would argue that reachability information (i.e. external routes) constitutes topology and resource information. OK fine == Section 4 - While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. Why does the policy agreement need to be offline? It should actually read "pre-determined". Actually the best thing to do here is to remove "off-line" == Section 5 No assumption is made on the actual path computation algorithm in use by the PCE (it can be any variant of CSPF, algorithm based on linear- programming to solve multi-constraints optimization problems and so on). Suggest that you delete the text in parenthesis because it is making suggestions that border on assumptions! Well I'd suggest to keep it as is since the point is to differentiate the path computation procedure from the algorithm to compute each intra-domain path segment. Furthermore, we'd like to highlight the fact that the BRPC procedure does not mandate for each PCE to use CSPF, could be other algorithm. == Section 5.1 and throughout "BRPC path computation" seems to be tautologous It is actually a double tautology ;-) (fixed). == Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." == Section 5.2 The introduction of the term Virtual Shortest Path Tree is hard to parse and to my mind the definition is arse about tit. I think you could usefully add some textual definition of what the VSPT is trying to achieve, before presenting it in pictorial or abstract form. Even more important (I think) is the fact that the tree as presented "represents the shortest path between the destination and BR-en(j,i)..." Frankly, we are building directional paths in exactly the oposite direction! This is an abstract form of representation but see below, So the VSPT is still a tree, but it is an MP2P tree, not a P2MP tree as described. I suspect that this is just a textual descriptive issue rather than anything broken in the process. I clarified the text to avoid any ambiguity (VSPT defined as a MP2P tree). == Section 5.2 I suggest that you pull the note (Note: in term of computation...) out into a separate section. It doesn't belong in the middle of section 5.2. You will probably want to re-write the text as well since the unidirectional limit is not necessary. Also to explain 'flood' - flood to where, and how, and by whom? And you will want to add to pieces of information: - the link to the I-D that defines how to do this - a description of what happens if this process is not used. This only works for unidirectional LSPs: indeed, the exit boundary node can flood TE-related data in its LSA/LSP for the link exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP running on the link but how would a node in domain (i) get the TE-related data for the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on unidirectional link. Are we in sync ? == Section 5.2 The paragraph that begins "BRPC guarantees to find the optimal..." is a nascent Applicability Statement. I suggest moving this to another Section and significantly beefing it up. You need to describe more fully: - how ECMP works (the PCC has to request the return of more than one path) - how diversity works (i.e. section 9 fits in here) - how some freedom of selection of domains can be offered - how to mix the method with other mechanisms This was (and is) planned for future revision. Note that ECMP and diversity are discussed already but we're planning the flesh out these sections in further revision. == Section 7 If the BRPC procedure cannot be completed because a PCE along the domain path does not support the procedure, a PCErr message is returned by the upstream PCE with a Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. Not clear to me whether PCE(n) is supposed to know that PCE(n+1) does not support brpc, presumably through capabilities configuration/advertisement/negotiation, or whether PCE(n+1) is supposed to respond to the path computation request saying that it does not support bit-V of the RP object. If the latter, presumably the PCErr comes from PCE(n+1) and not from PCE(n) as documented. Good catch, typo: it should read "a PCErr message is returned to the upstream". The plan is to define a capability bit (IGP) in a further revision. == Section 8 Metric normalisation is a great potential solution, but how does it fit with AS topology confidentiality? What is the solution to providing discretion about what TE connectivity is available within an AS, and operating brpc? Metric normalization is handled locally by the PCE and does not impact the BRPC procedure per-say. As far as confidentiality is concerned, this only requires for the SPs to exchange metric mapping information (nothing related to the network topology or resources); for example SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 A simple metric normalization can then be performed on the PCE thanks to simple cost mapping tables. Section 10 Some of this text has been seen before in this I-D Why do you single out LSP stitching as possibly breaking end-to-end optimality. There is functionally no difference between stitching and nesting in this respect. But further, your statement about stitching is pejorative! If you say that "In the case where a domain has more than one BR-en or more than one BR-ex, optimality after some network change within the domain can only be guaranteed by re-executing the full brpc computation" then I would agree with you. But as phrased, it implies that making a per-domain re-optimisation could make the path *less* optimal. This (of course) is not the case - per-domain optimisation will always improve or leave the same end-to-end optimality (in the case where new resources are made available this is obvious; in the case of a network failure, *any* path is better than no path!) And, lastly, the text about re-optimisation belongs in the next section, not in this section. Yes I wanted to leave that text to keep track of who would read the ID, expecting reaction ;-)) Per-domain reoptimization would always improve the current path *but* in case of stitched LSPs, TE LSP segments are computed by the stitching point; thus in case of failure, they could end up following a non optimal path whereas in the case of contiguous LSP, the BRPC procedure would be called again thus leading to the optimal path again. The point that I was trying to make is "if you have a stitched LSP and rely on BRPC when first signaled in an attempt to get an optimal path, you need to consider the interaction between the local reopt mode and BRPC if the goal is to preserve an optimal path at any given time". Anyway, we're on the same page and I agree and the text should be reworded according to your proposal to avoid any misunderstanding. == Section 13 I would like you to discuss the issues of confidentiality of topology information at greater length. It seems that you would possibly use this technique in conjunction with path cookies, which is fine. But, are there two things you cannot escape from? - indicating which BR-en provides best connectivity - indicating the metric for multiple BR-ens Maybe there are some things that can be done here based on policy, including not reporting all of the BR-ens, ranking rather than giving absolute metrics, etc. But these would compromise optimality. Indeed. Maybe the PCE(n+1) should carefully monitor and limit (statistically and by policy) brpc requests so that excessive information is not divulged? Since one of objectives for using the BRPC procedure is to compute an optimal path, we need to know at least the BN (Boundary Nodes) and the cost. == I wouldn't mind seeing a Management Considerations section. Do we need to be able to examine the pruned pieces of VSPT at transit PCEs? What are the implications of reporting multiple VSPT branches in PCEP to the MIB modules? Is brpc support something that needs to be configured: per PCE?; per PCE-neighbor? What are the implications on existing protocols (IGPs? PCEP?) of using brpc? Absolutely ! I put a placeholder for a further revision. Fully supportive of adding such section. Many Thanks for your comments ! JP. etc. == I think Jean-Louis' email address needs updating == The document would benefit from a little care in the formatting, and you could usefully re-read it for missing words, etc. == _______________________________________________ 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 Sun Jun 25 19:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fudoc-00054O-Oi; Sun, 25 Jun 2006 19:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fudoa-0004wh-LC for pce@ietf.org; Sun, 25 Jun 2006 19:14:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FudoY-0006Xz-OU for pce@ietf.org; Sun, 25 Jun 2006 19:14:52 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jun 2006 16:14:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,173,1149490800"; d="scan'208"; a="30442412:sNHT28938548" 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 k5PNEmYL001091; Sun, 25 Jun 2006 19:14:48 -0400 (EDT) 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.211); Sun, 25 Jun 2006 19:14:48 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Jun 2006 19:14:47 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F06FE61-537F-4713-A8BA-869492D5C4F9@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Sun, 25 Jun 2006 19:14:46 -0400 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 25 Jun 2006 23:14:47.0910 (UTC) FILETIME=[27152860:01C698AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4297a3b9ddbbc388d94c1425bc2288b8 Cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi dimitiri, On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > the following comment was also discussed during last meeting > > "== > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > => in brief, how to determine the sequence through which path > computation > has to be performed because if this sequence was known there is no > need > for such procedure (only inter-domain link selection would be > required) - Not correct; even if you know the sequence you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient. > now adrian mentions that pre- determination becomes a new constraint - > well actually this is not a constraint for the TE LSP itself but a > restriction on the domain set known to be (a-priori) supportive of the > method such as to make the method not returning an error message > No, this is a constraint: "Give me the shortest path (potentially made of loose hops (the BNs)) that provides the shortest end to end path, considering that the additional constraint is to traverse the following set of domains . > hence sentence "The BRPC procedure guarantees to compute the > optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > should as far as i understand the method fulfill the following > > a) this method provides a result iff all domains traversed by the > request > support the proposed method BRPC is a multi-PCE based approach where you need at least one PCE per-domain. > > b) this method provides an "optimal" result iff > > b1) all possible sequences of domains have been traversed (starting > from > the root) and are supportive of that method - as there might be an > optimal > path through a domain not supporting this method - > heu ... yes indeed. If a domain does not support the method, the method cannot be used to compute the path. > b2) there is no discontinuity in the availability of the inter-AS link > information on each PCE performing a given selection - indeed a domain > might be supportive of the method without supporting inter-AS link > flooding No this is not a requirement, just an optimization. The only requirement is for the PCE to get the TE-related data about the Inter- AS links. I'll detail a bit more in the next revision. > > b3) at each step there is no PCE that has partial visibility of a > given > domain > This is not specific to BRPC. Even with intra-domain if you want to compute the path for a TE LSP, you cannot always use the PCE if it has a partial visibility. Note that this also applies to the case of co-located PCE (when the path is computed by the head-end). > b4) during the selection process no network conditions changes > (that would > make the returned result void) > Again, this applies to other cases as well. thanks. JP. > > > > > > JP Vasseur > 23/06/2006 16:11 > > To: "Adrian Farrel" > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > Many Thanks Adrian for the comments. > > We incorporated the vast majority of them in the new revision (just > posted). > > See below for the comments requesting some clarification. > > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > > Hi, > > Thanks for keeping these ideas alive. > > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. > > Thanks, > Adrian > > == > Is this I-D likely to be Informational or Standards Track? From > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > == > > Status has been updated (Informational) but let's discuss this > later on. > FYI, it does not appear on the front page when using the xml2rfc > editor > (which by the way is excellent), thus the appendix addition. > > It would be nice if the Abstract contained a pithy summary of brpc > and/or > gave the motivation for the draft. For example, what is the method > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? > > Agree. Here is the new Abstract: > "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 (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) has been identified as a key > requirement . > This document specifies a procedure relying on the use of multiple > Path > Computation Elements (PCEs) in order to compute such inter-domain > shortest > constraint paths, using a backward recursive path computation > technique > while fully preserving confidentiality requirements across domains. " > > > == > I'm assuming that section 1 is for short term information only and > will be > deleted (in the next revision?) > == > > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. > > == > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would > argue that > reachability information (i.e. external routes) constitutes > topology and > resource information. > > > OK fine > > == > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed > that, at > the domain boundary LSRs, there will exist some sort of local > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? > > > It should actually read "pre-determined". Actually the best thing > to do > here is to remove "off-line" > > == > Section 5 > No assumption is made on the actual path computation algorithm in > use > by the PCE (it can be any variant of CSPF, algorithm based on > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! > > Well I'd suggest to keep it as is since the point is to > differentiate the > path computation procedure from the algorithm to compute each intra- > domain > path segment. Furthermore, we'd like to highlight the fact that the > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. > > == > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous > > It is actually a double tautology ;-) (fixed). > > == > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > == > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to > parse > and > to my mind the definition is arse about tit. I think you could > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! > > This is an abstract form of representation but see below, > > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. > > > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P > tree). > > == > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where, > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. > > This only works for unidirectional LSPs: indeed, the exit boundary > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP > running on > the link but how would a node in domain (i) get the TE-related data > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? > > == > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..." > is a > nascent Applicability Statement. I suggest moving this to another > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms > > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. > > == > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is > supposed > to > respond to the path computation request saying that it does not > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. > > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. > > == > Section 8 > Metric normalisation is a great potential solution, but how does it > fit > with > AS topology confidentiality? What is the solution to providing > discretion > about what TE connectivity is available within an AS, and operating > brpc? > > Metric normalization is handled locally by the PCE and does not > impact the > BRPC procedure per-say. As far as confidentiality is concerned, > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 > SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 > > A simple metric normalization can then be performed on the PCE > thanks to > simple cost mapping tables. > > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of > course) is > not > the case - per-domain optimisation will always improve or leave the > same > end-to-end optimality (in the case where new resources are made > available > this is obvious; in the case of a network failure, *any* path is > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next > section, > not > in this section. > > > Yes I wanted to leave that text to keep track of who would read the > ID, > expecting reaction ;-)) Per-domain reoptimization would always > improve the > current path *but* in case of stitched LSPs, TE LSP segments are > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP, > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a > stitched LSP > and rely on BRPC when first signaled in an attempt to get an > optimal path, > you need to consider the interaction between the local reopt mode > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. > > == > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use > this > technique in conjunction with path cookies, which is fine. But, are > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. > > Indeed. > > Maybe the PCE(n+1) should carefully monitor and limit > (statistically and > by > policy) brpc requests so that excessive information is not divulged? > > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. > > == > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? > > Absolutely ! I put a placeholder for a further revision. > > Fully supportive of adding such section. > > Many Thanks for your comments ! > > JP. > > etc. > == > > > > > > I think Jean-Louis' email address needs updating > > > == > The document would benefit from a little care in the formatting, > and you > could usefully re-read it for missing words, etc. > == > _______________________________________________ > 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 Sun Jun 25 19:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fue8R-0006Cc-FM; Sun, 25 Jun 2006 19:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fue8Q-0006BJ-6e for pce@ietf.org; Sun, 25 Jun 2006 19:35:22 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fue8P-0000gA-3Z for pce@ietf.org; Sun, 25 Jun 2006 19:35:22 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5PNZBqT031821; Mon, 26 Jun 2006 01:35:11 +0200 In-Reply-To: <5F06FE61-537F-4713-A8BA-869492D5C4F9@cisco.com> To: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 26 Jun 2006 01:35:16 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/26/2006 01:35:10, Serialize complete at 06/26/2006 01:35:10 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: 0e831a3b581a967a651997b2cbc2bae7 Cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-p - see in-line JP Vasseur 26/06/2006 01:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Adrian Farrel" , nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi dimitiri, On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > the following comment was also discussed during last meeting > > "== > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > => in brief, how to determine the sequence through which path > computation > has to be performed because if this sequence was known there is no > need > for such procedure (only inter-domain link selection would be > required) - Not correct; even if you know the sequence you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient. [dp] inter-domain link selection (as i mentioned) implies what you mean with boundary nodes selection - you could rephrase by access/exit point selection exact same business > now adrian mentions that pre- determination becomes a new constraint - > well actually this is not a constraint for the TE LSP itself but a > restriction on the domain set known to be (a-priori) supportive of the > method such as to make the method not returning an error message > No, this is a constraint: "Give me the shortest path (potentially made of loose hops (the BNs)) that provides the shortest end to end path, considering that the additional constraint is to traverse the following set of domains . [dp] incorrect, this is not a "TE LSP" constraint - since so far when a set of domains do not support/or support a given computation has not yet become a constraint > hence sentence "The BRPC procedure guarantees to compute the > optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > should as far as i understand the method fulfill the following > > a) this method provides a result iff all domains traversed by the > request > support the proposed method BRPC is a multi-PCE based approach where you need at least one PCE per-domain. [dp] indeed, but one PCE supporting that method and having FULL visibility of the domain > b) this method provides an "optimal" result iff > > b1) all possible sequences of domains have been traversed (starting > from > the root) and are supportive of that method - as there might be an > optimal > path through a domain not supporting this method - > heu ... yes indeed. If a domain does not support the method, the method cannot be used to compute the path. > b2) there is no discontinuity in the availability of the inter-AS link > information on each PCE performing a given selection - indeed a domain > might be supportive of the method without supporting inter-AS link > flooding No this is not a requirement, just an optimization. The only requirement is for the PCE to get the TE-related data about the Inter- AS links. I'll detail a bit more in the next revision. [dp] then you can never achieve - using your own words to make it more straighforward - "you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient." > b3) at each step there is no PCE that has partial visibility of a > given > domain > This is not specific to BRPC. Even with intra-domain if you want to compute the path for a TE LSP, you cannot always use the PCE if it has a partial visibility. Note that this also applies to the case of co-located PCE (when the path is computed by the head-end). [dp] hence, to BRPC as well > b4) during the selection process no network conditions changes > (that would > make the returned result void) > Again, this applies to other cases as well. [dp] ditto thanks. JP. > > > > > > JP Vasseur > 23/06/2006 16:11 > > To: "Adrian Farrel" > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > Many Thanks Adrian for the comments. > > We incorporated the vast majority of them in the new revision (just > posted). > > See below for the comments requesting some clarification. > > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > > Hi, > > Thanks for keeping these ideas alive. > > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. > > Thanks, > Adrian > > == > Is this I-D likely to be Informational or Standards Track? From > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > == > > Status has been updated (Informational) but let's discuss this > later on. > FYI, it does not appear on the front page when using the xml2rfc > editor > (which by the way is excellent), thus the appendix addition. > > It would be nice if the Abstract contained a pithy summary of brpc > and/or > gave the motivation for the draft. For example, what is the method > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? > > Agree. Here is the new Abstract: > "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 (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) has been identified as a key > requirement . > This document specifies a procedure relying on the use of multiple > Path > Computation Elements (PCEs) in order to compute such inter-domain > shortest > constraint paths, using a backward recursive path computation > technique > while fully preserving confidentiality requirements across domains. " > > > == > I'm assuming that section 1 is for short term information only and > will be > deleted (in the next revision?) > == > > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. > > == > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would > argue that > reachability information (i.e. external routes) constitutes > topology and > resource information. > > > OK fine > > == > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed > that, at > the domain boundary LSRs, there will exist some sort of local > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? > > > It should actually read "pre-determined". Actually the best thing > to do > here is to remove "off-line" > > == > Section 5 > No assumption is made on the actual path computation algorithm in > use > by the PCE (it can be any variant of CSPF, algorithm based on > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! > > Well I'd suggest to keep it as is since the point is to > differentiate the > path computation procedure from the algorithm to compute each intra- > domain > path segment. Furthermore, we'd like to highlight the fact that the > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. > > == > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous > > It is actually a double tautology ;-) (fixed). > > == > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > == > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to > parse > and > to my mind the definition is arse about tit. I think you could > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! > > This is an abstract form of representation but see below, > > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. > > > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P > tree). > > == > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where, > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. > > This only works for unidirectional LSPs: indeed, the exit boundary > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP > running on > the link but how would a node in domain (i) get the TE-related data > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? > > == > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..." > is a > nascent Applicability Statement. I suggest moving this to another > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms > > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. > > == > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is > supposed > to > respond to the path computation request saying that it does not > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. > > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. > > == > Section 8 > Metric normalisation is a great potential solution, but how does it > fit > with > AS topology confidentiality? What is the solution to providing > discretion > about what TE connectivity is available within an AS, and operating > brpc? > > Metric normalization is handled locally by the PCE and does not > impact the > BRPC procedure per-say. As far as confidentiality is concerned, > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 > SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 > > A simple metric normalization can then be performed on the PCE > thanks to > simple cost mapping tables. > > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of > course) is > not > the case - per-domain optimisation will always improve or leave the > same > end-to-end optimality (in the case where new resources are made > available > this is obvious; in the case of a network failure, *any* path is > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next > section, > not > in this section. > > > Yes I wanted to leave that text to keep track of who would read the > ID, > expecting reaction ;-)) Per-domain reoptimization would always > improve the > current path *but* in case of stitched LSPs, TE LSP segments are > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP, > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a > stitched LSP > and rely on BRPC when first signaled in an attempt to get an > optimal path, > you need to consider the interaction between the local reopt mode > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. > > == > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use > this > technique in conjunction with path cookies, which is fine. But, are > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. > > Indeed. > > Maybe the PCE(n+1) should carefully monitor and limit > (statistically and > by > policy) brpc requests so that excessive information is not divulged? > > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. > > == > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? > > Absolutely ! I put a placeholder for a further revision. > > Fully supportive of adding such section. > > Many Thanks for your comments ! > > JP. > > etc. > == > > > > > > I think Jean-Louis' email address needs updating > > > == > The document would benefit from a little care in the formatting, > and you > could usefully re-read it for missing words, etc. > == > _______________________________________________ > 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 Sun Jun 25 20:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FufDg-0001R9-Dv; Sun, 25 Jun 2006 20:44:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FufB5-0006Kh-Sd for pce@ietf.org; Sun, 25 Jun 2006 20:42:11 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FufB1-0003Hd-HK for pce@ietf.org; Sun, 25 Jun 2006 20:42:11 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 25 Jun 2006 20:42:07 -0400 X-IronPort-AV: i="4.06,173,1149480000"; d="scan'208,217"; a="90979533:sNHT98024176" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5Q0g6no007187; Sun, 25 Jun 2006 20:42:06 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Jun 2006 20:42:06 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 25 Jun 2006 20:42:02 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Message-Id: From: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Sun, 25 Jun 2006 20:42:00 -0400 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 26 Jun 2006 00:42:02.0207 (UTC) FILETIME=[56F77EF0:01C698B9] X-Spam-Score: 0.5 (/) X-Scan-Signature: 82dc977d1ba167f9822a8f0be8c5b628 X-Mailman-Approved-At: Sun, 25 Jun 2006 20:44:51 -0400 Cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1518319221==" Errors-To: pce-bounces@lists.ietf.org --===============1518319221== Content-Type: multipart/alternative; boundary=Apple-Mail-25--970854821 --Apple-Mail-25--970854821 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi dimitri, On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: > hi j-p - see in-line > > > > > JP Vasseur > 26/06/2006 01:14 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" , > nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > hi dimitiri, > > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > >> the following comment was also discussed during last meeting >> >> "== >> Section 5.1 >> I like the simplicity of section 5.1, but I think you need to point >> out >> that >> if the sequence of domains is known a priori (can you determine it a >> priori?) then the path computed might not be 'optimal' in the usual >> sense >> of >> the word, but that this is OK because the ordered list of domains >> constitutes an additional constraint on the computation so the >> resultant >> path *is* optimal within the constraints applied. >> >> Can't agree more. Good suggestion, thanks. >> >> Updated text: "The PCE-based BRPC procedure applies to the >> computation of >> an optimal constrained inter-domain TE LSP. The sequence of domains >> to be >> traversed can either be determined a priori or during the path >> computation >> procedure. The BRPC procedure guarantees to compute the optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> => in brief, how to determine the sequence through which path >> computation >> has to be performed because if this sequence was known there is no >> need >> for such procedure (only inter-domain link selection would be >> required) - > > Not correct; even if you know the sequence you still need the BRPC > procedure to figure out the set of BN (boundary Nodes) to traverse to > get the shortest inter-domain TE LSP: this is the whole issue with > inter-domain, otherwise per-domain path computation would be > sufficient. > > [dp] inter-domain link selection (as i mentioned) implies what you > mean > with boundary nodes selection - you could rephrase by access/exit > point > selection exact same business but again even if you know the sequence you still need BRPC to determine the set of BN (or exit point - same thing) that will give you the shortest inter-domain path. Look you wrote "in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure", which is not correct. Even if you know the sequence of domains, you still need the procedure to get the exit/entry point (named BN) that provide you the shortest inter-domain path. > >> now adrian mentions that pre- determination becomes a new >> constraint - >> well actually this is not a constraint for the TE LSP itself but a >> restriction on the domain set known to be (a-priori) supportive of >> the >> method such as to make the method not returning an error message >> > > No, this is a constraint: "Give me the shortest path (potentially > made of loose hops (the BNs)) that provides the shortest end to end > path, considering that the additional constraint is to traverse the > following set of domains . > > [dp] incorrect, this is not a "TE LSP" constraint - Who said that this was a TE LSP constraint ? This is *a* constraint. If you impose the set of domain, this is a constraint. Please read the text: "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint)." Note that at this point, I still do not see the point that you're trying to make here ? > since so far when > a set of domains do not support/or support a given computation has not > yet become a constraint > >> hence sentence "The BRPC procedure guarantees to compute the >> optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> should as far as i understand the method fulfill the following >> >> a) this method provides a result iff all domains traversed by the >> request >> support the proposed method > > BRPC is a multi-PCE based approach where you need at least one PCE > per-domain. > > [dp] indeed, but one PCE supporting that method and having FULL > visibility of the domain So what is your point here ? > >> b) this method provides an "optimal" result iff >> >> b1) all possible sequences of domains have been traversed (starting >> from >> the root) and are supportive of that method - as there might be an >> optimal >> path through a domain not supporting this method - >> > > heu ... yes indeed. If a domain does not support the method, the > method cannot be used to compute the path. > >> b2) there is no discontinuity in the availability of the inter-AS >> link >> information on each PCE performing a given selection - indeed a >> domain >> might be supportive of the method without supporting inter-AS link >> flooding > > No this is not a requirement, just an optimization. The only > requirement is for the PCE to get the TE-related data about the Inter- > AS links. I'll detail a bit more in the next revision. > > [dp] then you can never achieve - You can never achieve what ? Sorry Dimitri, I'd love to accommodate your comment but I do not see your point ... hopefully we'll have a bit of time in Montreal to discuss if that does not work by email. > using your own words to make it more > straighforward - > > "you still need the BRPC procedure to figure out the set of BN > (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP: this is > the > whole issue with inter-domain, otherwise per-domain path > computation would > > be sufficient." > >> b3) at each step there is no PCE that has partial visibility of a >> given >> domain >> > > This is not specific to BRPC. Even with intra-domain if you want to > compute the path for a TE LSP, you cannot always use the PCE if it > has a partial visibility. Note that this also applies to the case of > co-located PCE (when the path is computed by the head-end). > > [dp] hence, to BRPC as well > >> b4) during the selection process no network conditions changes >> (that would >> make the returned result void) >> > > Again, this applies to other cases as well. > > [dp] ditto > Ah so we agree here :-) What was your comment then ? Thanks. JP. > > > thanks. > > JP. > >> >> >> >> >> >> JP Vasseur >> 23/06/2006 16:11 >> >> To: "Adrian Farrel" >> cc: raymond_zhang@bt.infonet.com, pce@ietf.org, >> nabil.n.bitar@verizon.com >> Subject: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> Many Thanks Adrian for the comments. >> >> We incorporated the vast majority of them in the new revision (just >> posted). >> >> See below for the comments requesting some clarification. >> >> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >> >> Hi, >> >> Thanks for keeping these ideas alive. >> >> Here are some picky thoughts that you may want to include in the next >> revision to make it more robust as a document. I don't have any >> issues >> with >> the basic process. >> >> Thanks, >> Adrian >> >> == >> Is this I-D likely to be Informational or Standards Track? From >> Appendix >> A, >> this looks like Standards Track. Can you remove Appendix A and put >> the >> status in the usual place in the header? >> == >> >> Status has been updated (Informational) but let's discuss this >> later on. >> FYI, it does not appear on the front page when using the xml2rfc >> editor >> (which by the way is excellent), thus the appendix addition. >> >> It would be nice if the Abstract contained a pithy summary of brpc >> and/or >> gave the motivation for the draft. For example, what is the method >> trying >> to >> achieve that isn't achievable by other methods? Or, what is the >> fundamental >> element of brpc that is not in other methods? >> >> Agree. Here is the new Abstract: >> "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 (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) has been identified as a key >> requirement . >> This document specifies a procedure relying on the use of multiple >> Path >> Computation Elements (PCEs) in order to compute such inter-domain >> shortest >> constraint paths, using a backward recursive path computation >> technique >> while fully preserving confidentiality requirements across domains. " >> >> >> == >> I'm assuming that section 1 is for short term information only and >> will be >> deleted (in the next revision?) >> == >> >> Indeed, just to provide a bit of history for the ones who have been >> following inter-domain path computation for a while. >> >> == >> Section 4 >> - No topology or resource information is distributed between >> domains >> (as mandated per [RFC4105] and [RFC4216]), which is critical to >> preserve IGP/BGP scalability and confidentiality in the case of TE >> LSPs spanning multiple domains. >> You should clarify what you are saying here, because many would >> argue that >> reachability information (i.e. external routes) constitutes >> topology and >> resource information. >> >> >> OK fine >> >> == >> Section 4 >> - While certain constraints like bandwidth can be used across >> different domains, certain other TE constraints like resource >> affinity, color, metric, etc. as listed in [RFC2702] could be >> translated at domain boundaries. If required, it is assumed >> that, at >> the domain boundary LSRs, there will exist some sort of local >> mapping >> based on offline policy agreement, in order to translate such >> constraints across domain boundaries during the inter-PCE >> communication process. >> Why does the policy agreement need to be offline? >> >> >> It should actually read "pre-determined". Actually the best thing >> to do >> here is to remove "off-line" >> >> == >> Section 5 >> No assumption is made on the actual path computation algorithm in >> use >> by the PCE (it can be any variant of CSPF, algorithm based on >> linear- >> programming to solve multi-constraints optimization problems and so >> on). >> Suggest that you delete the text in parenthesis because it is making >> suggestions that border on assumptions! >> >> Well I'd suggest to keep it as is since the point is to >> differentiate the >> path computation procedure from the algorithm to compute each intra- >> domain >> path segment. Furthermore, we'd like to highlight the fact that the >> BRPC >> procedure does not mandate for each PCE to use CSPF, could be other >> algorithm. >> >> == >> Section 5.1 and throughout >> "BRPC path computation" seems to be tautologous >> >> It is actually a double tautology ;-) (fixed). >> >> == >> Section 5.1 >> I like the simplicity of section 5.1, but I think you need to point >> out >> that >> if the sequence of domains is known a priori (can you determine it a >> priori?) then the path computed might not be 'optimal' in the usual >> sense >> of >> the word, but that this is OK because the ordered list of domains >> constitutes an additional constraint on the computation so the >> resultant >> path *is* optimal within the constraints applied. >> >> Can't agree more. Good suggestion, thanks. >> >> Updated text: "The PCE-based BRPC procedure applies to the >> computation of >> an optimal constrained inter-domain TE LSP. The sequence of domains >> to be >> traversed can either be determined a priori or during the path >> computation >> procedure. The BRPC procedure guarantees to compute the optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> == >> Section 5.2 >> The introduction of the term Virtual Shortest Path Tree is hard to >> parse >> and >> to my mind the definition is arse about tit. I think you could >> usefully >> add >> some textual definition of what the VSPT is trying to achieve, before >> presenting it in pictorial or abstract form. >> Even more important (I think) is the fact that the tree as presented >> "represents the shortest path between the destination and BR-en >> (j,i)..." >> Frankly, we are building directional paths in exactly the oposite >> direction! >> >> This is an abstract form of representation but see below, >> >> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP >> tree as >> described. >> I suspect that this is just a textual descriptive issue rather than >> anything >> broken in the process. >> >> >> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P >> tree). >> >> == >> Section 5.2 >> I suggest that you pull the note (Note: in term of computation...) >> out >> into >> a separate section. It doesn't belong in the middle of section 5.2. >> You will probably want to re-write the text as well since the >> unidirectional >> limit is not necessary. Also to explain 'flood' - flood to where, >> and how, >> and by whom? And you will want to add to pieces of information: >> - the link to the I-D that defines how to do this >> - a description of what happens if this process is not used. >> >> This only works for unidirectional LSPs: indeed, the exit boundary >> node >> can flood TE-related data in its LSA/LSP for the link >> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP >> running on >> the link but how would a node in domain (i) get the TE-related data >> for >> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the >> restriction on >> unidirectional link. Are we in sync ? >> >> == >> Section 5.2 >> The paragraph that begins "BRPC guarantees to find the optimal..." >> is a >> nascent Applicability Statement. I suggest moving this to another >> Section >> and significantly beefing it up. You need to describe more fully: >> - how ECMP works (the PCC has to request the return of more than >> one path) >> - how diversity works (i.e. section 9 fits in here) >> - how some freedom of selection of domains can be offered >> - how to mix the method with other mechanisms >> >> This was (and is) planned for future revision. Note that ECMP and >> diversity are discussed already but we're planning the flesh out >> these >> sections in further revision. >> >> == >> Section 7 >> If the BRPC procedure cannot be completed because a PCE along the >> domain path does not support the procedure, a PCErr message is >> returned by the upstream PCE with a Error-Type "BRPC procedure >> completion failure". The PCErr message MUST be relayed to the >> requesting PCC. >> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >> does not >> support brpc, presumably through capabilities >> configuration/advertisement/negotiation, or whether PCE(n+1) is >> supposed >> to >> respond to the path computation request saying that it does not >> support >> bit-V of the RP object. If the latter, presumably the PCErr comes >> from >> PCE(n+1) and not from PCE(n) as documented. >> >> Good catch, typo: it should read "a PCErr message is returned to the >> upstream". >> The plan is to define a capability bit (IGP) in a further revision. >> >> == >> Section 8 >> Metric normalisation is a great potential solution, but how does it >> fit >> with >> AS topology confidentiality? What is the solution to providing >> discretion >> about what TE connectivity is available within an AS, and operating >> brpc? >> >> Metric normalization is handled locally by the PCE and does not >> impact the >> BRPC procedure per-say. As far as confidentiality is concerned, >> this only >> requires for the SPs to exchange metric mapping information (nothing >> related to the network topology or resources); for example >> SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 >> SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 >> >> A simple metric normalization can then be performed on the PCE >> thanks to >> simple cost mapping tables. >> >> Section 10 >> Some of this text has been seen before in this I-D >> Why do you single out LSP stitching as possibly breaking end-to-end >> optimality. There is functionally no difference between stitching and >> nesting in this respect. >> But further, your statement about stitching is pejorative! If you >> say that >> "In the case where a domain has more than one BR-en or more than one >> BR-ex, >> optimality after some network change within the domain can only be >> guaranteed by re-executing the full brpc computation" then I would >> agree >> with you. But as phrased, it implies that making a per-domain >> re-optimisation could make the path *less* optimal. This (of >> course) is >> not >> the case - per-domain optimisation will always improve or leave the >> same >> end-to-end optimality (in the case where new resources are made >> available >> this is obvious; in the case of a network failure, *any* path is >> better >> than >> no path!) >> And, lastly, the text about re-optimisation belongs in the next >> section, >> not >> in this section. >> >> >> Yes I wanted to leave that text to keep track of who would read the >> ID, >> expecting reaction ;-)) Per-domain reoptimization would always >> improve the >> current path *but* in case of stitched LSPs, TE LSP segments are >> computed >> by the stitching point; thus in case of failure, they could end up >> following a non optimal path whereas in the case of contiguous LSP, >> the >> BRPC procedure would be called again thus leading to the optimal path >> again. The point that I was trying to make is "if you have a >> stitched LSP >> and rely on BRPC when first signaled in an attempt to get an >> optimal path, >> you need to consider the interaction between the local reopt mode >> and BRPC >> if the goal is to preserve an optimal path at any given time". >> Anyway, >> we're on the same page and I agree and the text should be reworded >> according to your proposal to avoid any misunderstanding. >> >> == >> Section 13 >> I would like you to discuss the issues of confidentiality of topology >> information at greater length. It seems that you would possibly use >> this >> technique in conjunction with path cookies, which is fine. But, are >> there >> two things you cannot escape from? >> - indicating which BR-en provides best connectivity >> - indicating the metric for multiple BR-ens >> Maybe there are some things that can be done here based on policy, >> including >> not reporting all of the BR-ens, ranking rather than giving absolute >> metrics, etc. But these would compromise optimality. >> >> Indeed. >> >> Maybe the PCE(n+1) should carefully monitor and limit >> (statistically and >> by >> policy) brpc requests so that excessive information is not divulged? >> >> Since one of objectives for using the BRPC procedure is to compute an >> optimal path, we need to know at least the BN (Boundary Nodes) and >> the >> cost. >> >> == >> I wouldn't mind seeing a Management Considerations section. >> Do we need to be able to examine the pruned pieces of VSPT at transit >> PCEs? >> What are the implications of reporting multiple VSPT branches in >> PCEP to >> the >> MIB modules? >> Is brpc support something that needs to be configured: per PCE?; per >> PCE-neighbor? >> What are the implications on existing protocols (IGPs? PCEP?) of >> using >> brpc? >> >> Absolutely ! I put a placeholder for a further revision. >> >> Fully supportive of adding such section. >> >> Many Thanks for your comments ! >> >> JP. >> >> etc. >> == >> >> >> >> >> >> I think Jean-Louis' email address needs updating >> >> >> == >> The document would benefit from a little care in the formatting, >> and you >> could usefully re-read it for missing words, etc. >> == >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-25--970854821 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi dimitri,

On = Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alc= atel.be wrote:

hi j-p - see in-line




JP = Vasseur <jvasseur@cisco.com>
26/06/2006 01:14

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>,=A0



the following = comment was also discussed during last meeting

Section 5.1
I like the simplicity of section 5.1, but I think = you need to point=A0
out
if the sequence of domains is = known a priori (can you determine it a
priori?) = then the path computed might not be 'optimal' in the usual=A0
of
the = word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the = computation so the=A0
resultant
path *is* = optimal within the constraints applied.

Can't agree = more. Good suggestion, thanks.

Updated text: "The PCE-based = BRPC procedure applies to the=A0
an optimal constrained = inter-domain TE LSP. The sequence of domains=A0
to = be
traversed can either be determined a priori or = during the path=A0
computation
procedure. = The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which = constitutes
an additional constraint). In = the case of an arbitrary set of meshed
domains, = the BRPC procedure can be used to compute the optimal path=A0
each domain set in order to get = to optimal constrained path between=A0
source and the destination of = the TE LSP."

=3D> in brief, how to determine the sequence = through which path=A0
computation
has to be = performed because if this sequence was known there is no=A0
for such procedure (only = inter-domain link selection would be=A0

Not correct; even if you know = the sequence you still need the BRPC=A0
=A0
get the shortest inter-domain TE LSP: this is the = whole issue with=A0
inter-domain, otherwise per-domain path computation = would be sufficient.
[dp] inter-domain link selection = (as i mentioned) implies what you mean=A0
with = boundary nodes selection - you could rephrase by access/exit point=A0
but again even if you know the sequence you = still need BRPC to determine the set of BN (or exit point - same thing) = that will give you the shortest inter-domain path. Look you wrote "in = brief, how to determine the sequence through which path=A0computation=A0ha= s to be performed because if this sequence was known there is = no=A0need=A0for such procedure", which is not correct. Even if you = know the sequence of domains, you still need the procedure to get the = exit/entry point (named BN) that provide you the shortest inter-domain = path.


now adrian mentions that pre- = determination becomes a new constraint -
well = actually this is not a constraint for the TE LSP itself but a
restriction on the domain set known to be (a-priori) = supportive of the
method such as to make the = method not returning an error message


No, this is a = constraint: "Give me the shortest path (potentially=A0
made of = loose hops (the BNs)) that provides the shortest end to end=A0
path, = considering that the additional constraint is to traverse the=A0

[dp] = incorrect, this is not a "TE LSP" constraint - =

Who said that this was a TE = LSP constraint ? This is *a* constraint. If you impose the set of = domain, this is a constraint.

Please read the text: "The BRPC procedure = guarantees to compute the optimal path across a specific set of = traversed domains (which=A0constitutes an additional = constraint)."

Note that at this point, I = still do not see the point that you're trying to make here = ?

since so far = when
a set of domains do not = support/or support a given computation has not
yet become a constraint

hence sentence "The BRPC procedure guarantees to = compute the=A0
optimal path
across a = specific set of traversed domains (which constitutes
an additional constraint). In the case of an = arbitrary set of meshed
domains, the = BRPC procedure can be used to compute the optimal path=A0
each domain set in order to get = to optimal constrained path between=A0
source and the destination of = the TE LSP."

should as far as i understand the method fulfill the = following

a) this method provides a result iff all domains = traversed by the=A0
request
support the = proposed method

BRPC is a multi-PCE based = approach where you need at least one PCE=A0

[dp] indeed, but one PCE supporting that method and = having FULL=A0
visibility of the domain

So what is your point here = ?


b) this = method provides an "optimal" result iff

b1) all = possible sequences of domains have been traversed (starting=A0
the root) and are supportive of = that method - as there might be an=A0
path through a domain not = supporting this method -


heu ... yes indeed. If a domain = does not support the method, the=A0
method = cannot be used to compute the path.

b2) = there is no discontinuity in the availability of the inter-AS = link
information on each PCE = performing a given selection - indeed a domain
might be supportive of the method without supporting = inter-AS link
flooding

No this = is not a requirement, just an optimization. The only=A0
=A0
AS links. I'll detail a bit more in the next = revision.

[dp] then you can never achieve = -

You can never achieve what = ?

Sorry = Dimitri, I'd love to=A0accommodate your comment but I do not see your = point ... hopefully we'll have a bit of time in Montreal to discuss if = that does not work by email.

using your own words to make it more
straighforward -=A0

"you still = need the BRPC procedure to figure out the set of BN (boundary=A0
Nodes) = to traverse to get the shortest inter-domain TE LSP: this is the=A0
whole = issue with inter-domain, otherwise per-domain path computation = would=A0

be = sufficient."

=
b3) at each step there is = no PCE that has partial visibility of a=A0
domain


This is = not specific to BRPC. Even with intra-domain if you want to=A0
compute = the path for a TE LSP, you cannot always use the PCE if it=A0
has a = partial visibility. Note that this also applies to the case of=A0

[dp] = hence, to BRPC as well
b4) during = the selection process no network conditions changes=A0
(that = would
make the returned result = void)

=

Again, this applies to other cases as = well.

[dp] ditto


Ah so we agree here = :-)

What was = your comment then ?

Thanks.

JP.




JP.






JP Vasseur = <jvasseur@cisco.com>
23/06/2006 16:11

=A0 =A0 =A0 =A0 To: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>
nabil.n.bitar@verizon.com
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = [Pce] Re: Comments on


Many Thanks Adrian for the comments.

We = incorporated the vast majority of them in the new revision = (just
posted).

See = below for the comments requesting some clarification.

On Jun = 10, 2006, at 8:49 AM, Adrian Farrel wrote:

Hi,

Thanks = for keeping these ideas alive.

Here are some picky thoughts = that you may want to include in the next
revision = to make it more robust as a document. I don't have any issues
with
the basic = process.

Thanks,

=3D=3D
Is this I-D = likely to be Informational or Standards Track? From=A0
A,
this = looks like Standards Track. Can you remove Appendix A and put = the
status in the usual place in the = header?
=3D=3D

Status = has been updated (Informational) but let's discuss this=A0
later = on.
FYI, it does not appear on the = front page when using the xml2rfc=A0
(which by the way is excellent), = thus the appendix addition.

It would be nice if the Abstract = contained a pithy summary of brpc=A0
gave the motivation for the = draft. For example, what is the method=A0
to
achieve = that isn't achievable by other methods? Or, what is the
fundamental
element of = brpc that is not in other methods?

Agree. Here is the new = Abstract:
"The ability to compute = constrained shortest Traffic Engineering (TE)
Label Switched Paths (LSPs) in Multiprotocol Label = Switching (MPLS)=A0
and
Generalized = MPLS (GMPLS) networks across multiple domains (where a=A0
is referred to as a collection = of network elements within a common=A0
of address management or path = computational responsibility such as IGP
areas = and Autonomous Systems) has been identified as a key=A0
This document specifies a = procedure relying on the use of multiple=A0
Computation Elements (PCEs) in = order to compute such inter-domain=A0
constraint paths, using a = backward recursive path computation=A0
while fully preserving = confidentiality requirements across domains. "


=3D=3D
I'm assuming that section 1 is for short term = information only and=A0
will = be
deleted (in the next revision?)
=3D=3D

Indeed, just to provide a bit of = history for the ones who have been
following = inter-domain path computation for a while.

=3D=3D
Section 4
=A0 - No topology or resource = information is distributed between domains
=A0 (as mandated per [RFC4105] = and [RFC4216]), which is critical to
=A0 preserve IGP/BGP scalability = and confidentiality in the case of TE
=A0 LSPs spanning multiple = domains.
You should clarify what you are = saying here, because many would=A0
argue = that
reachability information (i.e. = external routes) constitutes=A0
topology = and
resource information.


OK = fine

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

It should actually read "pre-determined". Actually = the best thing=A0
to do
here is to = remove "off-line"

=3D=3D
Section = 5
=A0 = No assumption is made on the actual path computation algorithm = in=A0
use
=A0 by the PCE (it can be any = variant of CSPF, algorithm based on=A0
=A0 programming to solve = multi-constraints optimization problems and so
=A0 = on).
Suggest that you delete the text = in parenthesis because it is making
suggestions = that border on assumptions!

Well I'd suggest to keep it as = is since the point is to=A0
path computation procedure = from the algorithm to compute each intra-=A0
path segment. Furthermore, we'd = like to highlight the fact that the=A0
procedure does not mandate for = each PCE to use CSPF, could be other

=3D=3D
Section 5.1 = and throughout
"BRPC path computation" seems to = be tautologous

It is actually a double tautology ;-) = (fixed).

=3D=3D
Section = 5.1
I like the simplicity of section = 5.1, but I think you need to point=A0
that
if the sequence of domains is known a priori (can = you determine it a
priori?) then the path = computed might not be 'optimal' in the usual=A0
of
the = word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the = computation so the=A0
resultant
path *is* = optimal within the constraints applied.

Can't agree = more. Good suggestion, thanks.

Updated text: "The PCE-based = BRPC procedure applies to the=A0
an optimal constrained = inter-domain TE LSP. The sequence of domains=A0
to = be
traversed can either be determined a priori or = during the path=A0
computation
procedure. = The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which = constitutes
an additional constraint). In = the case of an arbitrary set of meshed
domains, = the BRPC procedure can be used to compute the optimal path=A0
each domain set in order to get = to optimal constrained path between=A0
source and the destination of = the TE LSP."

=3D=3D
Section = 5.2
The introduction of the term = Virtual Shortest Path Tree is hard to=A0
and
to my = mind the definition is arse about tit. I think you could=A0
add
some = textual definition of what the VSPT is trying to achieve, = before
presenting it in pictorial or = abstract form.
Even more important (I think) is = the fact that the tree as presented
"represents = the shortest path between the destination and BR-en=A0
Frankly, we are building = directional paths in exactly the oposite

This is an abstract form of representation but see = below,

So the VSPT is still a tree, but it is an MP2P tree, = not a P2MP=A0
tree as
I suspect that this is just a = textual descriptive issue rather than
broken in the process.


I clarified = the text to avoid any ambiguity (VSPT defined as a MP2P=A0

=3D=3D
Section = 5.2
I suggest that you pull the note = (Note: in term of computation...) out
a separate section. It doesn't = belong in the middle of section 5.2.
You will = probably want to re-write the text as well since the
unidirectional
limit is not = necessary. Also to explain 'flood' - flood to where,=A0
and = how,
and by whom? And you will want = to add to pieces of information:
- the link to = the I-D that defines how to do this
- a = description of what happens if this process is not used.

This = only works for unidirectional LSPs: indeed, the exit boundary=A0
can flood TE-related data in its = LSA/LSP for the link
=A0
running = on
the link but how would a node in domain (i) get = the TE-related data=A0
the link = entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction = on
unidirectional link. Are we in sync ?

Section 5.2
The paragraph that begins "BRPC guarantees to find = the optimal..."=A0
is a
nascent = Applicability Statement. I suggest moving this to another=A0
and significantly beefing it up. = You need to describe more fully:
- how ECMP = works (the PCC has to request the return of more than=A0
one = path)
- how diversity works (i.e. = section 9 fits in here)
- how some = freedom of selection of domains can be offered
- how to mix the method with other = mechanisms

This was (and is) planned for future revision. Note = that ECMP and
diversity are discussed already = but we're planning the flesh out these
sections = in further revision.
=3D=3D
Section 7
=A0 If the BRPC procedure cannot = be completed because a PCE along the
=A0 domain path does not support = the procedure, a PCErr message is
=A0 returned by the upstream PCE = with a Error-Type "BRPC procedure
=A0 completion failure".=A0 The PCErr message MUST be = relayed to the
=A0 requesting PCC.
Not clear to me whether PCE(n) is supposed to know = that PCE(n+1)=A0
does not
support brpc, = presumably through capabilities
=A0
to
respond = to the path computation request saying that it does not=A0
bit-V of the RP object. If the = latter, presumably the PCErr comes from
PCE(n+1) = and not from PCE(n) as documented.

Good catch, typo: it should read = "a PCErr message is returned to the
The plan is to define a = capability bit (IGP) in a further revision.

=3D=3D
Section 8
Metric = normalisation is a great potential solution, but how does it=A0
with
AS topology confidentiality? What is the solution to = providing=A0
discretion
about what TE = connectivity is available within an AS, and operating=A0

Metric normalization is handled locally by the PCE = and does not=A0
impact the
BRPC = procedure per-say. As far as confidentiality is concerned,=A0
this = only
requires for the SPs to exchange = metric mapping information (nothing
related to = the network topology or resources); for example
SP 1 Links Cost =3D F (link_bandwidth) with F = (OC192)=3D1
SP 2 Links Cost =3D F = (link_bandwidth) with F (OC192)=3D10

A simple metric normalization = can then be performed on the PCE=A0
thanks = to
simple cost mapping tables.

Section = 10
Some of this text has been seen before in this = I-D
Why do you single out LSP = stitching as possibly breaking end-to-end
nesting in this = respect.
But further, your statement = about stitching is pejorative! If you=A0
say = that
"In the case where a domain has = more than one BR-en or more than one
optimality after some network = change within the domain can only be
guaranteed by = re-executing the full brpc computation" then I would=A0
with you. But as phrased, it = implies that making a per-domain
=A0
course) = is
not
the case - = per-domain optimisation will always improve or leave the=A0
end-to-end optimality (in the = case where new resources are made=A0
this is obvious; in the case of = a network failure, *any* path is=A0
than
no path!)
And, lastly, = the text about re-optimisation belongs in the next=A0
not
in this = section.


Yes I = wanted to leave that text to keep track of who would read the=A0
expecting reaction ;-)) = Per-domain reoptimization would always=A0
improve = the
current path *but* in case of = stitched LSPs, TE LSP segments are=A0
by the stitching point; thus in = case of failure, they could end up
following a = non optimal path whereas in the case of contiguous LSP,=A0
BRPC procedure would be called = again thus leading to the optimal path
again. = The point that I was trying to make is "if you have a=A0
stitched = LSP
and rely on BRPC when first = signaled in an attempt to get an=A0
optimal = path,
you need to consider the = interaction between the local reopt mode=A0
and = BRPC
if the goal is to preserve an = optimal path at any given time". Anyway,
we're on = the same page and I agree and the text should be reworded
according to your proposal to avoid any = misunderstanding.

=3D=3D
Section = 13
I would like you to discuss the issues of = confidentiality of topology
information = at greater length. It seems that you would possibly use=A0
technique in conjunction with = path cookies, which is fine. But, are=A0
two things you cannot escape = from?
- indicating which BR-en = provides best connectivity
- indicating = the metric for multiple BR-ens
Maybe there = are some things that can be done here based on policy,
including
not reporting = all of the BR-ens, ranking rather than giving absolute
metrics, etc. But these would compromise = optimality.

Indeed.

Maybe the PCE(n+1) should = carefully monitor and limit=A0
by
policy) brpc requests so that excessive information = is not divulged?

Since one of objectives for using the BRPC procedure = is to compute an
optimal path, we need to know at = least the BN (Boundary Nodes) and the

=3D=3D
I wouldn't = mind seeing a Management Considerations section.
Do we need to be able to examine the pruned pieces = of VSPT at transit
PCEs?
What are the implications of reporting multiple VSPT = branches in=A0
PCEP to
the
MIB modules?
Is brpc = support something that needs to be configured: per PCE?; per
PCE-neighbor?
What are the = implications on existing protocols (IGPs? PCEP?) of using
brpc?

Absolutely ! I put a placeholder = for a further revision.

Fully supportive of adding such = section.

Many Thanks for your comments !


etc.
=3D=3D





I think = Jean-Louis' email address needs updating


=3D=3D
The document would benefit from a little care in the = formatting,=A0
and you
could = usefully re-read it for missing words, etc.
Pce mailing list
=

= --Apple-Mail-25--970854821-- --===============1518319221== 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 --===============1518319221==-- From pce-bounces@lists.ietf.org Mon Jun 26 02:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fukwa-0002U8-Az; Mon, 26 Jun 2006 02:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FukwY-0002SS-KN for pce@ietf.org; Mon, 26 Jun 2006 02:51:34 -0400 Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FukwV-0002am-Hy for pce@ietf.org; Mon, 26 Jun 2006 02:51:34 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5Q6pKMu019480; Mon, 26 Jun 2006 08:51:20 +0200 In-Reply-To: To: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 26 Jun 2006 08:51:23 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/26/2006 08:51:19, Serialize complete at 06/26/2006 08:51:19 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: 466662da679e1d2dece19de64e166a5b Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-p - see in-line JP Vasseur 26/06/2006 02:42 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi dimitri, On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi j-p - see in-line JP Vasseur 26/06/2006 01:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Adrian Farrel" , nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi dimitiri, On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: the following comment was also discussed during last meeting "== Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." => in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure (only inter-domain link selection would be required) - Not correct; even if you know the sequence you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient. [dp] inter-domain link selection (as i mentioned) implies what you mean with boundary nodes selection - you could rephrase by access/exit point selection exact same business but again even if you know the sequence you still need BRPC to determine the set of BN (or exit point - same thing) that will give you the shortest inter-domain path. Look you wrote "in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure", which is not correct. Even if you know the sequence of domains, you still need the procedure to get the exit/entry point (named BN) that provide you the shortest inter-domain path. now adrian mentions that pre- determination becomes a new constraint - well actually this is not a constraint for the TE LSP itself but a restriction on the domain set known to be (a-priori) supportive of the method such as to make the method not returning an error message No, this is a constraint: "Give me the shortest path (potentially made of loose hops (the BNs)) that provides the shortest end to end path, considering that the additional constraint is to traverse the following set of domains . [dp] incorrect, this is not a "TE LSP" constraint - Who said that this was a TE LSP constraint ? This is *a* constraint. If you impose the set of domain, this is a constraint. Please read the text: "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint)." [dp] i read this, mind you, my point is that this is not a "constraint" of the same nature as the one you're making use such as minimize delays or whatsover - this constraint is introduced from the computation technique and mechanism of this proposed method Note that at this point, I still do not see the point that you're trying to make here ? since so far when a set of domains do not support/or support a given computation has not yet become a constraint hence sentence "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." should as far as i understand the method fulfill the following a) this method provides a result iff all domains traversed by the request support the proposed method BRPC is a multi-PCE based approach where you need at least one PCE per-domain. [dp] indeed, but one PCE supporting that method and having FULL visibility of the domain So what is your point here ? [dp] that the set of conditions to have this method workable is larger than the one listed in this doc. b) this method provides an "optimal" result iff b1) all possible sequences of domains have been traversed (starting from the root) and are supportive of that method - as there might be an optimal path through a domain not supporting this method - heu ... yes indeed. If a domain does not support the method, the method cannot be used to compute the path. b2) there is no discontinuity in the availability of the inter-AS link information on each PCE performing a given selection - indeed a domain might be supportive of the method without supporting inter-AS link flooding No this is not a requirement, just an optimization. The only requirement is for the PCE to get the TE-related data about the Inter- AS links. I'll detail a bit more in the next revision. [dp] then you can never achieve - You can never achieve what ? Sorry Dimitri, I'd love to accommodate your comment but I do not see your point ... hopefully we'll have a bit of time in Montreal to discuss if that does not work by email. [dp] my point is that without this additional information you can not achieve the expected result - i pointed to your own text to indicate that this information is a must have in order to achieve this objective using your own words to make it more straighforward - "you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient." b3) at each step there is no PCE that has partial visibility of a given domain This is not specific to BRPC. Even with intra-domain if you want to compute the path for a TE LSP, you cannot always use the PCE if it has a partial visibility. Note that this also applies to the case of co-located PCE (when the path is computed by the head-end). [dp] hence, to BRPC as well b4) during the selection process no network conditions changes (that would make the returned result void) Again, this applies to other cases as well. [dp] ditto Ah so we agree here :-) What was your comment then ? [dp] that you need to include these set of working conditions in the document itself, the document looks like quite simple in terms of conditions for having the proposed method working as expected while when you take a closer look at it this is not the case Thanks. JP. thanks. JP. JP Vasseur 23/06/2006 16:11 To: "Adrian Farrel" cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com Subject: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Many Thanks Adrian for the comments. We incorporated the vast majority of them in the new revision (just posted). See below for the comments requesting some clarification. On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: Hi, Thanks for keeping these ideas alive. Here are some picky thoughts that you may want to include in the next revision to make it more robust as a document. I don't have any issues with the basic process. Thanks, Adrian == Is this I-D likely to be Informational or Standards Track? From Appendix A, this looks like Standards Track. Can you remove Appendix A and put the status in the usual place in the header? == Status has been updated (Informational) but let's discuss this later on. FYI, it does not appear on the front page when using the xml2rfc editor (which by the way is excellent), thus the appendix addition. It would be nice if the Abstract contained a pithy summary of brpc and/or gave the motivation for the draft. For example, what is the method trying to achieve that isn't achievable by other methods? Or, what is the fundamental element of brpc that is not in other methods? Agree. Here is the new Abstract: "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 (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) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths, using a backward recursive path computation technique while fully preserving confidentiality requirements across domains. " == I'm assuming that section 1 is for short term information only and will be deleted (in the next revision?) == Indeed, just to provide a bit of history for the ones who have been following inter-domain path computation for a while. == Section 4 - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple domains. You should clarify what you are saying here, because many would argue that reachability information (i.e. external routes) constitutes topology and resource information. OK fine == Section 4 - While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. Why does the policy agreement need to be offline? It should actually read "pre-determined". Actually the best thing to do here is to remove "off-line" == Section 5 No assumption is made on the actual path computation algorithm in use by the PCE (it can be any variant of CSPF, algorithm based on linear- programming to solve multi-constraints optimization problems and so on). Suggest that you delete the text in parenthesis because it is making suggestions that border on assumptions! Well I'd suggest to keep it as is since the point is to differentiate the path computation procedure from the algorithm to compute each intra- domain path segment. Furthermore, we'd like to highlight the fact that the BRPC procedure does not mandate for each PCE to use CSPF, could be other algorithm. == Section 5.1 and throughout "BRPC path computation" seems to be tautologous It is actually a double tautology ;-) (fixed). == Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." == Section 5.2 The introduction of the term Virtual Shortest Path Tree is hard to parse and to my mind the definition is arse about tit. I think you could usefully add some textual definition of what the VSPT is trying to achieve, before presenting it in pictorial or abstract form. Even more important (I think) is the fact that the tree as presented "represents the shortest path between the destination and BR-en (j,i)..." Frankly, we are building directional paths in exactly the oposite direction! This is an abstract form of representation but see below, So the VSPT is still a tree, but it is an MP2P tree, not a P2MP tree as described. I suspect that this is just a textual descriptive issue rather than anything broken in the process. I clarified the text to avoid any ambiguity (VSPT defined as a MP2P tree). == Section 5.2 I suggest that you pull the note (Note: in term of computation...) out into a separate section. It doesn't belong in the middle of section 5.2. You will probably want to re-write the text as well since the unidirectional limit is not necessary. Also to explain 'flood' - flood to where, and how, and by whom? And you will want to add to pieces of information: - the link to the I-D that defines how to do this - a description of what happens if this process is not used. This only works for unidirectional LSPs: indeed, the exit boundary node can flood TE-related data in its LSA/LSP for the link exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP running on the link but how would a node in domain (i) get the TE-related data for the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on unidirectional link. Are we in sync ? == Section 5.2 The paragraph that begins "BRPC guarantees to find the optimal..." is a nascent Applicability Statement. I suggest moving this to another Section and significantly beefing it up. You need to describe more fully: - how ECMP works (the PCC has to request the return of more than one path) - how diversity works (i.e. section 9 fits in here) - how some freedom of selection of domains can be offered - how to mix the method with other mechanisms This was (and is) planned for future revision. Note that ECMP and diversity are discussed already but we're planning the flesh out these sections in further revision. == Section 7 If the BRPC procedure cannot be completed because a PCE along the domain path does not support the procedure, a PCErr message is returned by the upstream PCE with a Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. Not clear to me whether PCE(n) is supposed to know that PCE(n+1) does not support brpc, presumably through capabilities configuration/advertisement/negotiation, or whether PCE(n+1) is supposed to respond to the path computation request saying that it does not support bit-V of the RP object. If the latter, presumably the PCErr comes from PCE(n+1) and not from PCE(n) as documented. Good catch, typo: it should read "a PCErr message is returned to the upstream". The plan is to define a capability bit (IGP) in a further revision. == Section 8 Metric normalisation is a great potential solution, but how does it fit with AS topology confidentiality? What is the solution to providing discretion about what TE connectivity is available within an AS, and operating brpc? Metric normalization is handled locally by the PCE and does not impact the BRPC procedure per-say. As far as confidentiality is concerned, this only requires for the SPs to exchange metric mapping information (nothing related to the network topology or resources); for example SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 A simple metric normalization can then be performed on the PCE thanks to simple cost mapping tables. Section 10 Some of this text has been seen before in this I-D Why do you single out LSP stitching as possibly breaking end-to-end optimality. There is functionally no difference between stitching and nesting in this respect. But further, your statement about stitching is pejorative! If you say that "In the case where a domain has more than one BR-en or more than one BR-ex, optimality after some network change within the domain can only be guaranteed by re-executing the full brpc computation" then I would agree with you. But as phrased, it implies that making a per-domain re-optimisation could make the path *less* optimal. This (of course) is not the case - per-domain optimisation will always improve or leave the same end-to-end optimality (in the case where new resources are made available this is obvious; in the case of a network failure, *any* path is better than no path!) And, lastly, the text about re-optimisation belongs in the next section, not in this section. Yes I wanted to leave that text to keep track of who would read the ID, expecting reaction ;-)) Per-domain reoptimization would always improve the current path *but* in case of stitched LSPs, TE LSP segments are computed by the stitching point; thus in case of failure, they could end up following a non optimal path whereas in the case of contiguous LSP, the BRPC procedure would be called again thus leading to the optimal path again. The point that I was trying to make is "if you have a stitched LSP and rely on BRPC when first signaled in an attempt to get an optimal path, you need to consider the interaction between the local reopt mode and BRPC if the goal is to preserve an optimal path at any given time". Anyway, we're on the same page and I agree and the text should be reworded according to your proposal to avoid any misunderstanding. == Section 13 I would like you to discuss the issues of confidentiality of topology information at greater length. It seems that you would possibly use this technique in conjunction with path cookies, which is fine. But, are there two things you cannot escape from? - indicating which BR-en provides best connectivity - indicating the metric for multiple BR-ens Maybe there are some things that can be done here based on policy, including not reporting all of the BR-ens, ranking rather than giving absolute metrics, etc. But these would compromise optimality. Indeed. Maybe the PCE(n+1) should carefully monitor and limit (statistically and by policy) brpc requests so that excessive information is not divulged? Since one of objectives for using the BRPC procedure is to compute an optimal path, we need to know at least the BN (Boundary Nodes) and the cost. == I wouldn't mind seeing a Management Considerations section. Do we need to be able to examine the pruned pieces of VSPT at transit PCEs? What are the implications of reporting multiple VSPT branches in PCEP to the MIB modules? Is brpc support something that needs to be configured: per PCE?; per PCE-neighbor? What are the implications on existing protocols (IGPs? PCEP?) of using brpc? Absolutely ! I put a placeholder for a further revision. Fully supportive of adding such section. Many Thanks for your comments ! JP. etc. == I think Jean-Louis' email address needs updating == The document would benefit from a little care in the formatting, and you could usefully re-read it for missing words, etc. == _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 03:04:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ful8t-0004ze-7c; Mon, 26 Jun 2006 03:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ful8s-0004zO-HN for pce@ietf.org; Mon, 26 Jun 2006 03:04:18 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ful8r-0003QE-C5 for pce@ietf.org; Mon, 26 Jun 2006 03:04:18 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 09:03:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 09:03:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Thread-Index: AcaY7PzReUBMvt9eTUSOFY9wmyG/gAAAIfcQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "JP Vasseur" X-OriginalArrivalTime: 26 Jun 2006 07:03:32.0753 (UTC) FILETIME=[A2CBA010:01C698EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, [dp] i read this, mind you, my point is that this is not a "constraint" = of the same nature as the one you're making use such as minimize delays = or whatsover - this constraint is introduced from the computation = technique and mechanism of this proposed method =20 No, this is not introduced from the path computation technique.=20 The AS-path is a constraint of the same nature as link/node inclusion, = this is actually a set of abstract nodes to be included.=20 By the way "minimze the delay" is NOT a constraint, this is an objective = to achieve... Thanks, JL > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : lundi 26 juin 2006 08:51 > =C0 : JP Vasseur > Cc : raymond_zhang@bt.infonet.com; nabil.n.bitar@verizon.com;=20 > pce@ietf.org > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 02:42 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitri, >=20 > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 01:14 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" ,=20 > nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitiri, >=20 > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > the following comment was also discussed during last meeting >=20 > "=3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to=20 > point out that if the sequence of domains is known a priori=20 > (can you determine it a > priori?) then the path computed might not be 'optimal' in the=20 > usual sense of the word, but that this is OK because the=20 > ordered list of domains constitutes an additional constraint=20 > on the computation so the resultant path *is* optimal within=20 > the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of an optimal constrained inter-domain TE LSP.=20 > The sequence of domains to be traversed can either be=20 > determined a priori or during the path computation procedure.=20 > The BRPC procedure guarantees to compute the optimal path=20 > across a specific set of traversed domains (which constitutes=20 > an additional constraint). In the case of an arbitrary set of=20 > meshed domains, the BRPC procedure can be used to compute the=20 > optimal path across each domain set in order to get to=20 > optimal constrained path between the source and the=20 > destination of the TE LSP." >=20 > =3D> in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure (only inter-domain=20 > link selection would be > required) - >=20 > Not correct; even if you know the sequence you still need the=20 > BRPC procedure to figure out the set of BN (boundary Nodes)=20 > to traverse to get the shortest inter-domain TE LSP: this is=20 > the whole issue with inter-domain, otherwise per-domain path=20 > computation would be sufficient. >=20 > [dp] inter-domain link selection (as i mentioned) implies=20 > what you mean with boundary nodes selection - you could=20 > rephrase by access/exit point selection exact same business >=20 > but again even if you know the sequence you still need BRPC=20 > to determine the set of BN (or exit point - same thing) that=20 > will give you the shortest inter-domain path. Look you wrote=20 > "in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure", which is not=20 > correct. Even if you know the sequence of domains, you still=20 > need the procedure to get the exit/entry point (named BN)=20 > that provide you the shortest inter-domain path. >=20 >=20 > now adrian mentions that pre- determination becomes a new=20 > constraint - well actually this is not a constraint for the=20 > TE LSP itself but a restriction on the domain set known to be=20 > (a-priori) supportive of the method such as to make the=20 > method not returning an error message >=20 >=20 > No, this is a constraint: "Give me the shortest path=20 > (potentially made of loose hops (the BNs)) that provides the=20 > shortest end to end path, considering that the additional=20 > constraint is to traverse the following set of domains . >=20 > [dp] incorrect, this is not a "TE LSP" constraint -=20 >=20 > Who said that this was a TE LSP constraint ? This is *a*=20 > constraint. If you impose the set of domain, this is a constraint. >=20 > Please read the text: "The BRPC procedure guarantees to=20 > compute the optimal path across a specific set of traversed=20 > domains (which constitutes an additional constraint)." >=20 > [dp] i read this, mind you, my point is that this is not a=20 > "constraint" of the same nature as the one you're making use=20 > such as minimize delays or whatsover - this constraint is=20 > introduced from the computation technique and mechanism of=20 > this proposed method=20 >=20 > Note that at this point, I still do not see the point that=20 > you're trying to make here ? >=20 > since so far when > a set of domains do not support/or support a given=20 > computation has not yet become a constraint >=20 > hence sentence "The BRPC procedure guarantees to compute the=20 > optimal path across a specific set of traversed domains=20 > (which constitutes an additional constraint). In the case of=20 > an arbitrary set of meshed domains, the BRPC procedure can be=20 > used to compute the optimal path across each domain set in=20 > order to get to optimal constrained path between the source=20 > and the destination of the TE LSP." >=20 > should as far as i understand the method fulfill the following >=20 > a) this method provides a result iff all domains traversed by=20 > the request support the proposed method >=20 > BRPC is a multi-PCE based approach where you need at least=20 > one PCE per-domain. >=20 > [dp] indeed, but one PCE supporting that method and having=20 > FULL visibility of the domain >=20 > So what is your point here ? >=20 > [dp] that the set of conditions to have this method workable=20 > is larger than the one listed in this doc. >=20 > b) this method provides an "optimal" result iff >=20 > b1) all possible sequences of domains have been traversed=20 > (starting from the root) and are supportive of that method -=20 > as there might be an optimal path through a domain not=20 > supporting this method - >=20 >=20 > heu ... yes indeed. If a domain does not support the method,=20 > the method cannot be used to compute the path. >=20 > b2) there is no discontinuity in the availability of the=20 > inter-AS link information on each PCE performing a given=20 > selection - indeed a domain might be supportive of the method=20 > without supporting inter-AS link flooding >=20 > No this is not a requirement, just an optimization. The only=20 > requirement is for the PCE to get the TE-related data about=20 > the Inter- AS links. I'll detail a bit more in the next revision. >=20 > [dp] then you can never achieve - >=20 > You can never achieve what ? >=20 > Sorry Dimitri, I'd love to accommodate your comment but I do=20 > not see your point ... hopefully we'll have a bit of time in=20 > Montreal to discuss if that does not work by email. >=20 > [dp] my point is that without this additional information you=20 > can not achieve the expected result - i pointed to your own=20 > text to indicate that this information is a must have in=20 > order to achieve this objective=20 >=20 > using your own words to make it more > straighforward -=20 >=20 > "you still need the BRPC procedure to figure out the set of=20 > BN (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP:=20 > this is the whole issue with inter-domain, otherwise=20 > per-domain path computation would=20 >=20 > be sufficient." >=20 > b3) at each step there is no PCE that has partial visibility=20 > of a given domain >=20 >=20 > This is not specific to BRPC. Even with intra-domain if you want to=20 > compute the path for a TE LSP, you cannot always use the PCE if it=20 > has a partial visibility. Note that this also applies to the case of=20 > co-located PCE (when the path is computed by the head-end). >=20 > [dp] hence, to BRPC as well >=20 > b4) during the selection process no network conditions changes=20 > (that would > make the returned result void) >=20 >=20 > Again, this applies to other cases as well. >=20 > [dp] ditto >=20 >=20 > Ah so we agree here :-) >=20 > What was your comment then ? >=20 > [dp] that you need to include these set of working conditions in the=20 > document itself, the document looks like quite simple in terms of=20 > conditions for having the proposed method working as expected=20 > while when=20 > you take a closer look at it this is not the case >=20 > Thanks. >=20 > JP. >=20 >=20 >=20 > thanks. >=20 > JP. >=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > 23/06/2006 16:11 >=20 > To: "Adrian Farrel" > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt >=20 >=20 > Many Thanks Adrian for the comments. >=20 > We incorporated the vast majority of them in the new revision (just > posted). >=20 > See below for the comments requesting some clarification. >=20 > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >=20 > Hi, >=20 > Thanks for keeping these ideas alive. >=20 > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. >=20 > Thanks, > Adrian >=20 > =3D=3D > Is this I-D likely to be Informational or Standards Track? From=20 > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > =3D=3D >=20 > Status has been updated (Informational) but let's discuss this=20 > later on. > FYI, it does not appear on the front page when using the xml2rfc=20 > editor > (which by the way is excellent), thus the appendix addition. >=20 > It would be nice if the Abstract contained a pithy summary of brpc=20 > and/or > gave the motivation for the draft. For example, what is the method=20 > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? >=20 > Agree. Here is the new Abstract: > "The ability to compute constrained shortest Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)=20 > and > Generalized MPLS (GMPLS) networks across multiple domains (where a=20 > domain > is referred to as a collection of network elements within a common=20 > sphere > of address management or path computational responsibility such as IGP > areas and Autonomous Systems) has been identified as a key=20 > requirement . > This document specifies a procedure relying on the use of multiple=20 > Path > Computation Elements (PCEs) in order to compute such inter-domain=20 > shortest > constraint paths, using a backward recursive path computation=20 > technique > while fully preserving confidentiality requirements across domains. " >=20 >=20 > =3D=3D > I'm assuming that section 1 is for short term information only and=20 > will be > deleted (in the next revision?) > =3D=3D >=20 > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. >=20 > =3D=3D > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would=20 > argue that > reachability information (i.e. external routes) constitutes=20 > topology and > resource information. >=20 >=20 > OK fine >=20 > =3D=3D > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed=20 > that, at > the domain boundary LSRs, there will exist some sort of local=20 > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? >=20 >=20 > It should actually read "pre-determined". Actually the best thing=20 > to do > here is to remove "off-line" >=20 > =3D=3D > Section 5 > No assumption is made on the actual path computation algorithm in=20 > use > by the PCE (it can be any variant of CSPF, algorithm based on=20 > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! >=20 > Well I'd suggest to keep it as is since the point is to=20 > differentiate the > path computation procedure from the algorithm to compute each intra-=20 > domain > path segment. Furthermore, we'd like to highlight the fact that the=20 > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. >=20 > =3D=3D > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous >=20 > It is actually a double tautology ;-) (fixed). >=20 > =3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point=20 > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual=20 > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the=20 > resultant > path *is* optimal within the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains=20 > to be > traversed can either be determined a priori or during the path=20 > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path=20 > across > each domain set in order to get to optimal constrained path between=20 > the > source and the destination of the TE LSP." >=20 > =3D=3D > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to=20 > parse > and > to my mind the definition is arse about tit. I think you could=20 > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en=20 > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! >=20 > This is an abstract form of representation but see below, >=20 > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP=20 > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. >=20 >=20 > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P=20 > tree). >=20 > =3D=3D > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where,=20 > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. >=20 > This only works for unidirectional LSPs: indeed, the exit boundary=20 > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP=20 > running on > the link but how would a node in domain (i) get the TE-related data=20 > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? >=20 > =3D=3D > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..."=20 > is a > nascent Applicability Statement. I suggest moving this to another=20 > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than=20 > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms >=20 > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. >=20 > =3D=3D > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1)=20 > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is=20 > supposed > to > respond to the path computation request saying that it does not=20 > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. >=20 > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. >=20 > =3D=3D > Section 8 > Metric normalisation is a great potential solution, but how does it=20 > fit > with > AS topology confidentiality? What is the solution to providing=20 > discretion > about what TE connectivity is available within an AS, and operating=20 > brpc? >=20 > Metric normalization is handled locally by the PCE and does not=20 > impact the > BRPC procedure per-say. As far as confidentiality is concerned,=20 > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost =3D F (link_bandwidth) with F (OC192)=3D1 > SP 2 Links Cost =3D F (link_bandwidth) with F (OC192)=3D10 >=20 > A simple metric normalization can then be performed on the PCE=20 > thanks to > simple cost mapping tables. >=20 > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you=20 > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would=20 > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of=20 > course) is > not > the case - per-domain optimisation will always improve or leave the=20 > same > end-to-end optimality (in the case where new resources are made=20 > available > this is obvious; in the case of a network failure, *any* path is=20 > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next=20 > section, > not > in this section. >=20 >=20 > Yes I wanted to leave that text to keep track of who would read the=20 > ID, > expecting reaction ;-)) Per-domain reoptimization would always=20 > improve the > current path *but* in case of stitched LSPs, TE LSP segments are=20 > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP,=20 > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a=20 > stitched LSP > and rely on BRPC when first signaled in an attempt to get an=20 > optimal path, > you need to consider the interaction between the local reopt mode=20 > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. >=20 > =3D=3D > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use=20 > this > technique in conjunction with path cookies, which is fine. But, are=20 > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. >=20 > Indeed. >=20 > Maybe the PCE(n+1) should carefully monitor and limit=20 > (statistically and > by > policy) brpc requests so that excessive information is not divulged? >=20 > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. >=20 > =3D=3D > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in=20 > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? >=20 > Absolutely ! I put a placeholder for a further revision. >=20 > Fully supportive of adding such section. >=20 > Many Thanks for your comments ! >=20 > JP. >=20 > etc. > =3D=3D >=20 >=20 >=20 >=20 >=20 > I think Jean-Louis' email address needs updating >=20 >=20 > =3D=3D > The document would benefit from a little care in the formatting,=20 > and you > could usefully re-read it for missing words, etc. > =3D=3D > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 03:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulNg-0000oS-3f; Mon, 26 Jun 2006 03:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulNe-0000oN-Jf for pce@ietf.org; Mon, 26 Jun 2006 03:19:34 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FulNd-0004Dz-7q for pce@ietf.org; Mon, 26 Jun 2006 03:19:34 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5Q7JLRd021233; Mon, 26 Jun 2006 09:19:21 +0200 In-Reply-To: To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 26 Jun 2006 09:19:26 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/26/2006 09:19:21, Serialize complete at 06/26/2006 09:19:21 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: ff8f6fb66123e35ba88156f838266c1a Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-l=20 "LE ROUX Jean-Louis RD-CORE-LAN" 26/06/2006 09:03 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur"=20 cc: raymond=5Fzhang@bt.infonet.com, pce@ietf.org,=20 nabil.n.bitar@verizon.com Subject: RE: [Pce] Re: Comments on=20 draft-vasseur-pce-brpc-00.txt Hi Dimitri, [dp] i read this, mind you, my point is that this is not a "constraint" of = the same nature as the one you're making use such as minimize delays or=20 whatsover - this constraint is introduced from the computation technique=20 and mechanism of this proposed method=20 No, this is not introduced from the path computation technique.=20 The AS-path is a constraint of the same nature as link/node inclusion,=20 this is actually a set of abstract nodes to be included.=20 [dp] but not for the same reason - isn't it ? - By the way "minimze the delay" is NOT a constraint, this is an objective=20 to achieve... [dp] i meant "maximum/minimize delay"=20 Thanks, JL > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : lundi 26 juin 2006 08:51 > =C0 : JP Vasseur > Cc : raymond=5Fzhang@bt.infonet.com; nabil.n.bitar@verizon.com;=20 > pce@ietf.org > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 02:42 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond=5Fzhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitri, >=20 > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 01:14 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" ,=20 > nabil.n.bitar@verizon.com, pce@ietf.org, raymond=5Fzhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitiri, >=20 > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > the following comment was also discussed during last meeting >=20 > "=3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to=20 > point out that if the sequence of domains is known a priori=20 > (can you determine it a > priori?) then the path computed might not be 'optimal' in the=20 > usual sense of the word, but that this is OK because the=20 > ordered list of domains constitutes an additional constraint=20 > on the computation so the resultant path *is* optimal within=20 > the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of an optimal constrained inter-domain TE LSP.=20 > The sequence of domains to be traversed can either be=20 > determined a priori or during the path computation procedure.=20 > The BRPC procedure guarantees to compute the optimal path=20 > across a specific set of traversed domains (which constitutes=20 > an additional constraint). In the case of an arbitrary set of=20 > meshed domains, the BRPC procedure can be used to compute the=20 > optimal path across each domain set in order to get to=20 > optimal constrained path between the source and the=20 > destination of the TE LSP." >=20 > =3D> in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure (only inter-domain=20 > link selection would be > required) - >=20 > Not correct; even if you know the sequence you still need the=20 > BRPC procedure to figure out the set of BN (boundary Nodes)=20 > to traverse to get the shortest inter-domain TE LSP: this is=20 > the whole issue with inter-domain, otherwise per-domain path=20 > computation would be sufficient. >=20 > [dp] inter-domain link selection (as i mentioned) implies=20 > what you mean with boundary nodes selection - you could=20 > rephrase by access/exit point selection exact same business >=20 > but again even if you know the sequence you still need BRPC=20 > to determine the set of BN (or exit point - same thing) that=20 > will give you the shortest inter-domain path. Look you wrote=20 > "in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure", which is not=20 > correct. Even if you know the sequence of domains, you still=20 > need the procedure to get the exit/entry point (named BN)=20 > that provide you the shortest inter-domain path. >=20 >=20 > now adrian mentions that pre- determination becomes a new=20 > constraint - well actually this is not a constraint for the=20 > TE LSP itself but a restriction on the domain set known to be=20 > (a-priori) supportive of the method such as to make the=20 > method not returning an error message >=20 >=20 > No, this is a constraint: "Give me the shortest path=20 > (potentially made of loose hops (the BNs)) that provides the=20 > shortest end to end path, considering that the additional=20 > constraint is to traverse the following set of domains . >=20 > [dp] incorrect, this is not a "TE LSP" constraint -=20 >=20 > Who said that this was a TE LSP constraint ? This is *a*=20 > constraint. If you impose the set of domain, this is a constraint. >=20 > Please read the text: "The BRPC procedure guarantees to=20 > compute the optimal path across a specific set of traversed=20 > domains (which constitutes an additional constraint)." >=20 > [dp] i read this, mind you, my point is that this is not a=20 > "constraint" of the same nature as the one you're making use=20 > such as minimize delays or whatsover - this constraint is=20 > introduced from the computation technique and mechanism of=20 > this proposed method=20 >=20 > Note that at this point, I still do not see the point that=20 > you're trying to make here ? >=20 > since so far when > a set of domains do not support/or support a given=20 > computation has not yet become a constraint >=20 > hence sentence "The BRPC procedure guarantees to compute the=20 > optimal path across a specific set of traversed domains=20 > (which constitutes an additional constraint). In the case of=20 > an arbitrary set of meshed domains, the BRPC procedure can be=20 > used to compute the optimal path across each domain set in=20 > order to get to optimal constrained path between the source=20 > and the destination of the TE LSP." >=20 > should as far as i understand the method fulfill the following >=20 > a) this method provides a result iff all domains traversed by=20 > the request support the proposed method >=20 > BRPC is a multi-PCE based approach where you need at least=20 > one PCE per-domain. >=20 > [dp] indeed, but one PCE supporting that method and having=20 > FULL visibility of the domain >=20 > So what is your point here ? >=20 > [dp] that the set of conditions to have this method workable=20 > is larger than the one listed in this doc. >=20 > b) this method provides an "optimal" result iff >=20 > b1) all possible sequences of domains have been traversed=20 > (starting from the root) and are supportive of that method -=20 > as there might be an optimal path through a domain not=20 > supporting this method - >=20 >=20 > heu ... yes indeed. If a domain does not support the method,=20 > the method cannot be used to compute the path. >=20 > b2) there is no discontinuity in the availability of the=20 > inter-AS link information on each PCE performing a given=20 > selection - indeed a domain might be supportive of the method=20 > without supporting inter-AS link flooding >=20 > No this is not a requirement, just an optimization. The only=20 > requirement is for the PCE to get the TE-related data about=20 > the Inter- AS links. I'll detail a bit more in the next revision. >=20 > [dp] then you can never achieve - >=20 > You can never achieve what ? >=20 > Sorry Dimitri, I'd love to accommodate your comment but I do=20 > not see your point ... hopefully we'll have a bit of time in=20 > Montreal to discuss if that does not work by email. >=20 > [dp] my point is that without this additional information you=20 > can not achieve the expected result - i pointed to your own=20 > text to indicate that this information is a must have in=20 > order to achieve this objective=20 >=20 > using your own words to make it more > straighforward -=20 >=20 > "you still need the BRPC procedure to figure out the set of=20 > BN (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP:=20 > this is the whole issue with inter-domain, otherwise=20 > per-domain path computation would=20 >=20 > be sufficient." >=20 > b3) at each step there is no PCE that has partial visibility=20 > of a given domain >=20 >=20 > This is not specific to BRPC. Even with intra-domain if you want to=20 > compute the path for a TE LSP, you cannot always use the PCE if it=20 > has a partial visibility. Note that this also applies to the case of=20 > co-located PCE (when the path is computed by the head-end). >=20 > [dp] hence, to BRPC as well >=20 > b4) during the selection process no network conditions changes=20 > (that would > make the returned result void) >=20 >=20 > Again, this applies to other cases as well. >=20 > [dp] ditto >=20 >=20 > Ah so we agree here :-) >=20 > What was your comment then ? >=20 > [dp] that you need to include these set of working conditions in the=20 > document itself, the document looks like quite simple in terms of=20 > conditions for having the proposed method working as expected=20 > while when=20 > you take a closer look at it this is not the case >=20 > Thanks. >=20 > JP. >=20 >=20 >=20 > thanks. >=20 > JP. >=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > 23/06/2006 16:11 >=20 > To: "Adrian Farrel" > cc: raymond=5Fzhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt >=20 >=20 > Many Thanks Adrian for the comments. >=20 > We incorporated the vast majority of them in the new revision (just > posted). >=20 > See below for the comments requesting some clarification. >=20 > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >=20 > Hi, >=20 > Thanks for keeping these ideas alive. >=20 > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. >=20 > Thanks, > Adrian >=20 > =3D=3D > Is this I-D likely to be Informational or Standards Track? From=20 > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > =3D=3D >=20 > Status has been updated (Informational) but let's discuss this=20 > later on. > FYI, it does not appear on the front page when using the xml2rfc=20 > editor > (which by the way is excellent), thus the appendix addition. >=20 > It would be nice if the Abstract contained a pithy summary of brpc=20 > and/or > gave the motivation for the draft. For example, what is the method=20 > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? >=20 > Agree. Here is the new Abstract: > "The ability to compute constrained shortest Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)=20 > and > Generalized MPLS (GMPLS) networks across multiple domains (where a=20 > domain > is referred to as a collection of network elements within a common=20 > sphere > of address management or path computational responsibility such as IGP > areas and Autonomous Systems) has been identified as a key=20 > requirement . > This document specifies a procedure relying on the use of multiple=20 > Path > Computation Elements (PCEs) in order to compute such inter-domain=20 > shortest > constraint paths, using a backward recursive path computation=20 > technique > while fully preserving confidentiality requirements across domains. " >=20 >=20 > =3D=3D > I'm assuming that section 1 is for short term information only and=20 > will be > deleted (in the next revision?) > =3D=3D >=20 > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. >=20 > =3D=3D > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would=20 > argue that > reachability information (i.e. external routes) constitutes=20 > topology and > resource information. >=20 >=20 > OK fine >=20 > =3D=3D > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed=20 > that, at > the domain boundary LSRs, there will exist some sort of local=20 > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? >=20 >=20 > It should actually read "pre-determined". Actually the best thing=20 > to do > here is to remove "off-line" >=20 > =3D=3D > Section 5 > No assumption is made on the actual path computation algorithm in=20 > use > by the PCE (it can be any variant of CSPF, algorithm based on=20 > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! >=20 > Well I'd suggest to keep it as is since the point is to=20 > differentiate the > path computation procedure from the algorithm to compute each intra-=20 > domain > path segment. Furthermore, we'd like to highlight the fact that the=20 > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. >=20 > =3D=3D > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous >=20 > It is actually a double tautology ;-) (fixed). >=20 > =3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point=20 > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual=20 > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the=20 > resultant > path *is* optimal within the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains=20 > to be > traversed can either be determined a priori or during the path=20 > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path=20 > across > each domain set in order to get to optimal constrained path between=20 > the > source and the destination of the TE LSP." >=20 > =3D=3D > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to=20 > parse > and > to my mind the definition is arse about tit. I think you could=20 > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en=20 > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! >=20 > This is an abstract form of representation but see below, >=20 > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP=20 > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. >=20 >=20 > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P=20 > tree). >=20 > =3D=3D > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where,=20 > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. >=20 > This only works for unidirectional LSPs: indeed, the exit boundary=20 > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP=20 > running on > the link but how would a node in domain (i) get the TE-related data=20 > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? >=20 > =3D=3D > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..."=20 > is a > nascent Applicability Statement. I suggest moving this to another=20 > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than=20 > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms >=20 > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. >=20 > =3D=3D > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1)=20 > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is=20 > supposed > to > respond to the path computation request saying that it does not=20 > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. >=20 > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. >=20 > =3D=3D > Section 8 > Metric normalisation is a great potential solution, but how does it=20 > fit > with > AS topology confidentiality? What is the solution to providing=20 > discretion > about what TE connectivity is available within an AS, and operating=20 > brpc? >=20 > Metric normalization is handled locally by the PCE and does not=20 > impact the > BRPC procedure per-say. As far as confidentiality is concerned,=20 > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost =3D F (link=5Fbandwidth) with F (OC192)=3D1 > SP 2 Links Cost =3D F (link=5Fbandwidth) with F (OC192)=3D10 >=20 > A simple metric normalization can then be performed on the PCE=20 > thanks to > simple cost mapping tables. >=20 > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you=20 > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would=20 > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of=20 > course) is > not > the case - per-domain optimisation will always improve or leave the=20 > same > end-to-end optimality (in the case where new resources are made=20 > available > this is obvious; in the case of a network failure, *any* path is=20 > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next=20 > section, > not > in this section. >=20 >=20 > Yes I wanted to leave that text to keep track of who would read the=20 > ID, > expecting reaction ;-)) Per-domain reoptimization would always=20 > improve the > current path *but* in case of stitched LSPs, TE LSP segments are=20 > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP,=20 > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a=20 > stitched LSP > and rely on BRPC when first signaled in an attempt to get an=20 > optimal path, > you need to consider the interaction between the local reopt mode=20 > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. >=20 > =3D=3D > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use=20 > this > technique in conjunction with path cookies, which is fine. But, are=20 > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. >=20 > Indeed. >=20 > Maybe the PCE(n+1) should carefully monitor and limit=20 > (statistically and > by > policy) brpc requests so that excessive information is not divulged? >=20 > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. >=20 > =3D=3D > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in=20 > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? >=20 > Absolutely ! I put a placeholder for a further revision. >=20 > Fully supportive of adding such section. >=20 > Many Thanks for your comments ! >=20 > JP. >=20 > etc. > =3D=3D >=20 >=20 >=20 >=20 >=20 > I think Jean-Louis' email address needs updating >=20 >=20 > =3D=3D > The document would benefit from a little care in the formatting,=20 > and you > could usefully re-read it for missing words, etc. > =3D=3D > =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 > =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 >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 03:20:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulOw-0001CR-Js; Mon, 26 Jun 2006 03:20:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FulOv-0001CM-4h for pce@ietf.org; Mon, 26 Jun 2006 03:20:53 -0400 Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FulOu-0004Gv-3S for pce@ietf.org; Mon, 26 Jun 2006 03:20:53 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5Q7Kf6j023289; Mon, 26 Jun 2006 09:20:41 +0200 To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 26 Jun 2006 09:20:45 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/26/2006 09:20:41, Serialize complete at 06/26/2006 09:20:41 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: c6d4566aad1fef50f784fa8a77ccada7 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-l=20 "LE ROUX Jean-Louis RD-CORE-LAN" 26/06/2006 09:03 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur"=20 cc: raymond=5Fzhang@bt.infonet.com, pce@ietf.org,=20 nabil.n.bitar@verizon.com Subject: RE: [Pce] Re: Comments on=20 draft-vasseur-pce-brpc-00.txt Hi Dimitri, [dp] i read this, mind you, my point is that this is not a "constraint" of = the same nature as the one you're making use such as minimize delays or=20 whatsover - this constraint is introduced from the computation technique=20 and mechanism of this proposed method=20 No, this is not introduced from the path computation technique.=20 The AS-path is a constraint of the same nature as link/node inclusion,=20 this is actually a set of abstract nodes to be included.=20 [dp] but not for the same reason - isn't it ? - By the way "minimze the delay" is NOT a constraint, this is an objective=20 to achieve... [dp] i meant "maximum/minimize delay" read "maximum/minimum delay"=20 (decidemment ;-)=20 Thanks, JL > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : lundi 26 juin 2006 08:51 > =C0 : JP Vasseur > Cc : raymond=5Fzhang@bt.infonet.com; nabil.n.bitar@verizon.com;=20 > pce@ietf.org > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 02:42 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond=5Fzhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitri, >=20 > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 01:14 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" ,=20 > nabil.n.bitar@verizon.com, pce@ietf.org, raymond=5Fzhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitiri, >=20 > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > the following comment was also discussed during last meeting >=20 > "=3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to=20 > point out that if the sequence of domains is known a priori=20 > (can you determine it a > priori?) then the path computed might not be 'optimal' in the=20 > usual sense of the word, but that this is OK because the=20 > ordered list of domains constitutes an additional constraint=20 > on the computation so the resultant path *is* optimal within=20 > the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of an optimal constrained inter-domain TE LSP.=20 > The sequence of domains to be traversed can either be=20 > determined a priori or during the path computation procedure.=20 > The BRPC procedure guarantees to compute the optimal path=20 > across a specific set of traversed domains (which constitutes=20 > an additional constraint). In the case of an arbitrary set of=20 > meshed domains, the BRPC procedure can be used to compute the=20 > optimal path across each domain set in order to get to=20 > optimal constrained path between the source and the=20 > destination of the TE LSP." >=20 > =3D> in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure (only inter-domain=20 > link selection would be > required) - >=20 > Not correct; even if you know the sequence you still need the=20 > BRPC procedure to figure out the set of BN (boundary Nodes)=20 > to traverse to get the shortest inter-domain TE LSP: this is=20 > the whole issue with inter-domain, otherwise per-domain path=20 > computation would be sufficient. >=20 > [dp] inter-domain link selection (as i mentioned) implies=20 > what you mean with boundary nodes selection - you could=20 > rephrase by access/exit point selection exact same business >=20 > but again even if you know the sequence you still need BRPC=20 > to determine the set of BN (or exit point - same thing) that=20 > will give you the shortest inter-domain path. Look you wrote=20 > "in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure", which is not=20 > correct. Even if you know the sequence of domains, you still=20 > need the procedure to get the exit/entry point (named BN)=20 > that provide you the shortest inter-domain path. >=20 >=20 > now adrian mentions that pre- determination becomes a new=20 > constraint - well actually this is not a constraint for the=20 > TE LSP itself but a restriction on the domain set known to be=20 > (a-priori) supportive of the method such as to make the=20 > method not returning an error message >=20 >=20 > No, this is a constraint: "Give me the shortest path=20 > (potentially made of loose hops (the BNs)) that provides the=20 > shortest end to end path, considering that the additional=20 > constraint is to traverse the following set of domains . >=20 > [dp] incorrect, this is not a "TE LSP" constraint -=20 >=20 > Who said that this was a TE LSP constraint ? This is *a*=20 > constraint. If you impose the set of domain, this is a constraint. >=20 > Please read the text: "The BRPC procedure guarantees to=20 > compute the optimal path across a specific set of traversed=20 > domains (which constitutes an additional constraint)." >=20 > [dp] i read this, mind you, my point is that this is not a=20 > "constraint" of the same nature as the one you're making use=20 > such as minimize delays or whatsover - this constraint is=20 > introduced from the computation technique and mechanism of=20 > this proposed method=20 >=20 > Note that at this point, I still do not see the point that=20 > you're trying to make here ? >=20 > since so far when > a set of domains do not support/or support a given=20 > computation has not yet become a constraint >=20 > hence sentence "The BRPC procedure guarantees to compute the=20 > optimal path across a specific set of traversed domains=20 > (which constitutes an additional constraint). In the case of=20 > an arbitrary set of meshed domains, the BRPC procedure can be=20 > used to compute the optimal path across each domain set in=20 > order to get to optimal constrained path between the source=20 > and the destination of the TE LSP." >=20 > should as far as i understand the method fulfill the following >=20 > a) this method provides a result iff all domains traversed by=20 > the request support the proposed method >=20 > BRPC is a multi-PCE based approach where you need at least=20 > one PCE per-domain. >=20 > [dp] indeed, but one PCE supporting that method and having=20 > FULL visibility of the domain >=20 > So what is your point here ? >=20 > [dp] that the set of conditions to have this method workable=20 > is larger than the one listed in this doc. >=20 > b) this method provides an "optimal" result iff >=20 > b1) all possible sequences of domains have been traversed=20 > (starting from the root) and are supportive of that method -=20 > as there might be an optimal path through a domain not=20 > supporting this method - >=20 >=20 > heu ... yes indeed. If a domain does not support the method,=20 > the method cannot be used to compute the path. >=20 > b2) there is no discontinuity in the availability of the=20 > inter-AS link information on each PCE performing a given=20 > selection - indeed a domain might be supportive of the method=20 > without supporting inter-AS link flooding >=20 > No this is not a requirement, just an optimization. The only=20 > requirement is for the PCE to get the TE-related data about=20 > the Inter- AS links. I'll detail a bit more in the next revision. >=20 > [dp] then you can never achieve - >=20 > You can never achieve what ? >=20 > Sorry Dimitri, I'd love to accommodate your comment but I do=20 > not see your point ... hopefully we'll have a bit of time in=20 > Montreal to discuss if that does not work by email. >=20 > [dp] my point is that without this additional information you=20 > can not achieve the expected result - i pointed to your own=20 > text to indicate that this information is a must have in=20 > order to achieve this objective=20 >=20 > using your own words to make it more > straighforward -=20 >=20 > "you still need the BRPC procedure to figure out the set of=20 > BN (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP:=20 > this is the whole issue with inter-domain, otherwise=20 > per-domain path computation would=20 >=20 > be sufficient." >=20 > b3) at each step there is no PCE that has partial visibility=20 > of a given domain >=20 >=20 > This is not specific to BRPC. Even with intra-domain if you want to=20 > compute the path for a TE LSP, you cannot always use the PCE if it=20 > has a partial visibility. Note that this also applies to the case of=20 > co-located PCE (when the path is computed by the head-end). >=20 > [dp] hence, to BRPC as well >=20 > b4) during the selection process no network conditions changes=20 > (that would > make the returned result void) >=20 >=20 > Again, this applies to other cases as well. >=20 > [dp] ditto >=20 >=20 > Ah so we agree here :-) >=20 > What was your comment then ? >=20 > [dp] that you need to include these set of working conditions in the=20 > document itself, the document looks like quite simple in terms of=20 > conditions for having the proposed method working as expected=20 > while when=20 > you take a closer look at it this is not the case >=20 > Thanks. >=20 > JP. >=20 >=20 >=20 > thanks. >=20 > JP. >=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > 23/06/2006 16:11 >=20 > To: "Adrian Farrel" > cc: raymond=5Fzhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt >=20 >=20 > Many Thanks Adrian for the comments. >=20 > We incorporated the vast majority of them in the new revision (just > posted). >=20 > See below for the comments requesting some clarification. >=20 > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >=20 > Hi, >=20 > Thanks for keeping these ideas alive. >=20 > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. >=20 > Thanks, > Adrian >=20 > =3D=3D > Is this I-D likely to be Informational or Standards Track? From=20 > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > =3D=3D >=20 > Status has been updated (Informational) but let's discuss this=20 > later on. > FYI, it does not appear on the front page when using the xml2rfc=20 > editor > (which by the way is excellent), thus the appendix addition. >=20 > It would be nice if the Abstract contained a pithy summary of brpc=20 > and/or > gave the motivation for the draft. For example, what is the method=20 > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? >=20 > Agree. Here is the new Abstract: > "The ability to compute constrained shortest Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)=20 > and > Generalized MPLS (GMPLS) networks across multiple domains (where a=20 > domain > is referred to as a collection of network elements within a common=20 > sphere > of address management or path computational responsibility such as IGP > areas and Autonomous Systems) has been identified as a key=20 > requirement . > This document specifies a procedure relying on the use of multiple=20 > Path > Computation Elements (PCEs) in order to compute such inter-domain=20 > shortest > constraint paths, using a backward recursive path computation=20 > technique > while fully preserving confidentiality requirements across domains. " >=20 >=20 > =3D=3D > I'm assuming that section 1 is for short term information only and=20 > will be > deleted (in the next revision?) > =3D=3D >=20 > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. >=20 > =3D=3D > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would=20 > argue that > reachability information (i.e. external routes) constitutes=20 > topology and > resource information. >=20 >=20 > OK fine >=20 > =3D=3D > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed=20 > that, at > the domain boundary LSRs, there will exist some sort of local=20 > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? >=20 >=20 > It should actually read "pre-determined". Actually the best thing=20 > to do > here is to remove "off-line" >=20 > =3D=3D > Section 5 > No assumption is made on the actual path computation algorithm in=20 > use > by the PCE (it can be any variant of CSPF, algorithm based on=20 > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! >=20 > Well I'd suggest to keep it as is since the point is to=20 > differentiate the > path computation procedure from the algorithm to compute each intra-=20 > domain > path segment. Furthermore, we'd like to highlight the fact that the=20 > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. >=20 > =3D=3D > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous >=20 > It is actually a double tautology ;-) (fixed). >=20 > =3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point=20 > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual=20 > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the=20 > resultant > path *is* optimal within the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains=20 > to be > traversed can either be determined a priori or during the path=20 > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path=20 > across > each domain set in order to get to optimal constrained path between=20 > the > source and the destination of the TE LSP." >=20 > =3D=3D > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to=20 > parse > and > to my mind the definition is arse about tit. I think you could=20 > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en=20 > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! >=20 > This is an abstract form of representation but see below, >=20 > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP=20 > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. >=20 >=20 > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P=20 > tree). >=20 > =3D=3D > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where,=20 > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. >=20 > This only works for unidirectional LSPs: indeed, the exit boundary=20 > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP=20 > running on > the link but how would a node in domain (i) get the TE-related data=20 > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? >=20 > =3D=3D > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..."=20 > is a > nascent Applicability Statement. I suggest moving this to another=20 > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than=20 > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms >=20 > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. >=20 > =3D=3D > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1)=20 > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is=20 > supposed > to > respond to the path computation request saying that it does not=20 > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. >=20 > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. >=20 > =3D=3D > Section 8 > Metric normalisation is a great potential solution, but how does it=20 > fit > with > AS topology confidentiality? What is the solution to providing=20 > discretion > about what TE connectivity is available within an AS, and operating=20 > brpc? >=20 > Metric normalization is handled locally by the PCE and does not=20 > impact the > BRPC procedure per-say. As far as confidentiality is concerned,=20 > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost =3D F (link=5Fbandwidth) with F (OC192)=3D1 > SP 2 Links Cost =3D F (link=5Fbandwidth) with F (OC192)=3D10 >=20 > A simple metric normalization can then be performed on the PCE=20 > thanks to > simple cost mapping tables. >=20 > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you=20 > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would=20 > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of=20 > course) is > not > the case - per-domain optimisation will always improve or leave the=20 > same > end-to-end optimality (in the case where new resources are made=20 > available > this is obvious; in the case of a network failure, *any* path is=20 > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next=20 > section, > not > in this section. >=20 >=20 > Yes I wanted to leave that text to keep track of who would read the=20 > ID, > expecting reaction ;-)) Per-domain reoptimization would always=20 > improve the > current path *but* in case of stitched LSPs, TE LSP segments are=20 > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP,=20 > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a=20 > stitched LSP > and rely on BRPC when first signaled in an attempt to get an=20 > optimal path, > you need to consider the interaction between the local reopt mode=20 > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. >=20 > =3D=3D > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use=20 > this > technique in conjunction with path cookies, which is fine. But, are=20 > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. >=20 > Indeed. >=20 > Maybe the PCE(n+1) should carefully monitor and limit=20 > (statistically and > by > policy) brpc requests so that excessive information is not divulged? >=20 > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. >=20 > =3D=3D > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in=20 > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? >=20 > Absolutely ! I put a placeholder for a further revision. >=20 > Fully supportive of adding such section. >=20 > Many Thanks for your comments ! >=20 > JP. >=20 > etc. > =3D=3D >=20 >=20 >=20 >=20 >=20 > I think Jean-Louis' email address needs updating >=20 >=20 > =3D=3D > The document would benefit from a little care in the formatting,=20 > and you > could usefully re-read it for missing words, etc. > =3D=3D > =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 > =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 >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 09:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqiD-0000oW-Nb; Mon, 26 Jun 2006 09:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuqd4-0006rr-Rl for pce@ietf.org; Mon, 26 Jun 2006 08:55:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuqcv-0005eR-PM for pce@ietf.org; Mon, 26 Jun 2006 08:55:50 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Jun 2006 05:55:09 -0700 X-BrightmailFiltered: true X-IronPort-AV: i="4.06,175,1149490800"; d="scan'208,217"; a="30469096:sNHT87528674944" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5QCsjnu004423; Mon, 26 Jun 2006 08:55:08 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 08:54:54 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 08:54:49 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <08BBCE0D-BD0E-4D1D-A924-6C8D22ECC5EF@cisco.com> From: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 08:54:47 -0400 To: Dimitri.Papadimitriou@alcatel.be X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 26 Jun 2006 12:54:49.0625 (UTC) FILETIME=[B5971090:01C6991F] X-Spam-Score: 0.5 (/) X-Scan-Signature: 67e47d348da5eb56fc4a4f9c0b1831e6 X-Mailman-Approved-At: Mon, 26 Jun 2006 09:01:08 -0400 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0245048820==" Errors-To: pce-bounces@lists.ietf.org --===============0245048820== Content-Type: multipart/alternative; boundary=Apple-Mail-34--926887836 --Apple-Mail-34--926887836 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed hi, ok so to summarize there was no technical feed-back just a few editorial comments. You'd like to add to the following to the document: 1) The set of traversed domains has to be known and according to you this is not a constraint. I think that the current text is quite clear: "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint)." Now if you want to reword a bit to avoid using the word "constraint" although this *is* a constraint, this is no big deal. Actually, interestingly enough there are quite a few cases where there's only one single set of traversed domains. 2) We need at least one PCE per domain Sounds quite obvious but I have no problem adding this. Actually we're planning in the next revision to elaborate a little bit on the inter-As link flooding (again this is not a requirement but an optimization) but this will be covered. JP. On Jun 26, 2006, at 2:51 AM, Dimitri.Papadimitriou@alcatel.be wrote: > hi j-p - see in-line > > > > > JP Vasseur > 26/06/2006 02:42 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org, > raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > hi dimitri, > > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > hi j-p - see in-line > > > > > JP Vasseur > 26/06/2006 01:14 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" , > nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > hi dimitiri, > > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > the following comment was also discussed during last meeting > > "== > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > => in brief, how to determine the sequence through which path > computation > has to be performed because if this sequence was known there is no > need > for such procedure (only inter-domain link selection would be > required) - > > Not correct; even if you know the sequence you still need the BRPC > procedure to figure out the set of BN (boundary Nodes) to traverse to > get the shortest inter-domain TE LSP: this is the whole issue with > inter-domain, otherwise per-domain path computation would be > sufficient. > > [dp] inter-domain link selection (as i mentioned) implies what you > mean > with boundary nodes selection - you could rephrase by access/exit > point > selection exact same business > > but again even if you know the sequence you still need BRPC to > determine > the set of BN (or exit point - same thing) that will give you the > shortest > inter-domain path. Look you wrote "in brief, how to determine the > sequence > through which path computation has to be performed because if this > sequence was known there is no need for such procedure", which is not > correct. Even if you know the sequence of domains, you still need the > procedure to get the exit/entry point (named BN) that provide you the > shortest inter-domain path. > > > now adrian mentions that pre- determination becomes a new constraint - > well actually this is not a constraint for the TE LSP itself but a > restriction on the domain set known to be (a-priori) supportive of the > method such as to make the method not returning an error message > > > No, this is a constraint: "Give me the shortest path (potentially > made of loose hops (the BNs)) that provides the shortest end to end > path, considering that the additional constraint is to traverse the > following set of domains . > > [dp] incorrect, this is not a "TE LSP" constraint - > > Who said that this was a TE LSP constraint ? This is *a* > constraint. If > you impose the set of domain, this is a constraint. > > Please read the text: "The BRPC procedure guarantees to compute the > optimal path across a specific set of traversed domains (which > constitutes > an additional constraint)." > > [dp] i read this, mind you, my point is that this is not a > "constraint" of > the same nature as the one you're making use such as minimize > delays or > whatsover - this constraint is introduced from the computation > technique > and mechanism of this proposed method > > Note that at this point, I still do not see the point that you're > trying > to make here ? > > since so far when > a set of domains do not support/or support a given computation has not > yet become a constraint > > hence sentence "The BRPC procedure guarantees to compute the > optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > should as far as i understand the method fulfill the following > > a) this method provides a result iff all domains traversed by the > request > support the proposed method > > BRPC is a multi-PCE based approach where you need at least one PCE > per-domain. > > [dp] indeed, but one PCE supporting that method and having FULL > visibility of the domain > > So what is your point here ? > > [dp] that the set of conditions to have this method workable is larger > than the one listed in this doc. > > b) this method provides an "optimal" result iff > > b1) all possible sequences of domains have been traversed (starting > from > the root) and are supportive of that method - as there might be an > optimal > path through a domain not supporting this method - > > > heu ... yes indeed. If a domain does not support the method, the > method cannot be used to compute the path. > > b2) there is no discontinuity in the availability of the inter-AS link > information on each PCE performing a given selection - indeed a domain > might be supportive of the method without supporting inter-AS link > flooding > > No this is not a requirement, just an optimization. The only > requirement is for the PCE to get the TE-related data about the Inter- > AS links. I'll detail a bit more in the next revision. > > [dp] then you can never achieve - > > You can never achieve what ? > > Sorry Dimitri, I'd love to accommodate your comment but I do not > see your > point ... hopefully we'll have a bit of time in Montreal to discuss if > that does not work by email. > > [dp] my point is that without this additional information you can not > achieve the expected result - i pointed to your own text to > indicate that > this information is a must have in order to achieve this objective > > using your own words to make it more > straighforward - > > "you still need the BRPC procedure to figure out the set of BN > (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP: this is > the > whole issue with inter-domain, otherwise per-domain path computation > would > > be sufficient." > > b3) at each step there is no PCE that has partial visibility of a > given > domain > > > This is not specific to BRPC. Even with intra-domain if you want to > compute the path for a TE LSP, you cannot always use the PCE if it > has a partial visibility. Note that this also applies to the case of > co-located PCE (when the path is computed by the head-end). > > [dp] hence, to BRPC as well > > b4) during the selection process no network conditions changes > (that would > make the returned result void) > > > Again, this applies to other cases as well. > > [dp] ditto > > > Ah so we agree here :-) > > What was your comment then ? > > [dp] that you need to include these set of working conditions in the > document itself, the document looks like quite simple in terms of > conditions for having the proposed method working as expected while > when > you take a closer look at it this is not the case > > Thanks. > > JP. > > > > thanks. > > JP. > > > > > > > JP Vasseur > 23/06/2006 16:11 > > To: "Adrian Farrel" > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > Many Thanks Adrian for the comments. > > We incorporated the vast majority of them in the new revision (just > posted). > > See below for the comments requesting some clarification. > > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > > Hi, > > Thanks for keeping these ideas alive. > > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. > > Thanks, > Adrian > > == > Is this I-D likely to be Informational or Standards Track? From > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > == > > Status has been updated (Informational) but let's discuss this > later on. > FYI, it does not appear on the front page when using the xml2rfc > editor > (which by the way is excellent), thus the appendix addition. > > It would be nice if the Abstract contained a pithy summary of brpc > and/or > gave the motivation for the draft. For example, what is the method > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? > > Agree. Here is the new Abstract: > "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 (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) has been identified as a key > requirement . > This document specifies a procedure relying on the use of multiple > Path > Computation Elements (PCEs) in order to compute such inter-domain > shortest > constraint paths, using a backward recursive path computation > technique > while fully preserving confidentiality requirements across domains. " > > > == > I'm assuming that section 1 is for short term information only and > will be > deleted (in the next revision?) > == > > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. > > == > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would > argue that > reachability information (i.e. external routes) constitutes > topology and > resource information. > > > OK fine > > == > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed > that, at > the domain boundary LSRs, there will exist some sort of local > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? > > > It should actually read "pre-determined". Actually the best thing > to do > here is to remove "off-line" > > == > Section 5 > No assumption is made on the actual path computation algorithm in > use > by the PCE (it can be any variant of CSPF, algorithm based on > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! > > Well I'd suggest to keep it as is since the point is to > differentiate the > path computation procedure from the algorithm to compute each intra- > domain > path segment. Furthermore, we'd like to highlight the fact that the > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. > > == > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous > > It is actually a double tautology ;-) (fixed). > > == > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > == > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to > parse > and > to my mind the definition is arse about tit. I think you could > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! > > This is an abstract form of representation but see below, > > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. > > > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P > tree). > > == > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where, > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. > > This only works for unidirectional LSPs: indeed, the exit boundary > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP > running on > the link but how would a node in domain (i) get the TE-related data > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? > > == > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..." > is a > nascent Applicability Statement. I suggest moving this to another > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms > > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. > > == > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is > supposed > to > respond to the path computation request saying that it does not > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. > > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. > > == > Section 8 > Metric normalisation is a great potential solution, but how does it > fit > with > AS topology confidentiality? What is the solution to providing > discretion > about what TE connectivity is available within an AS, and operating > brpc? > > Metric normalization is handled locally by the PCE and does not > impact the > BRPC procedure per-say. As far as confidentiality is concerned, > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 > SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 > > A simple metric normalization can then be performed on the PCE > thanks to > simple cost mapping tables. > > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of > course) is > not > the case - per-domain optimisation will always improve or leave the > same > end-to-end optimality (in the case where new resources are made > available > this is obvious; in the case of a network failure, *any* path is > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next > section, > not > in this section. > > > Yes I wanted to leave that text to keep track of who would read the > ID, > expecting reaction ;-)) Per-domain reoptimization would always > improve the > current path *but* in case of stitched LSPs, TE LSP segments are > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP, > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a > stitched LSP > and rely on BRPC when first signaled in an attempt to get an > optimal path, > you need to consider the interaction between the local reopt mode > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. > > == > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use > this > technique in conjunction with path cookies, which is fine. But, are > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. > > Indeed. > > Maybe the PCE(n+1) should carefully monitor and limit > (statistically and > by > policy) brpc requests so that excessive information is not divulged? > > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. > > == > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? > > Absolutely ! I put a placeholder for a further revision. > > Fully supportive of adding such section. > > Many Thanks for your comments ! > > JP. > > etc. > == > > > > > > I think Jean-Louis' email address needs updating > > > == > The document would benefit from a little care in the formatting, > and you > could usefully re-read it for missing words, etc. > == > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-34--926887836 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 hi,

ok so to summarize there = was no technical feed-back just a few editorial comments.=A0
You'd like to add to the = following to the document:
1) The set of traversed domains has = to be known and according to you this is not a constraint.
I = think that the current text is quite clear:
"The BRPC = procedure guarantees to compute the optimal path across a specific set = of traversed domains (which constitutes an additional = constraint)."
Now if you want to reword a bit to avoid = using the word "constraint" although this *is* a constraint, this is no = big deal.

Actually, interestingly = enough there are quite a few cases where there's only one single set of = traversed domains.

2) We need at least one PCE = per domain
Sounds quite obvious but I have no problem adding = this. Actually we're planning in the next revision to elaborate a little = bit on the inter-As link flooding (again this is not a requirement but = an optimization) but this will be covered.

JP.

O= n Jun 26, 2006, at 2:51 AM, Dimitri.Papadimitriou@alc= atel.be wrote:

hi j-p - see in-line




JP = Vasseur <jvasseur@cisco.com>
26/06/2006 02:42

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 nabil.n.bitar@verizon.com, = pce@ietf.org,=A0



hi j-p - see in-line




JP Vasseur <jvasseur@cisco.com>
26/06/2006 01:14

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>,=A0



the following comment was also = discussed during last meeting

"=3D=3D
Section 5.1
I like the = simplicity of section 5.1, but I think you need to point=A0
that
if the sequence of domains is known a priori (can = you determine it a
priori?) then the path = computed might not be 'optimal' in the usual=A0
of
the = word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the = computation so the=A0
resultant
path *is* = optimal within the constraints applied.

Can't agree = more. Good suggestion, thanks.

Updated text: "The PCE-based = BRPC procedure applies to the=A0
an optimal constrained = inter-domain TE LSP. The sequence of domains=A0
to = be
traversed can either be determined a priori or = during the path=A0
computation
procedure. = The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which = constitutes
an additional constraint). In = the case of an arbitrary set of meshed
domains, = the BRPC procedure can be used to compute the optimal path=A0
each domain set in order to get = to optimal constrained path between=A0
source and the destination of = the TE LSP."

=3D> in brief, how to determine the sequence = through which path=A0
computation
has to be = performed because if this sequence was known there is no=A0
for such procedure (only = inter-domain link selection would be=A0

Not correct; even if you know the sequence you still = need the BRPC=A0
procedure to figure out the set of BN (boundary = Nodes) to traverse to=A0
get the = shortest inter-domain TE LSP: this is the whole issue with=A0

[dp] inter-domain link selection (as i mentioned) = implies what you mean=A0
with = boundary nodes selection - you could rephrase by access/exit point=A0

but again even if you know the = sequence you still need BRPC to determine=A0
the set = of BN (or exit point - same thing) that will give you the shortest=A0
=A0
through which path computation has to be performed = because if this=A0
sequence was known there is no need for such = procedure", which is not=A0
correct. = Even if you know the sequence of domains, you still need the=A0
=A0
shortest inter-domain path.


now adrian = mentions that pre- determination becomes a new constraint -
well actually this is not a constraint for the TE = LSP itself but a
restriction on the domain set = known to be (a-priori) supportive of the
method = such as to make the method not returning an error message


No, this is a = constraint: "Give me the shortest path (potentially=A0
made of = loose hops (the BNs)) that provides the shortest end to end=A0
path, = considering that the additional constraint is to traverse the=A0

[dp] = incorrect, this is not a "TE LSP" constraint -=A0

Who said that = this was a TE LSP constraint ? This is *a* constraint. If=A0
you = impose the set of domain, this is a constraint.

Please = read the text: "The BRPC procedure guarantees to compute the=A0
optimal = path across a specific set of traversed domains (which constitutes=A0
an = additional constraint)."

[dp] i read this, mind you, my = point is that this is not a "constraint" of=A0
the same = nature as the one you're making use such as minimize delays or=A0
=A0
and mechanism of this proposed method=A0

Note that at = this point, I still do not see the point that you're trying=A0
to make = here ?

since so far when
a set of = domains do not support/or support a given computation has not
yet become a constraint

hence = sentence "The BRPC procedure guarantees to compute the=A0
optimal = path
across a specific set of = traversed domains (which constitutes
an additional = constraint). In the case of an arbitrary set of meshed
domains, the BRPC procedure can be used to compute = the optimal path=A0
across
each domain = set in order to get to optimal constrained path between=A0
source and the destination of = the TE LSP."

should as far as i understand the method fulfill the = following

a) this method provides a result iff all domains = traversed by the=A0
request
support the = proposed method

BRPC is a multi-PCE based approach where you need at = least one PCE=A0
per-domain.

[dp] indeed, but one PCE = supporting that method and having FULL=A0

So what is your point here = ?

[dp] that the set of conditions to have this method = workable is larger=A0
than the one listed in this doc.

b) this = method provides an "optimal" result iff

b1) all = possible sequences of domains have been traversed (starting=A0
the root) and are supportive of = that method - as there might be an=A0
path through a domain not = supporting this method -


heu ... yes indeed. If a domain does not support the = method, the=A0
method cannot be used to compute the path.

b2) = there is no discontinuity in the availability of the inter-AS = link
information on each PCE = performing a given selection - indeed a domain
might be supportive of the method without supporting = inter-AS link
flooding

No this = is not a requirement, just an optimization. The only=A0
=A0
AS links. I'll detail a bit more in the next = revision.

[dp] then you can never achieve -

You can = never achieve what ?
Sorry Dimitri, I'd love to = accommodate your comment but I do not see your=A0
point = ... hopefully we'll have a bit of time in Montreal to discuss if=A0
that = does not work by email.

[dp] my point is that without = this additional information you can not=A0
achieve = the expected result - i pointed to your own text to indicate that=A0
this = information is a must have in order to achieve this objective=A0

using your = own words to make it more
=A0

"you = still need the BRPC procedure to figure out the set of BN (boundary=A0
Nodes) = to traverse to get the shortest inter-domain TE LSP: this is the=A0
whole = issue with inter-domain, otherwise per-domain path computation=A0
=A0

be = sufficient."

b3) at each step there is no PCE that has partial = visibility of a=A0
given


This is = not specific to BRPC. Even with intra-domain if you want to=A0
compute = the path for a TE LSP, you cannot always use the PCE if it=A0
has a = partial visibility. Note that this also applies to the case of=A0

[dp] = hence, to BRPC as well
b4) during the selection process = no network conditions changes=A0
(that = would
make the returned result = void)


Again, = this applies to other cases as well.

[dp] ditto


Ah so we = agree here :-)

What was your comment then ?

[dp] = that you need to include these set of working conditions in the=A0
document = itself, the document looks like quite simple in terms of=A0
=A0
you take a closer look at it this is not the = case

Thanks.

JP.



thanks.

JP.






JP Vasseur <jvasseur@cisco.com>
23/06/2006 16:11

=A0 =A0 =A0 =A0 To: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>
nabil.n.bitar@verizon.com
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = [Pce] Re: Comments on


Many Thanks Adrian for the comments.

We = incorporated the vast majority of them in the new revision = (just
posted).

See = below for the comments requesting some clarification.

On Jun = 10, 2006, at 8:49 AM, Adrian Farrel wrote:

Hi,

Thanks = for keeping these ideas alive.

Here are some picky thoughts = that you may want to include in the next
revision = to make it more robust as a document. I don't have any issues
with
the basic = process.

Thanks,

=3D=3D
Is this I-D = likely to be Informational or Standards Track? From=A0
A,
this = looks like Standards Track. Can you remove Appendix A and put = the
status in the usual place in the = header?
=3D=3D

Status = has been updated (Informational) but let's discuss this=A0
later = on.
FYI, it does not appear on the = front page when using the xml2rfc=A0
(which by the way is excellent), = thus the appendix addition.

It would be nice if the Abstract = contained a pithy summary of brpc=A0
gave the motivation for the = draft. For example, what is the method=A0
to
achieve = that isn't achievable by other methods? Or, what is the
fundamental
element of = brpc that is not in other methods?

Agree. Here is the new = Abstract:
"The ability to compute = constrained shortest Traffic Engineering (TE)
Label Switched Paths (LSPs) in Multiprotocol Label = Switching (MPLS)=A0
and
Generalized = MPLS (GMPLS) networks across multiple domains (where a=A0
is referred to as a collection = of network elements within a common=A0
of address management or path = computational responsibility such as IGP
areas = and Autonomous Systems) has been identified as a key=A0
This document specifies a = procedure relying on the use of multiple=A0
Computation Elements (PCEs) in = order to compute such inter-domain=A0
constraint paths, using a = backward recursive path computation=A0
while fully preserving = confidentiality requirements across domains. "


=3D=3D
I'm assuming that section 1 is for short term = information only and=A0
will = be
deleted (in the next revision?)
=3D=3D

Indeed, just to provide a bit of = history for the ones who have been
following = inter-domain path computation for a while.

=3D=3D
Section 4
=A0 - No topology or resource = information is distributed between domains
=A0 (as mandated per [RFC4105] = and [RFC4216]), which is critical to
=A0 preserve IGP/BGP scalability = and confidentiality in the case of TE
=A0 LSPs spanning multiple = domains.
You should clarify what you are = saying here, because many would=A0
argue = that
reachability information (i.e. = external routes) constitutes=A0
topology = and
resource information.


OK = fine

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

It should actually read "pre-determined". Actually = the best thing=A0
to do
here is to = remove "off-line"

=3D=3D
Section = 5
=A0 = No assumption is made on the actual path computation algorithm = in=A0
use
=A0 by the PCE (it can be any = variant of CSPF, algorithm based on=A0
=A0 programming to solve = multi-constraints optimization problems and so
=A0 = on).
Suggest that you delete the text = in parenthesis because it is making
suggestions = that border on assumptions!

Well I'd suggest to keep it as = is since the point is to=A0
path computation procedure = from the algorithm to compute each intra-=A0
path segment. Furthermore, we'd = like to highlight the fact that the=A0
procedure does not mandate for = each PCE to use CSPF, could be other

=3D=3D
Section 5.1 = and throughout
"BRPC path computation" seems to = be tautologous

It is actually a double tautology ;-) = (fixed).

=3D=3D
Section = 5.1
I like the simplicity of section = 5.1, but I think you need to point=A0
that
if the sequence of domains is known a priori (can = you determine it a
priori?) then the path = computed might not be 'optimal' in the usual=A0
of
the = word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the = computation so the=A0
resultant
path *is* = optimal within the constraints applied.

Can't agree = more. Good suggestion, thanks.

Updated text: "The PCE-based = BRPC procedure applies to the=A0
an optimal constrained = inter-domain TE LSP. The sequence of domains=A0
to = be
traversed can either be determined a priori or = during the path=A0
computation
procedure. = The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which = constitutes
an additional constraint). In = the case of an arbitrary set of meshed
domains, = the BRPC procedure can be used to compute the optimal path=A0
each domain set in order to get = to optimal constrained path between=A0
source and the destination of = the TE LSP."

=3D=3D
Section = 5.2
The introduction of the term = Virtual Shortest Path Tree is hard to=A0
and
to my = mind the definition is arse about tit. I think you could=A0
add
some = textual definition of what the VSPT is trying to achieve, = before
presenting it in pictorial or = abstract form.
Even more important (I think) is = the fact that the tree as presented
"represents = the shortest path between the destination and BR-en=A0
Frankly, we are building = directional paths in exactly the oposite

This is an abstract form of representation but see = below,

So the VSPT is still a tree, but it is an MP2P tree, = not a P2MP=A0
tree as
I suspect that this is just a = textual descriptive issue rather than
broken in the process.


I clarified = the text to avoid any ambiguity (VSPT defined as a MP2P=A0

=3D=3D
Section = 5.2
I suggest that you pull the note = (Note: in term of computation...) out
a separate section. It doesn't = belong in the middle of section 5.2.
You will = probably want to re-write the text as well since the
unidirectional
limit is not = necessary. Also to explain 'flood' - flood to where,=A0
and = how,
and by whom? And you will want = to add to pieces of information:
- the link to = the I-D that defines how to do this
- a = description of what happens if this process is not used.

This = only works for unidirectional LSPs: indeed, the exit boundary=A0
can flood TE-related data in its = LSA/LSP for the link
=A0
running = on
the link but how would a node in domain (i) get = the TE-related data=A0
the link = entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction = on
unidirectional link. Are we in sync ?

Section 5.2
The paragraph that begins "BRPC guarantees to find = the optimal..."=A0
is a
nascent = Applicability Statement. I suggest moving this to another=A0
and significantly beefing it up. = You need to describe more fully:
- how ECMP = works (the PCC has to request the return of more than=A0
one = path)
- how diversity works (i.e. = section 9 fits in here)
- how some = freedom of selection of domains can be offered
- how to mix the method with other = mechanisms

This was (and is) planned for future revision. Note = that ECMP and
diversity are discussed already = but we're planning the flesh out these
sections = in further revision.
=3D=3D
Section 7
=A0 If the BRPC procedure cannot = be completed because a PCE along the
=A0 domain path does not support = the procedure, a PCErr message is
=A0 returned by the upstream PCE = with a Error-Type "BRPC procedure
=A0 completion failure".=A0 The PCErr message MUST be = relayed to the
=A0 requesting PCC.
Not clear to me whether PCE(n) is supposed to know = that PCE(n+1)=A0
does not
support brpc, = presumably through capabilities
=A0
to
respond = to the path computation request saying that it does not=A0
bit-V of the RP object. If the = latter, presumably the PCErr comes from
PCE(n+1) = and not from PCE(n) as documented.

Good catch, typo: it should read = "a PCErr message is returned to the
The plan is to define a = capability bit (IGP) in a further revision.

=3D=3D
Section 8
Metric = normalisation is a great potential solution, but how does it=A0
with
AS topology confidentiality? What is the solution to = providing=A0
discretion
about what TE = connectivity is available within an AS, and operating=A0

Metric normalization is handled locally by the PCE = and does not=A0
impact the
BRPC = procedure per-say. As far as confidentiality is concerned,=A0
this = only
requires for the SPs to exchange = metric mapping information (nothing
related to = the network topology or resources); for example
SP 1 Links Cost =3D F (link_bandwidth) with F = (OC192)=3D1
SP 2 Links Cost =3D F = (link_bandwidth) with F (OC192)=3D10

A simple metric normalization = can then be performed on the PCE=A0
thanks = to
simple cost mapping tables.

Section = 10
Some of this text has been seen before in this = I-D
Why do you single out LSP = stitching as possibly breaking end-to-end
nesting in this = respect.
But further, your statement = about stitching is pejorative! If you=A0
say = that
"In the case where a domain has = more than one BR-en or more than one
optimality after some network = change within the domain can only be
guaranteed by = re-executing the full brpc computation" then I would=A0
with you. But as phrased, it = implies that making a per-domain
=A0
course) = is
not
the case - = per-domain optimisation will always improve or leave the=A0
end-to-end optimality (in the = case where new resources are made=A0
this is obvious; in the case of = a network failure, *any* path is=A0
than
no path!)
And, lastly, = the text about re-optimisation belongs in the next=A0
not
in this = section.


Yes I = wanted to leave that text to keep track of who would read the=A0
expecting reaction ;-)) = Per-domain reoptimization would always=A0
improve = the
current path *but* in case of = stitched LSPs, TE LSP segments are=A0
by the stitching point; thus in = case of failure, they could end up
following a = non optimal path whereas in the case of contiguous LSP,=A0
BRPC procedure would be called = again thus leading to the optimal path
again. = The point that I was trying to make is "if you have a=A0
stitched = LSP
and rely on BRPC when first = signaled in an attempt to get an=A0
optimal = path,
you need to consider the = interaction between the local reopt mode=A0
and = BRPC
if the goal is to preserve an = optimal path at any given time". Anyway,
we're on = the same page and I agree and the text should be reworded
according to your proposal to avoid any = misunderstanding.

=3D=3D
Section = 13
I would like you to discuss the issues of = confidentiality of topology
information = at greater length. It seems that you would possibly use=A0
technique in conjunction with = path cookies, which is fine. But, are=A0
two things you cannot escape = from?
- indicating which BR-en = provides best connectivity
- indicating = the metric for multiple BR-ens
Maybe there = are some things that can be done here based on policy,
including
not reporting = all of the BR-ens, ranking rather than giving absolute
metrics, etc. But these would compromise = optimality.

Indeed.

Maybe the PCE(n+1) should = carefully monitor and limit=A0
by
policy) brpc requests so that excessive information = is not divulged?

Since one of objectives for using the BRPC procedure = is to compute an
optimal path, we need to know at = least the BN (Boundary Nodes) and the

=3D=3D
I wouldn't = mind seeing a Management Considerations section.
Do we need to be able to examine the pruned pieces = of VSPT at transit
PCEs?
What are the implications of reporting multiple VSPT = branches in=A0
PCEP to
the
MIB modules?
Is brpc = support something that needs to be configured: per PCE?; per
PCE-neighbor?
What are the = implications on existing protocols (IGPs? PCEP?) of using
brpc?

Absolutely ! I put a placeholder = for a further revision.

Fully supportive of adding such = section.

Many Thanks for your comments !


etc.
=3D=3D





I think = Jean-Louis' email address needs updating


=3D=3D
The document would benefit from a little care in the = formatting,=A0
and you
could = usefully re-read it for missing words, etc.
Pce mailing list
Pce mailing list
=
= --Apple-Mail-34--926887836-- --===============0245048820== 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 --===============0245048820==-- From pce-bounces@lists.ietf.org Mon Jun 26 09:17:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuqxf-0004wU-At; Mon, 26 Jun 2006 09:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuqxd-0004hj-2H for pce@ietf.org; Mon, 26 Jun 2006 09:17:05 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuqxX-0007ob-VD for pce@ietf.org; Mon, 26 Jun 2006 09:17:05 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FuqxU-0001DW-00 for pce@ietf.org; Mon, 26 Jun 2006 14:16:56 +0100 Received: from your029b8cecfe ([194.94.109.154] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 14:16:58 +0100 Message-ID: <02b101c69922$cbad5530$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: References: Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 14:14:05 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 26 Jun 2006 13:16:58.0650 (UTC) FILETIME=[CDC02FA0:01C69922] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5655aae64318292c42757ebeb53e54ce Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, I'm trying to parse something out of this thread. 1. It is clear that brpc *demands* that the sequence of domains is already known before brpc is executed. In my opinion, this is clear in the I-D, but it would not hurt to make it clearer. A statement in the Abstract and Introduction would achieve this. 2. The mechanism by which the sequence of domains is known is out of scope for the procedure. It is not clear whether this is a limitation of the process, or not. But in my opinion this is consistent with the guidance that the WG received from the IAB when we were chartered. We are not trying to 'solve the Internet', so selection of domains is out of scope. 3. brpc *does* include mechanisms for the selection of interdomain links and/or nodes. This is more complex than the simple selection of these points of attachment because the connection to use may depend on the TE paths within the domains. IMO, brpc is constructed specifically for this purpose. If we did not need this function, we could use pd-path computation with visibility of the inter-domain TE links. 4. The discussion is not helped by debate about the precise wording around 'constraint'. Let us say that "the sequence of domains to be traversed is provided by an external source as a limiting factor to the computation or choice of paths." Do we all agree with these statements? Cheers, Adrian ----- Original Message ----- From: To: "JP Vasseur" Cc: ; ; Sent: Monday, June 26, 2006 7:51 AM Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt > hi j-p - see in-line > > > > > JP Vasseur > 26/06/2006 02:42 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org, > raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > hi dimitri, > > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > hi j-p - see in-line > > > > > JP Vasseur > 26/06/2006 01:14 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" , > nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > hi dimitiri, > > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > the following comment was also discussed during last meeting > > "== > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > => in brief, how to determine the sequence through which path > computation > has to be performed because if this sequence was known there is no > need > for such procedure (only inter-domain link selection would be > required) - > > Not correct; even if you know the sequence you still need the BRPC > procedure to figure out the set of BN (boundary Nodes) to traverse to > get the shortest inter-domain TE LSP: this is the whole issue with > inter-domain, otherwise per-domain path computation would be sufficient. > > [dp] inter-domain link selection (as i mentioned) implies what you mean > with boundary nodes selection - you could rephrase by access/exit point > selection exact same business > > but again even if you know the sequence you still need BRPC to determine > the set of BN (or exit point - same thing) that will give you the shortest > inter-domain path. Look you wrote "in brief, how to determine the sequence > through which path computation has to be performed because if this > sequence was known there is no need for such procedure", which is not > correct. Even if you know the sequence of domains, you still need the > procedure to get the exit/entry point (named BN) that provide you the > shortest inter-domain path. > > > now adrian mentions that pre- determination becomes a new constraint - > well actually this is not a constraint for the TE LSP itself but a > restriction on the domain set known to be (a-priori) supportive of the > method such as to make the method not returning an error message > > > No, this is a constraint: "Give me the shortest path (potentially > made of loose hops (the BNs)) that provides the shortest end to end > path, considering that the additional constraint is to traverse the > following set of domains . > > [dp] incorrect, this is not a "TE LSP" constraint - > > Who said that this was a TE LSP constraint ? This is *a* constraint. If > you impose the set of domain, this is a constraint. > > Please read the text: "The BRPC procedure guarantees to compute the > optimal path across a specific set of traversed domains (which constitutes > an additional constraint)." > > [dp] i read this, mind you, my point is that this is not a "constraint" of > the same nature as the one you're making use such as minimize delays or > whatsover - this constraint is introduced from the computation technique > and mechanism of this proposed method > > Note that at this point, I still do not see the point that you're trying > to make here ? > > since so far when > a set of domains do not support/or support a given computation has not > yet become a constraint > > hence sentence "The BRPC procedure guarantees to compute the > optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > should as far as i understand the method fulfill the following > > a) this method provides a result iff all domains traversed by the > request > support the proposed method > > BRPC is a multi-PCE based approach where you need at least one PCE > per-domain. > > [dp] indeed, but one PCE supporting that method and having FULL > visibility of the domain > > So what is your point here ? > > [dp] that the set of conditions to have this method workable is larger > than the one listed in this doc. > > b) this method provides an "optimal" result iff > > b1) all possible sequences of domains have been traversed (starting > from > the root) and are supportive of that method - as there might be an > optimal > path through a domain not supporting this method - > > > heu ... yes indeed. If a domain does not support the method, the > method cannot be used to compute the path. > > b2) there is no discontinuity in the availability of the inter-AS link > information on each PCE performing a given selection - indeed a domain > might be supportive of the method without supporting inter-AS link > flooding > > No this is not a requirement, just an optimization. The only > requirement is for the PCE to get the TE-related data about the Inter- > AS links. I'll detail a bit more in the next revision. > > [dp] then you can never achieve - > > You can never achieve what ? > > Sorry Dimitri, I'd love to accommodate your comment but I do not see your > point ... hopefully we'll have a bit of time in Montreal to discuss if > that does not work by email. > > [dp] my point is that without this additional information you can not > achieve the expected result - i pointed to your own text to indicate that > this information is a must have in order to achieve this objective > > using your own words to make it more > straighforward - > > "you still need the BRPC procedure to figure out the set of BN (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP: this is the > whole issue with inter-domain, otherwise per-domain path computation > would > > be sufficient." > > b3) at each step there is no PCE that has partial visibility of a > given > domain > > > This is not specific to BRPC. Even with intra-domain if you want to > compute the path for a TE LSP, you cannot always use the PCE if it > has a partial visibility. Note that this also applies to the case of > co-located PCE (when the path is computed by the head-end). > > [dp] hence, to BRPC as well > > b4) during the selection process no network conditions changes > (that would > make the returned result void) > > > Again, this applies to other cases as well. > > [dp] ditto > > > Ah so we agree here :-) > > What was your comment then ? > > [dp] that you need to include these set of working conditions in the > document itself, the document looks like quite simple in terms of > conditions for having the proposed method working as expected while when > you take a closer look at it this is not the case > > Thanks. > > JP. > > > > thanks. > > JP. > > > > > > > JP Vasseur > 23/06/2006 16:11 > > To: "Adrian Farrel" > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > Many Thanks Adrian for the comments. > > We incorporated the vast majority of them in the new revision (just > posted). > > See below for the comments requesting some clarification. > > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > > Hi, > > Thanks for keeping these ideas alive. > > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. > > Thanks, > Adrian > > == > Is this I-D likely to be Informational or Standards Track? From > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > == > > Status has been updated (Informational) but let's discuss this > later on. > FYI, it does not appear on the front page when using the xml2rfc > editor > (which by the way is excellent), thus the appendix addition. > > It would be nice if the Abstract contained a pithy summary of brpc > and/or > gave the motivation for the draft. For example, what is the method > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? > > Agree. Here is the new Abstract: > "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 (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) has been identified as a key > requirement . > This document specifies a procedure relying on the use of multiple > Path > Computation Elements (PCEs) in order to compute such inter-domain > shortest > constraint paths, using a backward recursive path computation > technique > while fully preserving confidentiality requirements across domains. " > > > == > I'm assuming that section 1 is for short term information only and > will be > deleted (in the next revision?) > == > > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. > > == > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would > argue that > reachability information (i.e. external routes) constitutes > topology and > resource information. > > > OK fine > > == > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed > that, at > the domain boundary LSRs, there will exist some sort of local > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? > > > It should actually read "pre-determined". Actually the best thing > to do > here is to remove "off-line" > > == > Section 5 > No assumption is made on the actual path computation algorithm in > use > by the PCE (it can be any variant of CSPF, algorithm based on > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! > > Well I'd suggest to keep it as is since the point is to > differentiate the > path computation procedure from the algorithm to compute each intra- > domain > path segment. Furthermore, we'd like to highlight the fact that the > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. > > == > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous > > It is actually a double tautology ;-) (fixed). > > == > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > == > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to > parse > and > to my mind the definition is arse about tit. I think you could > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! > > This is an abstract form of representation but see below, > > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. > > > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P > tree). > > == > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where, > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. > > This only works for unidirectional LSPs: indeed, the exit boundary > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP > running on > the link but how would a node in domain (i) get the TE-related data > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? > > == > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..." > is a > nascent Applicability Statement. I suggest moving this to another > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms > > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. > > == > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is > supposed > to > respond to the path computation request saying that it does not > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. > > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. > > == > Section 8 > Metric normalisation is a great potential solution, but how does it > fit > with > AS topology confidentiality? What is the solution to providing > discretion > about what TE connectivity is available within an AS, and operating > brpc? > > Metric normalization is handled locally by the PCE and does not > impact the > BRPC procedure per-say. As far as confidentiality is concerned, > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 > SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 > > A simple metric normalization can then be performed on the PCE > thanks to > simple cost mapping tables. > > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of > course) is > not > the case - per-domain optimisation will always improve or leave the > same > end-to-end optimality (in the case where new resources are made > available > this is obvious; in the case of a network failure, *any* path is > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next > section, > not > in this section. > > > Yes I wanted to leave that text to keep track of who would read the > ID, > expecting reaction ;-)) Per-domain reoptimization would always > improve the > current path *but* in case of stitched LSPs, TE LSP segments are > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP, > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a > stitched LSP > and rely on BRPC when first signaled in an attempt to get an > optimal path, > you need to consider the interaction between the local reopt mode > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. > > == > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use > this > technique in conjunction with path cookies, which is fine. But, are > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. > > Indeed. > > Maybe the PCE(n+1) should carefully monitor and limit > (statistically and > by > policy) brpc requests so that excessive information is not divulged? > > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. > > == > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? > > Absolutely ! I put a placeholder for a further revision. > > Fully supportive of adding such section. > > Many Thanks for your comments ! > > JP. > > etc. > == > > > > > > I think Jean-Louis' email address needs updating > > > == > The document would benefit from a little care in the formatting, > and you > could usefully re-read it for missing words, etc. > == > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 09:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fur29-0008AW-2q; Mon, 26 Jun 2006 09:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fur27-0008AQ-9U for pce@ietf.org; Mon, 26 Jun 2006 09:21:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fur25-0007xQ-73 for pce@ietf.org; Mon, 26 Jun 2006 09:21:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2006 09:21:41 -0400 X-IronPort-AV: i="4.06,175,1149480000"; d="scan'208"; a="91007614:sNHT40417940" 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 k5QDLeYL026644; Mon, 26 Jun 2006 09:21:40 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 09:21:40 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 09:21:38 -0400 In-Reply-To: <02b101c69922$cbad5530$0a23fea9@your029b8cecfe> References: <02b101c69922$cbad5530$0a23fea9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <179F416E-FD60-4EBB-A126-8EB4DDCB2FC6@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 09:21:37 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 26 Jun 2006 13:21:38.0969 (UTC) FILETIME=[74D57890:01C69923] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20c6ed26ee4f226a67d90641b17dfc32 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org 100% Thanks, JP. On Jun 26, 2006, at 9:14 AM, Adrian Farrel wrote: > Hi, > > I'm trying to parse something out of this thread. > > 1. It is clear that brpc *demands* that the sequence of domains > is already known before brpc is executed. > In my opinion, this is clear in the I-D, but it would not hurt to > make it clearer. > A statement in the Abstract and Introduction would achieve > this. > > 2. The mechanism by which the sequence of domains is known > is out of scope for the procedure. > It is not clear whether this is a limitation of the process, or > not. But in my opinion this is consistent with the guidance > that the WG received from the IAB when we were chartered. > We are not trying to 'solve the Internet', so selection of > domains is out of scope. > > 3. brpc *does* include mechanisms for the selection of interdomain > links and/or nodes. This is more complex than the simple selection > of these points of attachment because the connection to use may > depend on the TE paths within the domains. > IMO, brpc is constructed specifically for this purpose. If we did > not need this function, we could use pd-path computation with > visibility of the inter-domain TE links. > > 4. The discussion is not helped by debate about the precise wording > around 'constraint'. > Let us say that "the sequence of domains to be traversed is > provided by an external source as a limiting factor to the > computation > or choice of paths." > > Do we all agree with these statements? > > Cheers, > Adrian > > ----- Original Message ----- From: > To: "JP Vasseur" > Cc: ; ; > > Sent: Monday, June 26, 2006 7:51 AM > Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt > > >> hi j-p - see in-line >> >> >> >> >> JP Vasseur >> 26/06/2006 02:42 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: nabil.n.bitar@verizon.com, pce@ietf.org, >> raymond_zhang@bt.infonet.com >> Subject: Re: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> hi dimitri, >> >> On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >> >> hi j-p - see in-line >> >> >> >> >> JP Vasseur >> 26/06/2006 01:14 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: "Adrian Farrel" , >> nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com >> Subject: Re: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> hi dimitiri, >> >> On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >> >> the following comment was also discussed during last meeting >> >> "== >> Section 5.1 >> I like the simplicity of section 5.1, but I think you need to point >> out >> that >> if the sequence of domains is known a priori (can you determine it a >> priori?) then the path computed might not be 'optimal' in the usual >> sense >> of >> the word, but that this is OK because the ordered list of domains >> constitutes an additional constraint on the computation so the >> resultant >> path *is* optimal within the constraints applied. >> >> Can't agree more. Good suggestion, thanks. >> >> Updated text: "The PCE-based BRPC procedure applies to the >> computation of >> an optimal constrained inter-domain TE LSP. The sequence of domains >> to be >> traversed can either be determined a priori or during the path >> computation >> procedure. The BRPC procedure guarantees to compute the optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> => in brief, how to determine the sequence through which path >> computation >> has to be performed because if this sequence was known there is no >> need >> for such procedure (only inter-domain link selection would be >> required) - >> >> Not correct; even if you know the sequence you still need the BRPC >> procedure to figure out the set of BN (boundary Nodes) to traverse to >> get the shortest inter-domain TE LSP: this is the whole issue with >> inter-domain, otherwise per-domain path computation would be >> sufficient. >> >> [dp] inter-domain link selection (as i mentioned) implies what you >> mean >> with boundary nodes selection - you could rephrase by access/exit >> point >> selection exact same business >> >> but again even if you know the sequence you still need BRPC to >> determine >> the set of BN (or exit point - same thing) that will give you the >> shortest >> inter-domain path. Look you wrote "in brief, how to determine the >> sequence >> through which path computation has to be performed because if this >> sequence was known there is no need for such procedure", which is not >> correct. Even if you know the sequence of domains, you still need the >> procedure to get the exit/entry point (named BN) that provide you the >> shortest inter-domain path. >> >> >> now adrian mentions that pre- determination becomes a new >> constraint - >> well actually this is not a constraint for the TE LSP itself but a >> restriction on the domain set known to be (a-priori) supportive of >> the >> method such as to make the method not returning an error message >> >> >> No, this is a constraint: "Give me the shortest path (potentially >> made of loose hops (the BNs)) that provides the shortest end to end >> path, considering that the additional constraint is to traverse the >> following set of domains . >> >> [dp] incorrect, this is not a "TE LSP" constraint - >> >> Who said that this was a TE LSP constraint ? This is *a* >> constraint. If >> you impose the set of domain, this is a constraint. >> >> Please read the text: "The BRPC procedure guarantees to compute the >> optimal path across a specific set of traversed domains (which >> constitutes >> an additional constraint)." >> >> [dp] i read this, mind you, my point is that this is not a >> "constraint" of >> the same nature as the one you're making use such as minimize >> delays or >> whatsover - this constraint is introduced from the computation >> technique >> and mechanism of this proposed method >> >> Note that at this point, I still do not see the point that you're >> trying >> to make here ? >> >> since so far when >> a set of domains do not support/or support a given computation has >> not >> yet become a constraint >> >> hence sentence "The BRPC procedure guarantees to compute the >> optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> should as far as i understand the method fulfill the following >> >> a) this method provides a result iff all domains traversed by the >> request >> support the proposed method >> >> BRPC is a multi-PCE based approach where you need at least one PCE >> per-domain. >> >> [dp] indeed, but one PCE supporting that method and having FULL >> visibility of the domain >> >> So what is your point here ? >> >> [dp] that the set of conditions to have this method workable is >> larger >> than the one listed in this doc. >> >> b) this method provides an "optimal" result iff >> >> b1) all possible sequences of domains have been traversed (starting >> from >> the root) and are supportive of that method - as there might be an >> optimal >> path through a domain not supporting this method - >> >> >> heu ... yes indeed. If a domain does not support the method, the >> method cannot be used to compute the path. >> >> b2) there is no discontinuity in the availability of the inter-AS >> link >> information on each PCE performing a given selection - indeed a >> domain >> might be supportive of the method without supporting inter-AS link >> flooding >> >> No this is not a requirement, just an optimization. The only >> requirement is for the PCE to get the TE-related data about the >> Inter- >> AS links. I'll detail a bit more in the next revision. >> >> [dp] then you can never achieve - >> >> You can never achieve what ? >> >> Sorry Dimitri, I'd love to accommodate your comment but I do not >> see your >> point ... hopefully we'll have a bit of time in Montreal to >> discuss if >> that does not work by email. >> >> [dp] my point is that without this additional information you can not >> achieve the expected result - i pointed to your own text to >> indicate that >> this information is a must have in order to achieve this objective >> >> using your own words to make it more >> straighforward - >> >> "you still need the BRPC procedure to figure out the set of BN >> (boundary >> Nodes) to traverse to get the shortest inter-domain TE LSP: this >> is the >> whole issue with inter-domain, otherwise per-domain path computation >> would >> >> be sufficient." >> >> b3) at each step there is no PCE that has partial visibility of a >> given >> domain >> >> >> This is not specific to BRPC. Even with intra-domain if you want to >> compute the path for a TE LSP, you cannot always use the PCE if it >> has a partial visibility. Note that this also applies to the case of >> co-located PCE (when the path is computed by the head-end). >> >> [dp] hence, to BRPC as well >> >> b4) during the selection process no network conditions changes >> (that would >> make the returned result void) >> >> >> Again, this applies to other cases as well. >> >> [dp] ditto >> >> >> Ah so we agree here :-) >> >> What was your comment then ? >> >> [dp] that you need to include these set of working conditions in the >> document itself, the document looks like quite simple in terms of >> conditions for having the proposed method working as expected >> while when >> you take a closer look at it this is not the case >> >> Thanks. >> >> JP. >> >> >> >> thanks. >> >> JP. >> >> >> >> >> >> >> JP Vasseur >> 23/06/2006 16:11 >> >> To: "Adrian Farrel" >> cc: raymond_zhang@bt.infonet.com, pce@ietf.org, >> nabil.n.bitar@verizon.com >> Subject: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> Many Thanks Adrian for the comments. >> >> We incorporated the vast majority of them in the new revision (just >> posted). >> >> See below for the comments requesting some clarification. >> >> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >> >> Hi, >> >> Thanks for keeping these ideas alive. >> >> Here are some picky thoughts that you may want to include in the next >> revision to make it more robust as a document. I don't have any >> issues >> with >> the basic process. >> >> Thanks, >> Adrian >> >> == >> Is this I-D likely to be Informational or Standards Track? From >> Appendix >> A, >> this looks like Standards Track. Can you remove Appendix A and put >> the >> status in the usual place in the header? >> == >> >> Status has been updated (Informational) but let's discuss this >> later on. >> FYI, it does not appear on the front page when using the xml2rfc >> editor >> (which by the way is excellent), thus the appendix addition. >> >> It would be nice if the Abstract contained a pithy summary of brpc >> and/or >> gave the motivation for the draft. For example, what is the method >> trying >> to >> achieve that isn't achievable by other methods? Or, what is the >> fundamental >> element of brpc that is not in other methods? >> >> Agree. Here is the new Abstract: >> "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 (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) has been identified as a key >> requirement . >> This document specifies a procedure relying on the use of multiple >> Path >> Computation Elements (PCEs) in order to compute such inter-domain >> shortest >> constraint paths, using a backward recursive path computation >> technique >> while fully preserving confidentiality requirements across domains. " >> >> >> == >> I'm assuming that section 1 is for short term information only and >> will be >> deleted (in the next revision?) >> == >> >> Indeed, just to provide a bit of history for the ones who have been >> following inter-domain path computation for a while. >> >> == >> Section 4 >> - No topology or resource information is distributed between domains >> (as mandated per [RFC4105] and [RFC4216]), which is critical to >> preserve IGP/BGP scalability and confidentiality in the case of TE >> LSPs spanning multiple domains. >> You should clarify what you are saying here, because many would >> argue that >> reachability information (i.e. external routes) constitutes >> topology and >> resource information. >> >> >> OK fine >> >> == >> Section 4 >> - While certain constraints like bandwidth can be used across >> different domains, certain other TE constraints like resource >> affinity, color, metric, etc. as listed in [RFC2702] could be >> translated at domain boundaries. If required, it is assumed >> that, at >> the domain boundary LSRs, there will exist some sort of local >> mapping >> based on offline policy agreement, in order to translate such >> constraints across domain boundaries during the inter-PCE >> communication process. >> Why does the policy agreement need to be offline? >> >> >> It should actually read "pre-determined". Actually the best thing >> to do >> here is to remove "off-line" >> >> == >> Section 5 >> No assumption is made on the actual path computation algorithm in >> use >> by the PCE (it can be any variant of CSPF, algorithm based on >> linear- >> programming to solve multi-constraints optimization problems and so >> on). >> Suggest that you delete the text in parenthesis because it is making >> suggestions that border on assumptions! >> >> Well I'd suggest to keep it as is since the point is to >> differentiate the >> path computation procedure from the algorithm to compute each intra- >> domain >> path segment. Furthermore, we'd like to highlight the fact that the >> BRPC >> procedure does not mandate for each PCE to use CSPF, could be other >> algorithm. >> >> == >> Section 5.1 and throughout >> "BRPC path computation" seems to be tautologous >> >> It is actually a double tautology ;-) (fixed). >> >> == >> Section 5.1 >> I like the simplicity of section 5.1, but I think you need to point >> out >> that >> if the sequence of domains is known a priori (can you determine it a >> priori?) then the path computed might not be 'optimal' in the usual >> sense >> of >> the word, but that this is OK because the ordered list of domains >> constitutes an additional constraint on the computation so the >> resultant >> path *is* optimal within the constraints applied. >> >> Can't agree more. Good suggestion, thanks. >> >> Updated text: "The PCE-based BRPC procedure applies to the >> computation of >> an optimal constrained inter-domain TE LSP. The sequence of domains >> to be >> traversed can either be determined a priori or during the path >> computation >> procedure. The BRPC procedure guarantees to compute the optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> == >> Section 5.2 >> The introduction of the term Virtual Shortest Path Tree is hard to >> parse >> and >> to my mind the definition is arse about tit. I think you could >> usefully >> add >> some textual definition of what the VSPT is trying to achieve, before >> presenting it in pictorial or abstract form. >> Even more important (I think) is the fact that the tree as presented >> "represents the shortest path between the destination and BR-en >> (j,i)..." >> Frankly, we are building directional paths in exactly the oposite >> direction! >> >> This is an abstract form of representation but see below, >> >> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP >> tree as >> described. >> I suspect that this is just a textual descriptive issue rather than >> anything >> broken in the process. >> >> >> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P >> tree). >> >> == >> Section 5.2 >> I suggest that you pull the note (Note: in term of computation...) >> out >> into >> a separate section. It doesn't belong in the middle of section 5.2. >> You will probably want to re-write the text as well since the >> unidirectional >> limit is not necessary. Also to explain 'flood' - flood to where, >> and how, >> and by whom? And you will want to add to pieces of information: >> - the link to the I-D that defines how to do this >> - a description of what happens if this process is not used. >> >> This only works for unidirectional LSPs: indeed, the exit boundary >> node >> can flood TE-related data in its LSA/LSP for the link >> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP >> running on >> the link but how would a node in domain (i) get the TE-related data >> for >> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the >> restriction on >> unidirectional link. Are we in sync ? >> >> == >> Section 5.2 >> The paragraph that begins "BRPC guarantees to find the optimal..." >> is a >> nascent Applicability Statement. I suggest moving this to another >> Section >> and significantly beefing it up. You need to describe more fully: >> - how ECMP works (the PCC has to request the return of more than >> one path) >> - how diversity works (i.e. section 9 fits in here) >> - how some freedom of selection of domains can be offered >> - how to mix the method with other mechanisms >> >> This was (and is) planned for future revision. Note that ECMP and >> diversity are discussed already but we're planning the flesh out >> these >> sections in further revision. >> >> == >> Section 7 >> If the BRPC procedure cannot be completed because a PCE along the >> domain path does not support the procedure, a PCErr message is >> returned by the upstream PCE with a Error-Type "BRPC procedure >> completion failure". The PCErr message MUST be relayed to the >> requesting PCC. >> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >> does not >> support brpc, presumably through capabilities >> configuration/advertisement/negotiation, or whether PCE(n+1) is >> supposed >> to >> respond to the path computation request saying that it does not >> support >> bit-V of the RP object. If the latter, presumably the PCErr comes >> from >> PCE(n+1) and not from PCE(n) as documented. >> >> Good catch, typo: it should read "a PCErr message is returned to the >> upstream". >> The plan is to define a capability bit (IGP) in a further revision. >> >> == >> Section 8 >> Metric normalisation is a great potential solution, but how does it >> fit >> with >> AS topology confidentiality? What is the solution to providing >> discretion >> about what TE connectivity is available within an AS, and operating >> brpc? >> >> Metric normalization is handled locally by the PCE and does not >> impact the >> BRPC procedure per-say. As far as confidentiality is concerned, >> this only >> requires for the SPs to exchange metric mapping information (nothing >> related to the network topology or resources); for example >> SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 >> SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 >> >> A simple metric normalization can then be performed on the PCE >> thanks to >> simple cost mapping tables. >> >> Section 10 >> Some of this text has been seen before in this I-D >> Why do you single out LSP stitching as possibly breaking end-to-end >> optimality. There is functionally no difference between stitching and >> nesting in this respect. >> But further, your statement about stitching is pejorative! If you >> say that >> "In the case where a domain has more than one BR-en or more than one >> BR-ex, >> optimality after some network change within the domain can only be >> guaranteed by re-executing the full brpc computation" then I would >> agree >> with you. But as phrased, it implies that making a per-domain >> re-optimisation could make the path *less* optimal. This (of >> course) is >> not >> the case - per-domain optimisation will always improve or leave the >> same >> end-to-end optimality (in the case where new resources are made >> available >> this is obvious; in the case of a network failure, *any* path is >> better >> than >> no path!) >> And, lastly, the text about re-optimisation belongs in the next >> section, >> not >> in this section. >> >> >> Yes I wanted to leave that text to keep track of who would read the >> ID, >> expecting reaction ;-)) Per-domain reoptimization would always >> improve the >> current path *but* in case of stitched LSPs, TE LSP segments are >> computed >> by the stitching point; thus in case of failure, they could end up >> following a non optimal path whereas in the case of contiguous LSP, >> the >> BRPC procedure would be called again thus leading to the optimal path >> again. The point that I was trying to make is "if you have a >> stitched LSP >> and rely on BRPC when first signaled in an attempt to get an >> optimal path, >> you need to consider the interaction between the local reopt mode >> and BRPC >> if the goal is to preserve an optimal path at any given time". >> Anyway, >> we're on the same page and I agree and the text should be reworded >> according to your proposal to avoid any misunderstanding. >> >> == >> Section 13 >> I would like you to discuss the issues of confidentiality of topology >> information at greater length. It seems that you would possibly use >> this >> technique in conjunction with path cookies, which is fine. But, are >> there >> two things you cannot escape from? >> - indicating which BR-en provides best connectivity >> - indicating the metric for multiple BR-ens >> Maybe there are some things that can be done here based on policy, >> including >> not reporting all of the BR-ens, ranking rather than giving absolute >> metrics, etc. But these would compromise optimality. >> >> Indeed. >> >> Maybe the PCE(n+1) should carefully monitor and limit >> (statistically and >> by >> policy) brpc requests so that excessive information is not divulged? >> >> Since one of objectives for using the BRPC procedure is to compute an >> optimal path, we need to know at least the BN (Boundary Nodes) and >> the >> cost. >> >> == >> I wouldn't mind seeing a Management Considerations section. >> Do we need to be able to examine the pruned pieces of VSPT at transit >> PCEs? >> What are the implications of reporting multiple VSPT branches in >> PCEP to >> the >> MIB modules? >> Is brpc support something that needs to be configured: per PCE?; per >> PCE-neighbor? >> What are the implications on existing protocols (IGPs? PCEP?) of >> using >> brpc? >> >> Absolutely ! I put a placeholder for a further revision. >> >> Fully supportive of adding such section. >> >> Many Thanks for your comments ! >> >> JP. >> >> etc. >> == >> >> >> >> >> >> I think Jean-Louis' email address needs updating >> >> >> == >> The document would benefit from a little care in the formatting, >> and you >> could usefully re-read it for missing words, etc. >> == >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 09:42:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurMa-00083E-MH; Mon, 26 Jun 2006 09:42:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurMZ-000839-2v for pce@ietf.org; Mon, 26 Jun 2006 09:42:51 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurMV-0000sN-Md for pce@ietf.org; Mon, 26 Jun 2006 09:42:51 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5QDgbdS030506; Mon, 26 Jun 2006 15:42:37 +0200 In-Reply-To: <08BBCE0D-BD0E-4D1D-A924-6C8D22ECC5EF@cisco.com> To: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 26 Jun 2006 15:42:33 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/26/2006 15:42:36, Serialize complete at 06/26/2006 15:42:36 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: 489500194134bea022a3070ad86cad76 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi i don't think 1) and 2) have been captured on 1) there is a terminology issue - indeed - but there is also an issue that is the arbitrary selection/pruning of other potential alternatives - why that sequence ? and not another - was mentioned as the chicken-egg (technical) problem; first there may be many available interdomain paths that are never learned by the LSRs, more generically the diversity of the BGP routes available at each LSR is not sufficient to successfully provide for a satisfactory sequence; on the other hand, you may have receive multiple let's take an example to illustrate there are two AS path between A and D, one A-B-C-D the other A-E-F-D disjoint (on intermediate ASs) either both sequences are valid both policing and filtering makes you selecting the inappropriate sequence for the real TE-LSP consrttaints on 2) this is part of the answer - the comment was PCE per domain supporting that method - and in case of two PCEs or more per domain i am not sure how one could guarantee that the proposed (recursive) sequence works (assumption is made that the PCE as full visibility on the whole domain but what in case of multiple PCEs per domain) i have also asked to have a better description of the working conditions along this draft - to complete section 5.1 - if you consider this as non-technical or technical feedback that's your own appreciation thanks, - dimitri. JP Vasseur 26/06/2006 14:54 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi, ok so to summarize there was no technical feed-back just a few editorial comments. You'd like to add to the following to the document: 1) The set of traversed domains has to be known and according to you this is not a constraint. I think that the current text is quite clear: "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint)." Now if you want to reword a bit to avoid using the word "constraint" although this *is* a constraint, this is no big deal. Actually, interestingly enough there are quite a few cases where there's only one single set of traversed domains. 2) We need at least one PCE per domain Sounds quite obvious but I have no problem adding this. Actually we're planning in the next revision to elaborate a little bit on the inter-As link flooding (again this is not a requirement but an optimization) but this will be covered. JP. On Jun 26, 2006, at 2:51 AM, Dimitri.Papadimitriou@alcatel.be wrote: hi j-p - see in-line JP Vasseur 26/06/2006 02:42 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi dimitri, On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: hi j-p - see in-line JP Vasseur 26/06/2006 01:14 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Adrian Farrel" , nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt hi dimitiri, On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: the following comment was also discussed during last meeting "== Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." => in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure (only inter-domain link selection would be required) - Not correct; even if you know the sequence you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient. [dp] inter-domain link selection (as i mentioned) implies what you mean with boundary nodes selection - you could rephrase by access/exit point selection exact same business but again even if you know the sequence you still need BRPC to determine the set of BN (or exit point - same thing) that will give you the shortest inter-domain path. Look you wrote "in brief, how to determine the sequence through which path computation has to be performed because if this sequence was known there is no need for such procedure", which is not correct. Even if you know the sequence of domains, you still need the procedure to get the exit/entry point (named BN) that provide you the shortest inter-domain path. now adrian mentions that pre- determination becomes a new constraint - well actually this is not a constraint for the TE LSP itself but a restriction on the domain set known to be (a-priori) supportive of the method such as to make the method not returning an error message No, this is a constraint: "Give me the shortest path (potentially made of loose hops (the BNs)) that provides the shortest end to end path, considering that the additional constraint is to traverse the following set of domains . [dp] incorrect, this is not a "TE LSP" constraint - Who said that this was a TE LSP constraint ? This is *a* constraint. If you impose the set of domain, this is a constraint. Please read the text: "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint)." [dp] i read this, mind you, my point is that this is not a "constraint" of the same nature as the one you're making use such as minimize delays or whatsover - this constraint is introduced from the computation technique and mechanism of this proposed method Note that at this point, I still do not see the point that you're trying to make here ? since so far when a set of domains do not support/or support a given computation has not yet become a constraint hence sentence "The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." should as far as i understand the method fulfill the following a) this method provides a result iff all domains traversed by the request support the proposed method BRPC is a multi-PCE based approach where you need at least one PCE per-domain. [dp] indeed, but one PCE supporting that method and having FULL visibility of the domain So what is your point here ? [dp] that the set of conditions to have this method workable is larger than the one listed in this doc. b) this method provides an "optimal" result iff b1) all possible sequences of domains have been traversed (starting from the root) and are supportive of that method - as there might be an optimal path through a domain not supporting this method - heu ... yes indeed. If a domain does not support the method, the method cannot be used to compute the path. b2) there is no discontinuity in the availability of the inter-AS link information on each PCE performing a given selection - indeed a domain might be supportive of the method without supporting inter-AS link flooding No this is not a requirement, just an optimization. The only requirement is for the PCE to get the TE-related data about the Inter- AS links. I'll detail a bit more in the next revision. [dp] then you can never achieve - You can never achieve what ? Sorry Dimitri, I'd love to accommodate your comment but I do not see your point ... hopefully we'll have a bit of time in Montreal to discuss if that does not work by email. [dp] my point is that without this additional information you can not achieve the expected result - i pointed to your own text to indicate that this information is a must have in order to achieve this objective using your own words to make it more straighforward - "you still need the BRPC procedure to figure out the set of BN (boundary Nodes) to traverse to get the shortest inter-domain TE LSP: this is the whole issue with inter-domain, otherwise per-domain path computation would be sufficient." b3) at each step there is no PCE that has partial visibility of a given domain This is not specific to BRPC. Even with intra-domain if you want to compute the path for a TE LSP, you cannot always use the PCE if it has a partial visibility. Note that this also applies to the case of co-located PCE (when the path is computed by the head-end). [dp] hence, to BRPC as well b4) during the selection process no network conditions changes (that would make the returned result void) Again, this applies to other cases as well. [dp] ditto Ah so we agree here :-) What was your comment then ? [dp] that you need to include these set of working conditions in the document itself, the document looks like quite simple in terms of conditions for having the proposed method working as expected while when you take a closer look at it this is not the case Thanks. JP. thanks. JP. JP Vasseur 23/06/2006 16:11 To: "Adrian Farrel" cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com Subject: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Many Thanks Adrian for the comments. We incorporated the vast majority of them in the new revision (just posted). See below for the comments requesting some clarification. On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: Hi, Thanks for keeping these ideas alive. Here are some picky thoughts that you may want to include in the next revision to make it more robust as a document. I don't have any issues with the basic process. Thanks, Adrian == Is this I-D likely to be Informational or Standards Track? From Appendix A, this looks like Standards Track. Can you remove Appendix A and put the status in the usual place in the header? == Status has been updated (Informational) but let's discuss this later on. FYI, it does not appear on the front page when using the xml2rfc editor (which by the way is excellent), thus the appendix addition. It would be nice if the Abstract contained a pithy summary of brpc and/or gave the motivation for the draft. For example, what is the method trying to achieve that isn't achievable by other methods? Or, what is the fundamental element of brpc that is not in other methods? Agree. Here is the new Abstract: "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 (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) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths, using a backward recursive path computation technique while fully preserving confidentiality requirements across domains. " == I'm assuming that section 1 is for short term information only and will be deleted (in the next revision?) == Indeed, just to provide a bit of history for the ones who have been following inter-domain path computation for a while. == Section 4 - No topology or resource information is distributed between domains (as mandated per [RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality in the case of TE LSPs spanning multiple domains. You should clarify what you are saying here, because many would argue that reachability information (i.e. external routes) constitutes topology and resource information. OK fine == Section 4 - While certain constraints like bandwidth can be used across different domains, certain other TE constraints like resource affinity, color, metric, etc. as listed in [RFC2702] could be translated at domain boundaries. If required, it is assumed that, at the domain boundary LSRs, there will exist some sort of local mapping based on offline policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. Why does the policy agreement need to be offline? It should actually read "pre-determined". Actually the best thing to do here is to remove "off-line" == Section 5 No assumption is made on the actual path computation algorithm in use by the PCE (it can be any variant of CSPF, algorithm based on linear- programming to solve multi-constraints optimization problems and so on). Suggest that you delete the text in parenthesis because it is making suggestions that border on assumptions! Well I'd suggest to keep it as is since the point is to differentiate the path computation procedure from the algorithm to compute each intra- domain path segment. Furthermore, we'd like to highlight the fact that the BRPC procedure does not mandate for each PCE to use CSPF, could be other algorithm. == Section 5.1 and throughout "BRPC path computation" seems to be tautologous It is actually a double tautology ;-) (fixed). == Section 5.1 I like the simplicity of section 5.1, but I think you need to point out that if the sequence of domains is known a priori (can you determine it a priori?) then the path computed might not be 'optimal' in the usual sense of the word, but that this is OK because the ordered list of domains constitutes an additional constraint on the computation so the resultant path *is* optimal within the constraints applied. Can't agree more. Good suggestion, thanks. Updated text: "The PCE-based BRPC procedure applies to the computation of an optimal constrained inter-domain TE LSP. The sequence of domains to be traversed can either be determined a priori or during the path computation procedure. The BRPC procedure guarantees to compute the optimal path across a specific set of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get to optimal constrained path between the source and the destination of the TE LSP." == Section 5.2 The introduction of the term Virtual Shortest Path Tree is hard to parse and to my mind the definition is arse about tit. I think you could usefully add some textual definition of what the VSPT is trying to achieve, before presenting it in pictorial or abstract form. Even more important (I think) is the fact that the tree as presented "represents the shortest path between the destination and BR-en (j,i)..." Frankly, we are building directional paths in exactly the oposite direction! This is an abstract form of representation but see below, So the VSPT is still a tree, but it is an MP2P tree, not a P2MP tree as described. I suspect that this is just a textual descriptive issue rather than anything broken in the process. I clarified the text to avoid any ambiguity (VSPT defined as a MP2P tree). == Section 5.2 I suggest that you pull the note (Note: in term of computation...) out into a separate section. It doesn't belong in the middle of section 5.2. You will probably want to re-write the text as well since the unidirectional limit is not necessary. Also to explain 'flood' - flood to where, and how, and by whom? And you will want to add to pieces of information: - the link to the I-D that defines how to do this - a description of what happens if this process is not used. This only works for unidirectional LSPs: indeed, the exit boundary node can flood TE-related data in its LSA/LSP for the link exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP running on the link but how would a node in domain (i) get the TE-related data for the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on unidirectional link. Are we in sync ? == Section 5.2 The paragraph that begins "BRPC guarantees to find the optimal..." is a nascent Applicability Statement. I suggest moving this to another Section and significantly beefing it up. You need to describe more fully: - how ECMP works (the PCC has to request the return of more than one path) - how diversity works (i.e. section 9 fits in here) - how some freedom of selection of domains can be offered - how to mix the method with other mechanisms This was (and is) planned for future revision. Note that ECMP and diversity are discussed already but we're planning the flesh out these sections in further revision. == Section 7 If the BRPC procedure cannot be completed because a PCE along the domain path does not support the procedure, a PCErr message is returned by the upstream PCE with a Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. Not clear to me whether PCE(n) is supposed to know that PCE(n+1) does not support brpc, presumably through capabilities configuration/advertisement/negotiation, or whether PCE(n+1) is supposed to respond to the path computation request saying that it does not support bit-V of the RP object. If the latter, presumably the PCErr comes from PCE(n+1) and not from PCE(n) as documented. Good catch, typo: it should read "a PCErr message is returned to the upstream". The plan is to define a capability bit (IGP) in a further revision. == Section 8 Metric normalisation is a great potential solution, but how does it fit with AS topology confidentiality? What is the solution to providing discretion about what TE connectivity is available within an AS, and operating brpc? Metric normalization is handled locally by the PCE and does not impact the BRPC procedure per-say. As far as confidentiality is concerned, this only requires for the SPs to exchange metric mapping information (nothing related to the network topology or resources); for example SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 A simple metric normalization can then be performed on the PCE thanks to simple cost mapping tables. Section 10 Some of this text has been seen before in this I-D Why do you single out LSP stitching as possibly breaking end-to-end optimality. There is functionally no difference between stitching and nesting in this respect. But further, your statement about stitching is pejorative! If you say that "In the case where a domain has more than one BR-en or more than one BR-ex, optimality after some network change within the domain can only be guaranteed by re-executing the full brpc computation" then I would agree with you. But as phrased, it implies that making a per-domain re-optimisation could make the path *less* optimal. This (of course) is not the case - per-domain optimisation will always improve or leave the same end-to-end optimality (in the case where new resources are made available this is obvious; in the case of a network failure, *any* path is better than no path!) And, lastly, the text about re-optimisation belongs in the next section, not in this section. Yes I wanted to leave that text to keep track of who would read the ID, expecting reaction ;-)) Per-domain reoptimization would always improve the current path *but* in case of stitched LSPs, TE LSP segments are computed by the stitching point; thus in case of failure, they could end up following a non optimal path whereas in the case of contiguous LSP, the BRPC procedure would be called again thus leading to the optimal path again. The point that I was trying to make is "if you have a stitched LSP and rely on BRPC when first signaled in an attempt to get an optimal path, you need to consider the interaction between the local reopt mode and BRPC if the goal is to preserve an optimal path at any given time". Anyway, we're on the same page and I agree and the text should be reworded according to your proposal to avoid any misunderstanding. == Section 13 I would like you to discuss the issues of confidentiality of topology information at greater length. It seems that you would possibly use this technique in conjunction with path cookies, which is fine. But, are there two things you cannot escape from? - indicating which BR-en provides best connectivity - indicating the metric for multiple BR-ens Maybe there are some things that can be done here based on policy, including not reporting all of the BR-ens, ranking rather than giving absolute metrics, etc. But these would compromise optimality. Indeed. Maybe the PCE(n+1) should carefully monitor and limit (statistically and by policy) brpc requests so that excessive information is not divulged? Since one of objectives for using the BRPC procedure is to compute an optimal path, we need to know at least the BN (Boundary Nodes) and the cost. == I wouldn't mind seeing a Management Considerations section. Do we need to be able to examine the pruned pieces of VSPT at transit PCEs? What are the implications of reporting multiple VSPT branches in PCEP to the MIB modules? Is brpc support something that needs to be configured: per PCE?; per PCE-neighbor? What are the implications on existing protocols (IGPs? PCEP?) of using brpc? Absolutely ! I put a placeholder for a further revision. Fully supportive of adding such section. Many Thanks for your comments ! JP. etc. == I think Jean-Louis' email address needs updating == The document would benefit from a little care in the formatting, and you could usefully re-read it for missing words, etc. == _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 09:46:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurQ8-0002zk-9y; Mon, 26 Jun 2006 09:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurQ6-0002xI-9O for pce@ietf.org; Mon, 26 Jun 2006 09:46:30 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurQ3-0000ye-6O for pce@ietf.org; Mon, 26 Jun 2006 09:46:30 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k5QDkLl6005063; Mon, 26 Jun 2006 09:46:21 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11480; Mon, 26 Jun 2006 09:46:21 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jun 2006 09:46:20 -0400 Message-ID: <0BF76B30C100624BA997C9CED19D81250A5D1A@uspitsmsgusr08.win.marconi.com> From: "Gray, Eric" To: Adrian Farrel , Dimitri.Papadimitriou@alcatel.be Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 09:46:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a5c486139a804859f37cd11eb5255b5 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org I do. --> -----Original Message----- --> From: Adrian Farrel [mailto:adrian@olddog.co.uk] --> Sent: Monday, June 26, 2006 9:14 AM --> To: Dimitri.Papadimitriou@alcatel.be --> Cc: pce@ietf.org --> Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt --> --> Hi, --> --> I'm trying to parse something out of this thread. --> --> 1. It is clear that brpc *demands* that the sequence of domains --> is already known before brpc is executed. --> In my opinion, this is clear in the I-D, but it would --> not hurt to --> make it clearer. --> A statement in the Abstract and Introduction would achieve --> this. --> --> 2. The mechanism by which the sequence of domains is known --> is out of scope for the procedure. --> It is not clear whether this is a limitation of the process, or --> not. But in my opinion this is consistent with the guidance --> that the WG received from the IAB when we were chartered. --> We are not trying to 'solve the Internet', so selection of --> domains is out of scope. --> --> 3. brpc *does* include mechanisms for the selection of interdomain --> links and/or nodes. This is more complex than the --> simple selection --> of these points of attachment because the connection to use may --> depend on the TE paths within the domains. --> IMO, brpc is constructed specifically for this purpose. --> If we did --> not need this function, we could use pd-path computation with --> visibility of the inter-domain TE links. --> --> 4. The discussion is not helped by debate about the precise wording --> around 'constraint'. --> Let us say that "the sequence of domains to be traversed is --> provided by an external source as a limiting factor to --> the computation --> or choice of paths." --> --> Do we all agree with these statements? --> --> Cheers, --> Adrian --> --> ----- Original Message ----- --> From: --> To: "JP Vasseur" --> Cc: ; ; --> --> Sent: Monday, June 26, 2006 7:51 AM --> Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt --> --> --> > hi j-p - see in-line --> > --> > --> > --> > --> > JP Vasseur --> > 26/06/2006 02:42 --> > --> > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL --> > cc: nabil.n.bitar@verizon.com, pce@ietf.org, --> > raymond_zhang@bt.infonet.com --> > Subject: Re: [Pce] Re: Comments on --> > draft-vasseur-pce-brpc-00.txt --> > --> > --> > hi dimitri, --> > --> > On Jun 25, 2006, at 7:35 PM, --> Dimitri.Papadimitriou@alcatel.be wrote: --> > --> > hi j-p - see in-line --> > --> > --> > --> > --> > JP Vasseur --> > 26/06/2006 01:14 --> > --> > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL --> > cc: "Adrian Farrel" , --> > nabil.n.bitar@verizon.com, pce@ietf.org, --> raymond_zhang@bt.infonet.com --> > Subject: Re: [Pce] Re: Comments on --> > draft-vasseur-pce-brpc-00.txt --> > --> > --> > hi dimitiri, --> > --> > On Jun 25, 2006, at 2:08 PM, --> Dimitri.Papadimitriou@alcatel.be wrote: --> > --> > the following comment was also discussed during last meeting --> > --> > "== --> > Section 5.1 --> > I like the simplicity of section 5.1, but I think you --> need to point --> > out --> > that --> > if the sequence of domains is known a priori (can you --> determine it a --> > priori?) then the path computed might not be 'optimal' in --> the usual --> > sense --> > of --> > the word, but that this is OK because the ordered list of domains --> > constitutes an additional constraint on the computation so the --> > resultant --> > path *is* optimal within the constraints applied. --> > --> > Can't agree more. Good suggestion, thanks. --> > --> > Updated text: "The PCE-based BRPC procedure applies to the --> > computation of --> > an optimal constrained inter-domain TE LSP. The sequence --> of domains --> > to be --> > traversed can either be determined a priori or during the path --> > computation --> > procedure. The BRPC procedure guarantees to compute the --> optimal path --> > across a specific set of traversed domains (which constitutes --> > an additional constraint). In the case of an arbitrary --> set of meshed --> > domains, the BRPC procedure can be used to compute the --> optimal path --> > across --> > each domain set in order to get to optimal constrained --> path between --> > the --> > source and the destination of the TE LSP." --> > --> > => in brief, how to determine the sequence through which path --> > computation --> > has to be performed because if this sequence was known there is no --> > need --> > for such procedure (only inter-domain link selection would be --> > required) - --> > --> > Not correct; even if you know the sequence you still need the BRPC --> > procedure to figure out the set of BN (boundary Nodes) to --> traverse to --> > get the shortest inter-domain TE LSP: this is the whole issue with --> > inter-domain, otherwise per-domain path computation would --> be sufficient. --> > --> > [dp] inter-domain link selection (as i mentioned) implies --> what you mean --> > with boundary nodes selection - you could rephrase by --> access/exit point --> > selection exact same business --> > --> > but again even if you know the sequence you still need --> BRPC to determine --> > the set of BN (or exit point - same thing) that will give --> you the shortest --> > inter-domain path. Look you wrote "in brief, how to --> determine the sequence --> > through which path computation has to be performed because if this --> > sequence was known there is no need for such procedure", --> which is not --> > correct. Even if you know the sequence of domains, you --> still need the --> > procedure to get the exit/entry point (named BN) that --> provide you the --> > shortest inter-domain path. --> > --> > --> > now adrian mentions that pre- determination becomes a new --> constraint - --> > well actually this is not a constraint for the TE LSP itself but a --> > restriction on the domain set known to be (a-priori) --> supportive of the --> > method such as to make the method not returning an error message --> > --> > --> > No, this is a constraint: "Give me the shortest path (potentially --> > made of loose hops (the BNs)) that provides the shortest --> end to end --> > path, considering that the additional constraint is to --> traverse the --> > following set of domains . --> > --> > [dp] incorrect, this is not a "TE LSP" constraint - --> > --> > Who said that this was a TE LSP constraint ? This is *a* --> constraint. If --> > you impose the set of domain, this is a constraint. --> > --> > Please read the text: "The BRPC procedure guarantees to --> compute the --> > optimal path across a specific set of traversed domains --> (which constitutes --> > an additional constraint)." --> > --> > [dp] i read this, mind you, my point is that this is not --> a "constraint" of --> > the same nature as the one you're making use such as --> minimize delays or --> > whatsover - this constraint is introduced from the --> computation technique --> > and mechanism of this proposed method --> > --> > Note that at this point, I still do not see the point --> that you're trying --> > to make here ? --> > --> > since so far when --> > a set of domains do not support/or support a given --> computation has not --> > yet become a constraint --> > --> > hence sentence "The BRPC procedure guarantees to compute the --> > optimal path --> > across a specific set of traversed domains (which constitutes --> > an additional constraint). In the case of an arbitrary --> set of meshed --> > domains, the BRPC procedure can be used to compute the --> optimal path --> > across --> > each domain set in order to get to optimal constrained --> path between --> > the --> > source and the destination of the TE LSP." --> > --> > should as far as i understand the method fulfill the following --> > --> > a) this method provides a result iff all domains traversed by the --> > request --> > support the proposed method --> > --> > BRPC is a multi-PCE based approach where you need at least one PCE --> > per-domain. --> > --> > [dp] indeed, but one PCE supporting that method and having FULL --> > visibility of the domain --> > --> > So what is your point here ? --> > --> > [dp] that the set of conditions to have this method --> workable is larger --> > than the one listed in this doc. --> > --> > b) this method provides an "optimal" result iff --> > --> > b1) all possible sequences of domains have been traversed --> (starting --> > from --> > the root) and are supportive of that method - as there might be an --> > optimal --> > path through a domain not supporting this method - --> > --> > --> > heu ... yes indeed. If a domain does not support the method, the --> > method cannot be used to compute the path. --> > --> > b2) there is no discontinuity in the availability of the --> inter-AS link --> > information on each PCE performing a given selection - --> indeed a domain --> > might be supportive of the method without supporting inter-AS link --> > flooding --> > --> > No this is not a requirement, just an optimization. The only --> > requirement is for the PCE to get the TE-related data --> about the Inter- --> > AS links. I'll detail a bit more in the next revision. --> > --> > [dp] then you can never achieve - --> > --> > You can never achieve what ? --> > --> > Sorry Dimitri, I'd love to accommodate your comment but I --> do not see your --> > point ... hopefully we'll have a bit of time in Montreal --> to discuss if --> > that does not work by email. --> > --> > [dp] my point is that without this additional information --> you can not --> > achieve the expected result - i pointed to your own text --> to indicate that --> > this information is a must have in order to achieve this objective --> > --> > using your own words to make it more --> > straighforward - --> > --> > "you still need the BRPC procedure to figure out the set --> of BN (boundary --> > Nodes) to traverse to get the shortest inter-domain TE --> LSP: this is the --> > whole issue with inter-domain, otherwise per-domain path --> computation --> > would --> > --> > be sufficient." --> > --> > b3) at each step there is no PCE that has partial visibility of a --> > given --> > domain --> > --> > --> > This is not specific to BRPC. Even with intra-domain if --> you want to --> > compute the path for a TE LSP, you cannot always use the PCE if it --> > has a partial visibility. Note that this also applies to --> the case of --> > co-located PCE (when the path is computed by the head-end). --> > --> > [dp] hence, to BRPC as well --> > --> > b4) during the selection process no network conditions changes --> > (that would --> > make the returned result void) --> > --> > --> > Again, this applies to other cases as well. --> > --> > [dp] ditto --> > --> > --> > Ah so we agree here :-) --> > --> > What was your comment then ? --> > --> > [dp] that you need to include these set of working --> conditions in the --> > document itself, the document looks like quite simple in terms of --> > conditions for having the proposed method working as --> expected while when --> > you take a closer look at it this is not the case --> > --> > Thanks. --> > --> > JP. --> > --> > --> > --> > thanks. --> > --> > JP. --> > --> > --> > --> > --> > --> > --> > JP Vasseur --> > 23/06/2006 16:11 --> > --> > To: "Adrian Farrel" --> > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, --> > nabil.n.bitar@verizon.com --> > Subject: [Pce] Re: Comments on --> > draft-vasseur-pce-brpc-00.txt --> > --> > --> > Many Thanks Adrian for the comments. --> > --> > We incorporated the vast majority of them in the new --> revision (just --> > posted). --> > --> > See below for the comments requesting some clarification. --> > --> > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: --> > --> > Hi, --> > --> > Thanks for keeping these ideas alive. --> > --> > Here are some picky thoughts that you may want to include --> in the next --> > revision to make it more robust as a document. I don't --> have any issues --> > with --> > the basic process. --> > --> > Thanks, --> > Adrian --> > --> > == --> > Is this I-D likely to be Informational or Standards Track? From --> > Appendix --> > A, --> > this looks like Standards Track. Can you remove Appendix --> A and put the --> > status in the usual place in the header? --> > == --> > --> > Status has been updated (Informational) but let's discuss this --> > later on. --> > FYI, it does not appear on the front page when using the xml2rfc --> > editor --> > (which by the way is excellent), thus the appendix addition. --> > --> > It would be nice if the Abstract contained a pithy summary of brpc --> > and/or --> > gave the motivation for the draft. For example, what is the method --> > trying --> > to --> > achieve that isn't achievable by other methods? Or, what is the --> > fundamental --> > element of brpc that is not in other methods? --> > --> > Agree. Here is the new Abstract: --> > "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 (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) has been identified as a key --> > requirement . --> > This document specifies a procedure relying on the use of multiple --> > Path --> > Computation Elements (PCEs) in order to compute such inter-domain --> > shortest --> > constraint paths, using a backward recursive path computation --> > technique --> > while fully preserving confidentiality requirements --> across domains. " --> > --> > --> > == --> > I'm assuming that section 1 is for short term information only and --> > will be --> > deleted (in the next revision?) --> > == --> > --> > Indeed, just to provide a bit of history for the ones who --> have been --> > following inter-domain path computation for a while. --> > --> > == --> > Section 4 --> > - No topology or resource information is distributed --> between domains --> > (as mandated per [RFC4105] and [RFC4216]), which is critical to --> > preserve IGP/BGP scalability and confidentiality in the --> case of TE --> > LSPs spanning multiple domains. --> > You should clarify what you are saying here, because many would --> > argue that --> > reachability information (i.e. external routes) constitutes --> > topology and --> > resource information. --> > --> > --> > OK fine --> > --> > == --> > Section 4 --> > - While certain constraints like bandwidth can be used across --> > different domains, certain other TE constraints like resource --> > affinity, color, metric, etc. as listed in [RFC2702] could be --> > translated at domain boundaries. If required, it is assumed --> > that, at --> > the domain boundary LSRs, there will exist some sort of local --> > mapping --> > based on offline policy agreement, in order to translate such --> > constraints across domain boundaries during the inter-PCE --> > communication process. --> > Why does the policy agreement need to be offline? --> > --> > --> > It should actually read "pre-determined". Actually the best thing --> > to do --> > here is to remove "off-line" --> > --> > == --> > Section 5 --> > No assumption is made on the actual path computation algorithm in --> > use --> > by the PCE (it can be any variant of CSPF, algorithm based on --> > linear- --> > programming to solve multi-constraints optimization --> problems and so --> > on). --> > Suggest that you delete the text in parenthesis because --> it is making --> > suggestions that border on assumptions! --> > --> > Well I'd suggest to keep it as is since the point is to --> > differentiate the --> > path computation procedure from the algorithm to compute --> each intra- --> > domain --> > path segment. Furthermore, we'd like to highlight the --> fact that the --> > BRPC --> > procedure does not mandate for each PCE to use CSPF, --> could be other --> > algorithm. --> > --> > == --> > Section 5.1 and throughout --> > "BRPC path computation" seems to be tautologous --> > --> > It is actually a double tautology ;-) (fixed). --> > --> > == --> > Section 5.1 --> > I like the simplicity of section 5.1, but I think you --> need to point --> > out --> > that --> > if the sequence of domains is known a priori (can you --> determine it a --> > priori?) then the path computed might not be 'optimal' in --> the usual --> > sense --> > of --> > the word, but that this is OK because the ordered list of domains --> > constitutes an additional constraint on the computation so the --> > resultant --> > path *is* optimal within the constraints applied. --> > --> > Can't agree more. Good suggestion, thanks. --> > --> > Updated text: "The PCE-based BRPC procedure applies to the --> > computation of --> > an optimal constrained inter-domain TE LSP. The sequence --> of domains --> > to be --> > traversed can either be determined a priori or during the path --> > computation --> > procedure. The BRPC procedure guarantees to compute the --> optimal path --> > across a specific set of traversed domains (which constitutes --> > an additional constraint). In the case of an arbitrary --> set of meshed --> > domains, the BRPC procedure can be used to compute the --> optimal path --> > across --> > each domain set in order to get to optimal constrained --> path between --> > the --> > source and the destination of the TE LSP." --> > --> > == --> > Section 5.2 --> > The introduction of the term Virtual Shortest Path Tree is hard to --> > parse --> > and --> > to my mind the definition is arse about tit. I think you could --> > usefully --> > add --> > some textual definition of what the VSPT is trying to --> achieve, before --> > presenting it in pictorial or abstract form. --> > Even more important (I think) is the fact that the tree --> as presented --> > "represents the shortest path between the destination and BR-en --> > (j,i)..." --> > Frankly, we are building directional paths in exactly the oposite --> > direction! --> > --> > This is an abstract form of representation but see below, --> > --> > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP --> > tree as --> > described. --> > I suspect that this is just a textual descriptive issue --> rather than --> > anything --> > broken in the process. --> > --> > --> > I clarified the text to avoid any ambiguity (VSPT defined --> as a MP2P --> > tree). --> > --> > == --> > Section 5.2 --> > I suggest that you pull the note (Note: in term of --> computation...) out --> > into --> > a separate section. It doesn't belong in the middle of --> section 5.2. --> > You will probably want to re-write the text as well since the --> > unidirectional --> > limit is not necessary. Also to explain 'flood' - flood to where, --> > and how, --> > and by whom? And you will want to add to pieces of information: --> > - the link to the I-D that defines how to do this --> > - a description of what happens if this process is not used. --> > --> > This only works for unidirectional LSPs: indeed, the exit boundary --> > node --> > can flood TE-related data in its LSA/LSP for the link --> > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP --> > running on --> > the link but how would a node in domain (i) get the --> TE-related data --> > for --> > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the --> restriction on --> > unidirectional link. Are we in sync ? --> > --> > == --> > Section 5.2 --> > The paragraph that begins "BRPC guarantees to find the optimal..." --> > is a --> > nascent Applicability Statement. I suggest moving this to another --> > Section --> > and significantly beefing it up. You need to describe more fully: --> > - how ECMP works (the PCC has to request the return of more than --> > one path) --> > - how diversity works (i.e. section 9 fits in here) --> > - how some freedom of selection of domains can be offered --> > - how to mix the method with other mechanisms --> > --> > This was (and is) planned for future revision. Note that ECMP and --> > diversity are discussed already but we're planning the --> flesh out these --> > sections in further revision. --> > --> > == --> > Section 7 --> > If the BRPC procedure cannot be completed because a PCE along the --> > domain path does not support the procedure, a PCErr message is --> > returned by the upstream PCE with a Error-Type "BRPC procedure --> > completion failure". The PCErr message MUST be relayed to the --> > requesting PCC. --> > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) --> >does not --> > support brpc, presumably through capabilities --> > configuration/advertisement/negotiation, or whether PCE(n+1) is --> > supposed --> > to --> > respond to the path computation request saying that it does not --> > support --> > bit-V of the RP object. If the latter, presumably the --> PCErr comes from --> > PCE(n+1) and not from PCE(n) as documented. --> > --> > Good catch, typo: it should read "a PCErr message is --> returned to the --> > upstream". --> > The plan is to define a capability bit (IGP) in a further --> revision. --> > --> > == --> > Section 8 --> > Metric normalisation is a great potential solution, but --> how does it --> > fit --> > with --> > AS topology confidentiality? What is the solution to providing --> > discretion --> > about what TE connectivity is available within an AS, and --> operating --> > brpc? --> > --> > Metric normalization is handled locally by the PCE and does not --> > impact the --> > BRPC procedure per-say. As far as confidentiality is concerned, --> > this only --> > requires for the SPs to exchange metric mapping --> information (nothing --> > related to the network topology or resources); for example --> > SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 --> > SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 --> > --> > A simple metric normalization can then be performed on the PCE --> > thanks to --> > simple cost mapping tables. --> > --> > Section 10 --> > Some of this text has been seen before in this I-D --> > Why do you single out LSP stitching as possibly breaking --> end-to-end --> > optimality. There is functionally no difference between --> stitching and --> > nesting in this respect. --> > But further, your statement about stitching is pejorative! If you --> > say that --> > "In the case where a domain has more than one BR-en or --> more than one --> > BR-ex, --> > optimality after some network change within the domain can only be --> > guaranteed by re-executing the full brpc computation" then I would --> > agree --> > with you. But as phrased, it implies that making a per-domain --> > re-optimisation could make the path *less* optimal. This (of --> > course) is --> > not --> > the case - per-domain optimisation will always improve or --> leave the --> > same --> > end-to-end optimality (in the case where new resources are made --> > available --> > this is obvious; in the case of a network failure, *any* path is --> > better --> > than --> > no path!) --> > And, lastly, the text about re-optimisation belongs in the next --> > section, --> > not --> > in this section. --> > --> > --> > Yes I wanted to leave that text to keep track of who --> would read the --> > ID, --> > expecting reaction ;-)) Per-domain reoptimization would always --> > improve the --> > current path *but* in case of stitched LSPs, TE LSP segments are --> > computed --> > by the stitching point; thus in case of failure, they could end up --> > following a non optimal path whereas in the case of --> contiguous LSP, --> > the --> > BRPC procedure would be called again thus leading to the --> optimal path --> > again. The point that I was trying to make is "if you have a --> > stitched LSP --> > and rely on BRPC when first signaled in an attempt to get an --> > optimal path, --> > you need to consider the interaction between the local reopt mode --> > and BRPC --> > if the goal is to preserve an optimal path at any given --> time". Anyway, --> > we're on the same page and I agree and the text should be reworded --> > according to your proposal to avoid any misunderstanding. --> > --> > == --> > Section 13 --> > I would like you to discuss the issues of confidentiality --> of topology --> > information at greater length. It seems that you would --> possibly use --> > this --> > technique in conjunction with path cookies, which is --> fine. But, are --> > there --> > two things you cannot escape from? --> > - indicating which BR-en provides best connectivity --> > - indicating the metric for multiple BR-ens --> > Maybe there are some things that can be done here based on policy, --> > including --> > not reporting all of the BR-ens, ranking rather than --> giving absolute --> > metrics, etc. But these would compromise optimality. --> > --> > Indeed. --> > --> > Maybe the PCE(n+1) should carefully monitor and limit --> > (statistically and --> > by --> > policy) brpc requests so that excessive information is --> not divulged? --> > --> > Since one of objectives for using the BRPC procedure is --> to compute an --> > optimal path, we need to know at least the BN (Boundary --> Nodes) and the --> > cost. --> > --> > == --> > I wouldn't mind seeing a Management Considerations section. --> > Do we need to be able to examine the pruned pieces of --> VSPT at transit --> > PCEs? --> > What are the implications of reporting multiple VSPT branches in --> > PCEP to --> > the --> > MIB modules? --> > Is brpc support something that needs to be configured: --> per PCE?; per --> > PCE-neighbor? --> > What are the implications on existing protocols (IGPs? --> PCEP?) of using --> > brpc? --> > --> > Absolutely ! I put a placeholder for a further revision. --> > --> > Fully supportive of adding such section. --> > --> > Many Thanks for your comments ! --> > --> > JP. --> > --> > etc. --> > == --> > --> > --> > --> > --> > --> > I think Jean-Louis' email address needs updating --> > --> > --> > == --> > The document would benefit from a little care in the formatting, --> > and you --> > could usefully re-read it for missing words, etc. --> > == --> > _______________________________________________ --> > Pce mailing list --> > Pce@lists.ietf.org --> > https://www1.ietf.org/mailman/listinfo/pce --> > _______________________________________________ --> > Pce mailing list --> > Pce@lists.ietf.org --> > https://www1.ietf.org/mailman/listinfo/pce --> > --> > --> > --> > _______________________________________________ --> > Pce mailing list --> > Pce@lists.ietf.org --> > https://www1.ietf.org/mailman/listinfo/pce --> > --> > --> > --> --> --> --> _______________________________________________ --> Pce mailing list --> Pce@lists.ietf.org --> https://www1.ietf.org/mailman/listinfo/pce --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 09:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurUJ-0006R6-Al; Mon, 26 Jun 2006 09:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurUH-0006Pj-U9 for pce@ietf.org; Mon, 26 Jun 2006 09:50:50 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurUG-00016L-Mo for pce@ietf.org; Mon, 26 Jun 2006 09:50:49 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 15:50:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 15:50:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Thread-Index: AcaZItlov27C8Wy0Q2uRAtzF7ipfoQABKILg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 26 Jun 2006 13:50:47.0791 (UTC) FILETIME=[873687F0:01C69927] X-Spam-Score: 0.0 (/) X-Scan-Signature: e07cb4561b0bc070cf5c9de2a587f312 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 >Do we all agree with these statements?=20 Fully Agree JL > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : lundi 26 juin 2006 15:14 > =C0 : Dimitri.Papadimitriou@alcatel.be > Cc : pce@ietf.org > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 > Hi, >=20 > I'm trying to parse something out of this thread. >=20 > 1. It is clear that brpc *demands* that the sequence of domains > is already known before brpc is executed. > In my opinion, this is clear in the I-D, but it would not hurt to > make it clearer. > A statement in the Abstract and Introduction would achieve > this. >=20 > 2. The mechanism by which the sequence of domains is known > is out of scope for the procedure. > It is not clear whether this is a limitation of the process, or > not. But in my opinion this is consistent with the guidance > that the WG received from the IAB when we were chartered. > We are not trying to 'solve the Internet', so selection of > domains is out of scope. >=20 > 3. brpc *does* include mechanisms for the selection of interdomain > links and/or nodes. This is more complex than the simple selection > of these points of attachment because the connection to use may > depend on the TE paths within the domains. > IMO, brpc is constructed specifically for this purpose. If we did > not need this function, we could use pd-path computation with > visibility of the inter-domain TE links. >=20 > 4. The discussion is not helped by debate about the precise wording > around 'constraint'. > Let us say that "the sequence of domains to be traversed is > provided by an external source as a limiting factor to the=20 > computation > or choice of paths." >=20 > Do we all agree with these statements? >=20 > Cheers, > Adrian >=20 > ----- Original Message ----- > From: > To: "JP Vasseur" > Cc: ;=20 > ; > Sent: Monday, June 26, 2006 7:51 AM > Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 >=20 > > hi j-p - see in-line > > > > > > > > > > JP Vasseur > > 26/06/2006 02:42 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: nabil.n.bitar@verizon.com, pce@ietf.org, > > raymond_zhang@bt.infonet.com > > Subject: Re: [Pce] Re: Comments on > > draft-vasseur-pce-brpc-00.txt > > > > > > hi dimitri, > > > > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > > hi j-p - see in-line > > > > > > > > > > JP Vasseur > > 26/06/2006 01:14 > > > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: "Adrian Farrel" , > > nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond_zhang@bt.infonet.com > > Subject: Re: [Pce] Re: Comments on > > draft-vasseur-pce-brpc-00.txt > > > > > > hi dimitiri, > > > > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > > > the following comment was also discussed during last meeting > > > > "=3D=3D > > Section 5.1 > > I like the simplicity of section 5.1, but I think you need to point=20 > > out that if the sequence of domains is known a priori (can you=20 > > determine it a > > priori?) then the path computed might not be 'optimal' in the usual=20 > > sense of the word, but that this is OK because the ordered list of=20 > > domains constitutes an additional constraint on the=20 > computation so the=20 > > resultant path *is* optimal within the constraints applied. > > > > Can't agree more. Good suggestion, thanks. > > > > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation=20 > > of an optimal constrained inter-domain TE LSP. The sequence=20 > of domains=20 > > to be traversed can either be determined a priori or during=20 > the path=20 > > computation procedure. The BRPC procedure guarantees to compute the=20 > > optimal path across a specific set of traversed domains (which=20 > > constitutes an additional constraint). In the case of an=20 > arbitrary set=20 > > of meshed domains, the BRPC procedure can be used to compute the=20 > > optimal path across each domain set in order to get to optimal=20 > > constrained path between the source and the destination of the TE=20 > > LSP." > > > > =3D> in brief, how to determine the sequence through which path=20 > > computation has to be performed because if this sequence was known=20 > > there is no need for such procedure (only inter-domain link=20 > selection=20 > > would be > > required) - > > > > Not correct; even if you know the sequence you still need the BRPC=20 > > procedure to figure out the set of BN (boundary Nodes) to=20 > traverse to=20 > > get the shortest inter-domain TE LSP: this is the whole issue with=20 > > inter-domain, otherwise per-domain path computation would=20 > be sufficient. > > > > [dp] inter-domain link selection (as i mentioned) implies what you=20 > > mean with boundary nodes selection - you could rephrase by=20 > access/exit=20 > > point selection exact same business > > > > but again even if you know the sequence you still need BRPC to=20 > > determine the set of BN (or exit point - same thing) that will give=20 > > you the shortest inter-domain path. Look you wrote "in=20 > brief, how to=20 > > determine the sequence through which path computation has to be=20 > > performed because if this sequence was known there is no=20 > need for such=20 > > procedure", which is not correct. Even if you know the sequence of=20 > > domains, you still need the procedure to get the exit/entry point=20 > > (named BN) that provide you the shortest inter-domain path. > > > > > > now adrian mentions that pre- determination becomes a new=20 > constraint -=20 > > well actually this is not a constraint for the TE LSP itself but a=20 > > restriction on the domain set known to be (a-priori)=20 > supportive of the=20 > > method such as to make the method not returning an error message > > > > > > No, this is a constraint: "Give me the shortest path=20 > (potentially made=20 > > of loose hops (the BNs)) that provides the shortest end to=20 > end path,=20 > > considering that the additional constraint is to traverse the=20 > > following set of domains . > > > > [dp] incorrect, this is not a "TE LSP" constraint - > > > > Who said that this was a TE LSP constraint ? This is *a*=20 > constraint.=20 > > If you impose the set of domain, this is a constraint. > > > > Please read the text: "The BRPC procedure guarantees to compute the=20 > > optimal path across a specific set of traversed domains (which=20 > > constitutes an additional constraint)." > > > > [dp] i read this, mind you, my point is that this is not a=20 > > "constraint" of the same nature as the one you're making=20 > use such as=20 > > minimize delays or whatsover - this constraint is=20 > introduced from the=20 > > computation technique and mechanism of this proposed method > > > > Note that at this point, I still do not see the point that you're=20 > > trying to make here ? > > > > since so far when > > a set of domains do not support/or support a given=20 > computation has not=20 > > yet become a constraint > > > > hence sentence "The BRPC procedure guarantees to compute=20 > the optimal=20 > > path across a specific set of traversed domains (which=20 > constitutes an=20 > > additional constraint). In the case of an arbitrary set of meshed=20 > > domains, the BRPC procedure can be used to compute the optimal path=20 > > across each domain set in order to get to optimal constrained path=20 > > between the source and the destination of the TE LSP." > > > > should as far as i understand the method fulfill the following > > > > a) this method provides a result iff all domains traversed by the=20 > > request support the proposed method > > > > BRPC is a multi-PCE based approach where you need at least one PCE=20 > > per-domain. > > > > [dp] indeed, but one PCE supporting that method and having FULL=20 > > visibility of the domain > > > > So what is your point here ? > > > > [dp] that the set of conditions to have this method=20 > workable is larger=20 > > than the one listed in this doc. > > > > b) this method provides an "optimal" result iff > > > > b1) all possible sequences of domains have been traversed (starting=20 > > from the root) and are supportive of that method - as there=20 > might be=20 > > an optimal path through a domain not supporting this method - > > > > > > heu ... yes indeed. If a domain does not support the method, the > > method cannot be used to compute the path. > > > > b2) there is no discontinuity in the availability of the=20 > inter-AS link > > information on each PCE performing a given selection -=20 > indeed a domain > > might be supportive of the method without supporting inter-AS link > > flooding > > > > No this is not a requirement, just an optimization. The only > > requirement is for the PCE to get the TE-related data about=20 > the Inter- > > AS links. I'll detail a bit more in the next revision. > > > > [dp] then you can never achieve - > > > > You can never achieve what ? > > > > Sorry Dimitri, I'd love to accommodate your comment but I=20 > do not see your > > point ... hopefully we'll have a bit of time in Montreal to=20 > discuss if > > that does not work by email. > > > > [dp] my point is that without this additional information=20 > you can not > > achieve the expected result - i pointed to your own text to=20 > indicate that > > this information is a must have in order to achieve this objective > > > > using your own words to make it more > > straighforward - > > > > "you still need the BRPC procedure to figure out the set of=20 > BN (boundary > > Nodes) to traverse to get the shortest inter-domain TE LSP:=20 > this is the > > whole issue with inter-domain, otherwise per-domain path computation > > would > > > > be sufficient." > > > > b3) at each step there is no PCE that has partial visibility of a > > given > > domain > > > > > > This is not specific to BRPC. Even with intra-domain if you want to > > compute the path for a TE LSP, you cannot always use the PCE if it > > has a partial visibility. Note that this also applies to the case of > > co-located PCE (when the path is computed by the head-end). > > > > [dp] hence, to BRPC as well > > > > b4) during the selection process no network conditions changes > > (that would > > make the returned result void) > > > > > > Again, this applies to other cases as well. > > > > [dp] ditto > > > > > > Ah so we agree here :-) > > > > What was your comment then ? > > > > [dp] that you need to include these set of working conditions in the > > document itself, the document looks like quite simple in terms of > > conditions for having the proposed method working as=20 > expected while when > > you take a closer look at it this is not the case > > > > Thanks. > > > > JP. > > > > > > > > thanks. > > > > JP. > > > > > > > > > > > > > > JP Vasseur > > 23/06/2006 16:11 > > > > To: "Adrian Farrel" > > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > > nabil.n.bitar@verizon.com > > Subject: [Pce] Re: Comments on > > draft-vasseur-pce-brpc-00.txt > > > > > > Many Thanks Adrian for the comments. > > > > We incorporated the vast majority of them in the new revision (just > > posted). > > > > See below for the comments requesting some clarification. > > > > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > > > > Hi, > > > > Thanks for keeping these ideas alive. > > > > Here are some picky thoughts that you may want to include=20 > in the next > > revision to make it more robust as a document. I don't have=20 > any issues > > with > > the basic process. > > > > Thanks, > > Adrian > > > > =3D=3D > > Is this I-D likely to be Informational or Standards Track? From > > Appendix > > A, > > this looks like Standards Track. Can you remove Appendix A=20 > and put the > > status in the usual place in the header? > > =3D=3D > > > > Status has been updated (Informational) but let's discuss this > > later on. > > FYI, it does not appear on the front page when using the xml2rfc > > editor > > (which by the way is excellent), thus the appendix addition. > > > > It would be nice if the Abstract contained a pithy summary of brpc > > and/or > > gave the motivation for the draft. For example, what is the method > > trying > > to > > achieve that isn't achievable by other methods? Or, what is the > > fundamental > > element of brpc that is not in other methods? > > > > Agree. Here is the new Abstract: > > "The ability to compute constrained shortest Traffic=20 > Engineering (TE) > > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) > > and > > Generalized MPLS (GMPLS) networks across 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=20 > such as IGP > > areas and Autonomous Systems) has been identified as a key > > requirement . > > This document specifies a procedure relying on the use of multiple > > Path > > Computation Elements (PCEs) in order to compute such inter-domain > > shortest > > constraint paths, using a backward recursive path computation > > technique > > while fully preserving confidentiality requirements across=20 > domains. " > > > > > > =3D=3D > > I'm assuming that section 1 is for short term information only and > > will be > > deleted (in the next revision?) > > =3D=3D > > > > Indeed, just to provide a bit of history for the ones who have been > > following inter-domain path computation for a while. > > > > =3D=3D > > Section 4 > > - No topology or resource information is distributed=20 > between domains > > (as mandated per [RFC4105] and [RFC4216]), which is critical to > > preserve IGP/BGP scalability and confidentiality in the case of TE > > LSPs spanning multiple domains. > > You should clarify what you are saying here, because many would > > argue that > > reachability information (i.e. external routes) constitutes > > topology and > > resource information. > > > > > > OK fine > > > > =3D=3D > > Section 4 > > - While certain constraints like bandwidth can be used across > > different domains, certain other TE constraints like resource > > affinity, color, metric, etc. as listed in [RFC2702] could be > > translated at domain boundaries. If required, it is assumed > > that, at > > the domain boundary LSRs, there will exist some sort of local > > mapping > > based on offline policy agreement, in order to translate such > > constraints across domain boundaries during the inter-PCE > > communication process. > > Why does the policy agreement need to be offline? > > > > > > It should actually read "pre-determined". Actually the best thing > > to do > > here is to remove "off-line" > > > > =3D=3D > > Section 5 > > No assumption is made on the actual path computation algorithm in > > use > > by the PCE (it can be any variant of CSPF, algorithm based on > > linear- > > programming to solve multi-constraints optimization problems and so > > on). > > Suggest that you delete the text in parenthesis because it is making > > suggestions that border on assumptions! > > > > Well I'd suggest to keep it as is since the point is to > > differentiate the > > path computation procedure from the algorithm to compute each intra- > > domain > > path segment. Furthermore, we'd like to highlight the fact that the > > BRPC > > procedure does not mandate for each PCE to use CSPF, could be other > > algorithm. > > > > =3D=3D > > Section 5.1 and throughout > > "BRPC path computation" seems to be tautologous > > > > It is actually a double tautology ;-) (fixed). > > > > =3D=3D > > Section 5.1 > > I like the simplicity of section 5.1, but I think you need to point > > out > > that > > if the sequence of domains is known a priori (can you determine it a > > priori?) then the path computed might not be 'optimal' in the usual > > sense > > of > > the word, but that this is OK because the ordered list of domains > > constitutes an additional constraint on the computation so the > > resultant > > path *is* optimal within the constraints applied. > > > > Can't agree more. Good suggestion, thanks. > > > > Updated text: "The PCE-based BRPC procedure applies to the > > computation of > > an optimal constrained inter-domain TE LSP. The sequence of domains > > to be > > traversed can either be determined a priori or during the path > > computation > > procedure. The BRPC procedure guarantees to compute the optimal path > > across a specific set of traversed domains (which constitutes > > an additional constraint). In the case of an arbitrary set of meshed > > domains, the BRPC procedure can be used to compute the optimal path > > across > > each domain set in order to get to optimal constrained path between > > the > > source and the destination of the TE LSP." > > > > =3D=3D > > Section 5.2 > > The introduction of the term Virtual Shortest Path Tree is hard to > > parse > > and > > to my mind the definition is arse about tit. I think you could > > usefully > > add > > some textual definition of what the VSPT is trying to=20 > achieve, before > > presenting it in pictorial or abstract form. > > Even more important (I think) is the fact that the tree as presented > > "represents the shortest path between the destination and BR-en > > (j,i)..." > > Frankly, we are building directional paths in exactly the oposite > > direction! > > > > This is an abstract form of representation but see below, > > > > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP > > tree as > > described. > > I suspect that this is just a textual descriptive issue rather than > > anything > > broken in the process. > > > > > > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P > > tree). > > > > =3D=3D > > Section 5.2 > > I suggest that you pull the note (Note: in term of=20 > computation...) out > > into > > a separate section. It doesn't belong in the middle of section 5.2. > > You will probably want to re-write the text as well since the > > unidirectional > > limit is not necessary. Also to explain 'flood' - flood to where, > > and how, > > and by whom? And you will want to add to pieces of information: > > - the link to the I-D that defines how to do this > > - a description of what happens if this process is not used. > > > > This only works for unidirectional LSPs: indeed, the exit boundary > > node > > can flood TE-related data in its LSA/LSP for the link > > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP > > running on > > the link but how would a node in domain (i) get the TE-related data > > for > > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the=20 > restriction on > > unidirectional link. Are we in sync ? > > > > =3D=3D > > Section 5.2 > > The paragraph that begins "BRPC guarantees to find the optimal..." > > is a > > nascent Applicability Statement. I suggest moving this to another > > Section > > and significantly beefing it up. You need to describe more fully: > > - how ECMP works (the PCC has to request the return of more than > > one path) > > - how diversity works (i.e. section 9 fits in here) > > - how some freedom of selection of domains can be offered > > - how to mix the method with other mechanisms > > > > This was (and is) planned for future revision. Note that ECMP and > > diversity are discussed already but we're planning the=20 > flesh out these > > sections in further revision. > > > > =3D=3D > > Section 7 > > If the BRPC procedure cannot be completed because a PCE along the > > domain path does not support the procedure, a PCErr message is > > returned by the upstream PCE with a Error-Type "BRPC procedure > > completion failure". The PCErr message MUST be relayed to the > > requesting PCC. > > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) > >does not > > support brpc, presumably through capabilities > > configuration/advertisement/negotiation, or whether PCE(n+1) is > > supposed > > to > > respond to the path computation request saying that it does not > > support > > bit-V of the RP object. If the latter, presumably the PCErr=20 > comes from > > PCE(n+1) and not from PCE(n) as documented. > > > > Good catch, typo: it should read "a PCErr message is returned to the > > upstream". > > The plan is to define a capability bit (IGP) in a further revision. > > > > =3D=3D > > Section 8 > > Metric normalisation is a great potential solution, but how does it > > fit > > with > > AS topology confidentiality? What is the solution to providing > > discretion > > about what TE connectivity is available within an AS, and operating > > brpc? > > > > Metric normalization is handled locally by the PCE and does not > > impact the > > BRPC procedure per-say. As far as confidentiality is concerned, > > this only > > requires for the SPs to exchange metric mapping information (nothing > > related to the network topology or resources); for example > > SP 1 Links Cost =3D F (link_bandwidth) with F (OC192)=3D1 > > SP 2 Links Cost =3D F (link_bandwidth) with F (OC192)=3D10 > > > > A simple metric normalization can then be performed on the PCE > > thanks to > > simple cost mapping tables. > > > > Section 10 > > Some of this text has been seen before in this I-D > > Why do you single out LSP stitching as possibly breaking end-to-end > > optimality. There is functionally no difference between=20 > stitching and > > nesting in this respect. > > But further, your statement about stitching is pejorative! If you > > say that > > "In the case where a domain has more than one BR-en or more than one > > BR-ex, > > optimality after some network change within the domain can only be > > guaranteed by re-executing the full brpc computation" then I would > > agree > > with you. But as phrased, it implies that making a per-domain > > re-optimisation could make the path *less* optimal. This (of > > course) is > > not > > the case - per-domain optimisation will always improve or leave the > > same > > end-to-end optimality (in the case where new resources are made > > available > > this is obvious; in the case of a network failure, *any* path is > > better > > than > > no path!) > > And, lastly, the text about re-optimisation belongs in the next > > section, > > not > > in this section. > > > > > > Yes I wanted to leave that text to keep track of who would read the > > ID, > > expecting reaction ;-)) Per-domain reoptimization would always > > improve the > > current path *but* in case of stitched LSPs, TE LSP segments are > > computed > > by the stitching point; thus in case of failure, they could end up > > following a non optimal path whereas in the case of contiguous LSP, > > the > > BRPC procedure would be called again thus leading to the=20 > optimal path > > again. The point that I was trying to make is "if you have a > > stitched LSP > > and rely on BRPC when first signaled in an attempt to get an > > optimal path, > > you need to consider the interaction between the local reopt mode > > and BRPC > > if the goal is to preserve an optimal path at any given=20 > time". Anyway, > > we're on the same page and I agree and the text should be reworded > > according to your proposal to avoid any misunderstanding. > > > > =3D=3D > > Section 13 > > I would like you to discuss the issues of confidentiality=20 > of topology > > information at greater length. It seems that you would possibly use > > this > > technique in conjunction with path cookies, which is fine. But, are > > there > > two things you cannot escape from? > > - indicating which BR-en provides best connectivity > > - indicating the metric for multiple BR-ens > > Maybe there are some things that can be done here based on policy, > > including > > not reporting all of the BR-ens, ranking rather than giving absolute > > metrics, etc. But these would compromise optimality. > > > > Indeed. > > > > Maybe the PCE(n+1) should carefully monitor and limit > > (statistically and > > by > > policy) brpc requests so that excessive information is not divulged? > > > > Since one of objectives for using the BRPC procedure is to=20 > compute an > > optimal path, we need to know at least the BN (Boundary=20 > Nodes) and the > > cost. > > > > =3D=3D > > I wouldn't mind seeing a Management Considerations section. > > Do we need to be able to examine the pruned pieces of VSPT=20 > at transit > > PCEs? > > What are the implications of reporting multiple VSPT branches in > > PCEP to > > the > > MIB modules? > > Is brpc support something that needs to be configured: per PCE?; per > > PCE-neighbor? > > What are the implications on existing protocols (IGPs?=20 > PCEP?) of using > > brpc? > > > > Absolutely ! I put a placeholder for a further revision. > > > > Fully supportive of adding such section. > > > > Many Thanks for your comments ! > > > > JP. > > > > etc. > > =3D=3D > > > > > > > > > > > > I think Jean-Louis' email address needs updating > > > > > > =3D=3D > > The document would benefit from a little care in the formatting, > > and you > > could usefully re-read it for missing words, etc. > > =3D=3D > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > > >=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 09:53:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurXK-0002CJ-O9; Mon, 26 Jun 2006 09:53:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurXJ-0002CB-Tx for pce@ietf.org; Mon, 26 Jun 2006 09:53:57 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FurXH-0001DF-Gv for pce@ietf.org; Mon, 26 Jun 2006 09:53:57 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-126.messagelabs.com!1151330010!9005126!4 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 25510 invoked from network); 26 Jun 2006 13:53:53 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-126.messagelabs.com with SMTP; 26 Jun 2006 13:53:53 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB4520000CFEB; Mon, 26 Jun 2006 09:53:50 -0400 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 Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 08:53:50 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC79E4@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Thread-Index: AcaZItlov27C8Wy0Q2uRAtzF7ipfoQABKILgAAATmhA= From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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 > Do we all agree with these statements? Also agree. Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 10:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Furpy-0000gr-NJ; Mon, 26 Jun 2006 10:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Furpx-0000gj-Jx for pce@ietf.org; Mon, 26 Jun 2006 10:13:13 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Furpw-00033G-Aj for pce@ietf.org; Mon, 26 Jun 2006 10:13:13 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5QEDAh4027620; Mon, 26 Jun 2006 16:13:10 +0200 In-Reply-To: <02b101c69922$cbad5530$0a23fea9@your029b8cecfe> To: "Adrian Farrel" Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 26 Jun 2006 16:13:08 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/26/2006 16:13:09, Serialize complete at 06/26/2006 16:13:09 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: dfec89f65e469387666e36fc1e4e3b22 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 adrian - ok (nice summary) - i think the whole debate is on point 2) since last meeting discussions - if one agrees that we don't solve this issue - then being aware upfront/descriptive of limitations, conditions and workability is really appropriated - let's assume this is (hopefully) the case the more important implication is point 3) - if this inter-domain link is not provided - de facto - as part of the method what does this method really provides ? i mean section 7. reads as if you can not flood just makes PCE aware of that TE data; however, point on whether this info is flooded or passed to the PCE or not the main issue is how this information is locally obtained ? what does happen if this information is only partially or not known, changing conditions, a unidirectional LSP reserves bandwidth downstream how accounting occurs (edges need to be aware of forward and reverse bandwidth), etc. thanks, - dimitri. "Adrian Farrel" 26/06/2006 15:14 Please respond to "Adrian Farrel" To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Hi, I'm trying to parse something out of this thread. 1. It is clear that brpc *demands* that the sequence of domains is already known before brpc is executed. In my opinion, this is clear in the I-D, but it would not hurt to make it clearer. A statement in the Abstract and Introduction would achieve this. 2. The mechanism by which the sequence of domains is known is out of scope for the procedure. It is not clear whether this is a limitation of the process, or not. But in my opinion this is consistent with the guidance that the WG received from the IAB when we were chartered. We are not trying to 'solve the Internet', so selection of domains is out of scope. 3. brpc *does* include mechanisms for the selection of interdomain links and/or nodes. This is more complex than the simple selection of these points of attachment because the connection to use may depend on the TE paths within the domains. IMO, brpc is constructed specifically for this purpose. If we did not need this function, we could use pd-path computation with visibility of the inter-domain TE links. 4. The discussion is not helped by debate about the precise wording around 'constraint'. Let us say that "the sequence of domains to be traversed is provided by an external source as a limiting factor to the computation or choice of paths." Do we all agree with these statements? Cheers, Adrian ----- Original Message ----- From: To: "JP Vasseur" Cc: ; ; Sent: Monday, June 26, 2006 7:51 AM Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt > hi j-p - see in-line > > > > > JP Vasseur > 26/06/2006 02:42 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org, > raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > hi dimitri, > > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > hi j-p - see in-line > > > > > JP Vasseur > 26/06/2006 01:14 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" , > nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > hi dimitiri, > > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > > the following comment was also discussed during last meeting > > "== > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > => in brief, how to determine the sequence through which path > computation > has to be performed because if this sequence was known there is no > need > for such procedure (only inter-domain link selection would be > required) - > > Not correct; even if you know the sequence you still need the BRPC > procedure to figure out the set of BN (boundary Nodes) to traverse to > get the shortest inter-domain TE LSP: this is the whole issue with > inter-domain, otherwise per-domain path computation would be sufficient. > > [dp] inter-domain link selection (as i mentioned) implies what you mean > with boundary nodes selection - you could rephrase by access/exit point > selection exact same business > > but again even if you know the sequence you still need BRPC to determine > the set of BN (or exit point - same thing) that will give you the shortest > inter-domain path. Look you wrote "in brief, how to determine the sequence > through which path computation has to be performed because if this > sequence was known there is no need for such procedure", which is not > correct. Even if you know the sequence of domains, you still need the > procedure to get the exit/entry point (named BN) that provide you the > shortest inter-domain path. > > > now adrian mentions that pre- determination becomes a new constraint - > well actually this is not a constraint for the TE LSP itself but a > restriction on the domain set known to be (a-priori) supportive of the > method such as to make the method not returning an error message > > > No, this is a constraint: "Give me the shortest path (potentially > made of loose hops (the BNs)) that provides the shortest end to end > path, considering that the additional constraint is to traverse the > following set of domains . > > [dp] incorrect, this is not a "TE LSP" constraint - > > Who said that this was a TE LSP constraint ? This is *a* constraint. If > you impose the set of domain, this is a constraint. > > Please read the text: "The BRPC procedure guarantees to compute the > optimal path across a specific set of traversed domains (which constitutes > an additional constraint)." > > [dp] i read this, mind you, my point is that this is not a "constraint" of > the same nature as the one you're making use such as minimize delays or > whatsover - this constraint is introduced from the computation technique > and mechanism of this proposed method > > Note that at this point, I still do not see the point that you're trying > to make here ? > > since so far when > a set of domains do not support/or support a given computation has not > yet become a constraint > > hence sentence "The BRPC procedure guarantees to compute the > optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > should as far as i understand the method fulfill the following > > a) this method provides a result iff all domains traversed by the > request > support the proposed method > > BRPC is a multi-PCE based approach where you need at least one PCE > per-domain. > > [dp] indeed, but one PCE supporting that method and having FULL > visibility of the domain > > So what is your point here ? > > [dp] that the set of conditions to have this method workable is larger > than the one listed in this doc. > > b) this method provides an "optimal" result iff > > b1) all possible sequences of domains have been traversed (starting > from > the root) and are supportive of that method - as there might be an > optimal > path through a domain not supporting this method - > > > heu ... yes indeed. If a domain does not support the method, the > method cannot be used to compute the path. > > b2) there is no discontinuity in the availability of the inter-AS link > information on each PCE performing a given selection - indeed a domain > might be supportive of the method without supporting inter-AS link > flooding > > No this is not a requirement, just an optimization. The only > requirement is for the PCE to get the TE-related data about the Inter- > AS links. I'll detail a bit more in the next revision. > > [dp] then you can never achieve - > > You can never achieve what ? > > Sorry Dimitri, I'd love to accommodate your comment but I do not see your > point ... hopefully we'll have a bit of time in Montreal to discuss if > that does not work by email. > > [dp] my point is that without this additional information you can not > achieve the expected result - i pointed to your own text to indicate that > this information is a must have in order to achieve this objective > > using your own words to make it more > straighforward - > > "you still need the BRPC procedure to figure out the set of BN (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP: this is the > whole issue with inter-domain, otherwise per-domain path computation > would > > be sufficient." > > b3) at each step there is no PCE that has partial visibility of a > given > domain > > > This is not specific to BRPC. Even with intra-domain if you want to > compute the path for a TE LSP, you cannot always use the PCE if it > has a partial visibility. Note that this also applies to the case of > co-located PCE (when the path is computed by the head-end). > > [dp] hence, to BRPC as well > > b4) during the selection process no network conditions changes > (that would > make the returned result void) > > > Again, this applies to other cases as well. > > [dp] ditto > > > Ah so we agree here :-) > > What was your comment then ? > > [dp] that you need to include these set of working conditions in the > document itself, the document looks like quite simple in terms of > conditions for having the proposed method working as expected while when > you take a closer look at it this is not the case > > Thanks. > > JP. > > > > thanks. > > JP. > > > > > > > JP Vasseur > 23/06/2006 16:11 > > To: "Adrian Farrel" > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > Many Thanks Adrian for the comments. > > We incorporated the vast majority of them in the new revision (just > posted). > > See below for the comments requesting some clarification. > > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > > Hi, > > Thanks for keeping these ideas alive. > > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. > > Thanks, > Adrian > > == > Is this I-D likely to be Informational or Standards Track? From > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > == > > Status has been updated (Informational) but let's discuss this > later on. > FYI, it does not appear on the front page when using the xml2rfc > editor > (which by the way is excellent), thus the appendix addition. > > It would be nice if the Abstract contained a pithy summary of brpc > and/or > gave the motivation for the draft. For example, what is the method > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? > > Agree. Here is the new Abstract: > "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 (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) has been identified as a key > requirement . > This document specifies a procedure relying on the use of multiple > Path > Computation Elements (PCEs) in order to compute such inter-domain > shortest > constraint paths, using a backward recursive path computation > technique > while fully preserving confidentiality requirements across domains. " > > > == > I'm assuming that section 1 is for short term information only and > will be > deleted (in the next revision?) > == > > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. > > == > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would > argue that > reachability information (i.e. external routes) constitutes > topology and > resource information. > > > OK fine > > == > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed > that, at > the domain boundary LSRs, there will exist some sort of local > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? > > > It should actually read "pre-determined". Actually the best thing > to do > here is to remove "off-line" > > == > Section 5 > No assumption is made on the actual path computation algorithm in > use > by the PCE (it can be any variant of CSPF, algorithm based on > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! > > Well I'd suggest to keep it as is since the point is to > differentiate the > path computation procedure from the algorithm to compute each intra- > domain > path segment. Furthermore, we'd like to highlight the fact that the > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. > > == > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous > > It is actually a double tautology ;-) (fixed). > > == > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the > resultant > path *is* optimal within the constraints applied. > > Can't agree more. Good suggestion, thanks. > > Updated text: "The PCE-based BRPC procedure applies to the > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains > to be > traversed can either be determined a priori or during the path > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path > across > each domain set in order to get to optimal constrained path between > the > source and the destination of the TE LSP." > > == > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to > parse > and > to my mind the definition is arse about tit. I think you could > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! > > This is an abstract form of representation but see below, > > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. > > > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P > tree). > > == > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where, > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. > > This only works for unidirectional LSPs: indeed, the exit boundary > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP > running on > the link but how would a node in domain (i) get the TE-related data > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? > > == > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..." > is a > nascent Applicability Statement. I suggest moving this to another > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms > > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. > > == > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is > supposed > to > respond to the path computation request saying that it does not > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. > > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. > > == > Section 8 > Metric normalisation is a great potential solution, but how does it > fit > with > AS topology confidentiality? What is the solution to providing > discretion > about what TE connectivity is available within an AS, and operating > brpc? > > Metric normalization is handled locally by the PCE and does not > impact the > BRPC procedure per-say. As far as confidentiality is concerned, > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 > SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 > > A simple metric normalization can then be performed on the PCE > thanks to > simple cost mapping tables. > > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of > course) is > not > the case - per-domain optimisation will always improve or leave the > same > end-to-end optimality (in the case where new resources are made > available > this is obvious; in the case of a network failure, *any* path is > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next > section, > not > in this section. > > > Yes I wanted to leave that text to keep track of who would read the > ID, > expecting reaction ;-)) Per-domain reoptimization would always > improve the > current path *but* in case of stitched LSPs, TE LSP segments are > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP, > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a > stitched LSP > and rely on BRPC when first signaled in an attempt to get an > optimal path, > you need to consider the interaction between the local reopt mode > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. > > == > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use > this > technique in conjunction with path cookies, which is fine. But, are > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. > > Indeed. > > Maybe the PCE(n+1) should carefully monitor and limit > (statistically and > by > policy) brpc requests so that excessive information is not divulged? > > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. > > == > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? > > Absolutely ! I put a placeholder for a further revision. > > Fully supportive of adding such section. > > Many Thanks for your comments ! > > JP. > > etc. > == > > > > > > I think Jean-Louis' email address needs updating > > > == > The document would benefit from a little care in the formatting, > and you > could usefully re-read it for missing words, etc. > == > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 10:38:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusEN-0003hZ-IU; Mon, 26 Jun 2006 10:38:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusEM-0003hP-CR for pce@ietf.org; Mon, 26 Jun 2006 10:38:26 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusEL-0005gM-32 for pce@ietf.org; Mon, 26 Jun 2006 10:38:26 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 16:37:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 16:37:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Thread-Index: AcaZJnLlnVcaLDwuSDWJYjZcwsM9BgAASeTw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "JP Vasseur" X-OriginalArrivalTime: 26 Jun 2006 14:37:54.0091 (UTC) FILETIME=[1BD1AFB0:01C6992E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1de2149c0c23c6675e98c918b359cf3 Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, =20 Please see inline,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : lundi 26 juin 2006 15:43 > =C0 : JP Vasseur > Cc : raymond_zhang@bt.infonet.com; nabil.n.bitar@verizon.com;=20 > pce@ietf.org > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 > hi=20 >=20 > i don't think 1) and 2) have been captured=20 >=20 > on 1) there is a terminology issue - indeed - but there is=20 > also an issue that is the arbitrary selection/pruning of=20 > other potential alternatives - why that sequence ? and not=20 > another - was mentioned as the chicken-egg > (technical) problem; first there may be many available=20 > interdomain paths that are never learned by the LSRs,=20 >more=20 > generically the diversity of the BGP routes available at each=20 > LSR is not sufficient to successfully provide for a=20 > satisfactory sequence; on the other hand, you may have=20 > receive multiple let's take an example to illustrate there=20 > are two AS path between A and D, one A-B-C-D the other=20 > A-E-F-D disjoint (on intermediate ASs) either both sequences=20 > are valid both policing and filtering makes you selecting the=20 > inappropriate sequence for the real TE-LSP consrttaints In the inter-AS case, inter-AS selection is likely to be driven by = business considerations and will be the result of (static or dynamic) = inter-SP service negociation and execution. Note that, as recalled by = Adrian, the objective is NOT to setup TE-LSPs over the Internet... Also in your example, one may simply run two BRPC with the two AS-Path = and select the best result... In the inter-area case, areas selection is straightforward. >=20 > on 2) this is part of the answer - the comment was PCE per=20 > domain supporting that method - and in case of two PCEs or=20 > more per domain i am not sure how one could guarantee that=20 > the proposed (recursive) sequence works (assumption is made=20 > that the PCE as full visibility on the whole domain but what=20 > in case of multiple PCEs per domain) If these PCEs have the same visibility then there is NO issue. If these PCEs don't have the same visibility, then actually you have = multiple sub-domains within the domain (or multiple domains within a = super domain!), the pratical case being inter-AS path computation where = each AS is made of several areas. Is that your concern? In this situation, the inter-AS BRPC procedure triggers a set of = inter-area BRPC procedures in each AS to compute intra-AS (ie = inter-area) path segments in each AS.=20 Regards, JL =20 Regards JL >=20 > i have also asked to have a better description of the working=20 > conditions along this draft - to complete section 5.1 -=20 >=20 > if you consider this as non-technical or technical feedback=20 > that's your own appreciation=20 >=20 > thanks, > - dimitri. >=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 14:54 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi, >=20 > ok so to summarize there was no technical feed-back just a=20 > few editorial comments.=20 >=20 > You'd like to add to the following to the document: > 1) The set of traversed domains has to be known and according=20 > to you this is not a constraint. > I think that the current text is quite clear: > "The BRPC procedure guarantees to compute the optimal path=20 > across a specific set of traversed domains (which constitutes=20 > an additional constraint)." > Now if you want to reword a bit to avoid using the word "constraint"=20 > although this *is* a constraint, this is no big deal. >=20 > Actually, interestingly enough there are quite a few cases=20 > where there's only one single set of traversed domains. >=20 > 2) We need at least one PCE per domain > Sounds quite obvious but I have no problem adding this.=20 > Actually we're planning in the next revision to elaborate a=20 > little bit on the inter-As link flooding (again this is not a=20 > requirement but an optimization) but this will be covered. >=20 > JP. >=20 > On Jun 26, 2006, at 2:51 AM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 02:42 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitri, >=20 > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 01:14 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" ,=20 > nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitiri, >=20 > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > the following comment was also discussed during last meeting >=20 > "=3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to=20 > point out that if the sequence of domains is known a priori=20 > (can you determine it a > priori?) then the path computed might not be 'optimal' in the=20 > usual sense of the word, but that this is OK because the=20 > ordered list of domains constitutes an additional constraint=20 > on the computation so the resultant path *is* optimal within=20 > the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of an optimal constrained inter-domain TE LSP.=20 > The sequence of domains to be traversed can either be=20 > determined a priori or during the path computation procedure.=20 > The BRPC procedure guarantees to compute the optimal path=20 > across a specific set of traversed domains (which constitutes=20 > an additional constraint). In the case of an arbitrary set of=20 > meshed domains, the BRPC procedure can be used to compute the=20 > optimal path across each domain set in order to get to=20 > optimal constrained path between the source and the=20 > destination of the TE LSP." >=20 > =3D> in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure (only inter-domain=20 > link selection would be > required) - >=20 > Not correct; even if you know the sequence you still need the=20 > BRPC procedure to figure out the set of BN (boundary Nodes)=20 > to traverse to get the shortest inter-domain TE LSP: this is=20 > the whole issue with inter-domain, otherwise per-domain path=20 > computation would be sufficient. >=20 > [dp] inter-domain link selection (as i mentioned) implies=20 > what you mean with boundary nodes selection - you could=20 > rephrase by access/exit point selection exact same business >=20 > but again even if you know the sequence you still need BRPC=20 > to determine the set of BN (or exit point - same thing) that=20 > will give you the shortest inter-domain path. Look you wrote=20 > "in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure", which is not=20 > correct. Even if you know the sequence of domains, you still=20 > need the procedure to get the exit/entry point (named BN)=20 > that provide you the shortest inter-domain path. >=20 >=20 > now adrian mentions that pre- determination becomes a new=20 > constraint - well actually this is not a constraint for the=20 > TE LSP itself but a restriction on the domain set known to be=20 > (a-priori) supportive of the method such as to make the=20 > method not returning an error message >=20 >=20 > No, this is a constraint: "Give me the shortest path=20 > (potentially made of loose hops (the BNs)) that provides the=20 > shortest end to end path, considering that the additional=20 > constraint is to traverse the following set of domains . >=20 > [dp] incorrect, this is not a "TE LSP" constraint -=20 >=20 > Who said that this was a TE LSP constraint ? This is *a*=20 > constraint. If you impose the set of domain, this is a constraint. >=20 > Please read the text: "The BRPC procedure guarantees to=20 > compute the optimal path across a specific set of traversed=20 > domains (which constitutes an additional constraint)." >=20 > [dp] i read this, mind you, my point is that this is not a=20 > "constraint"=20 > of > the same nature as the one you're making use such as minimize=20 > delays or whatsover - this constraint is introduced from the=20 > computation technique and mechanism of this proposed method=20 >=20 > Note that at this point, I still do not see the point that=20 > you're trying to make here ? >=20 > since so far when > a set of domains do not support/or support a given=20 > computation has not yet become a constraint >=20 > hence sentence "The BRPC procedure guarantees to compute the=20 > optimal path across a specific set of traversed domains=20 > (which constitutes an additional constraint). In the case of=20 > an arbitrary set of meshed domains, the BRPC procedure can be=20 > used to compute the optimal path across each domain set in=20 > order to get to optimal constrained path between the source=20 > and the destination of the TE LSP." >=20 > should as far as i understand the method fulfill the following >=20 > a) this method provides a result iff all domains traversed by=20 > the request support the proposed method >=20 > BRPC is a multi-PCE based approach where you need at least=20 > one PCE per-domain. >=20 > [dp] indeed, but one PCE supporting that method and having=20 > FULL visibility of the domain >=20 > So what is your point here ? >=20 > [dp] that the set of conditions to have this method workable=20 > is larger than the one listed in this doc. >=20 > b) this method provides an "optimal" result iff >=20 > b1) all possible sequences of domains have been traversed=20 > (starting from the root) and are supportive of that method -=20 > as there might be an optimal path through a domain not=20 > supporting this method - >=20 >=20 > heu ... yes indeed. If a domain does not support the method,=20 > the method cannot be used to compute the path. >=20 > b2) there is no discontinuity in the availability of the=20 > inter-AS link information on each PCE performing a given=20 > selection - indeed a domain might be supportive of the method=20 > without supporting inter-AS link flooding >=20 > No this is not a requirement, just an optimization. The only=20 > requirement is for the PCE to get the TE-related data about=20 > the Inter- AS links. I'll detail a bit more in the next revision. >=20 > [dp] then you can never achieve - >=20 > You can never achieve what ? >=20 > Sorry Dimitri, I'd love to accommodate your comment but I do=20 > not see your point ... hopefully we'll have a bit of time in=20 > Montreal to discuss if that does not work by email. >=20 > [dp] my point is that without this additional information you=20 > can not achieve the expected result - i pointed to your own=20 > text to indicate that this information is a must have in=20 > order to achieve this objective=20 >=20 > using your own words to make it more > straighforward -=20 >=20 > "you still need the BRPC procedure to figure out the set of=20 > BN (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP:=20 > this is the whole issue with inter-domain, otherwise=20 > per-domain path computation would=20 >=20 > be sufficient." >=20 > b3) at each step there is no PCE that has partial visibility=20 > of a given domain >=20 >=20 > This is not specific to BRPC. Even with intra-domain if you want to=20 > compute the path for a TE LSP, you cannot always use the PCE if it=20 > has a partial visibility. Note that this also applies to the case of=20 > co-located PCE (when the path is computed by the head-end). >=20 > [dp] hence, to BRPC as well >=20 > b4) during the selection process no network conditions changes=20 > (that would > make the returned result void) >=20 >=20 > Again, this applies to other cases as well. >=20 > [dp] ditto >=20 >=20 > Ah so we agree here :-) >=20 > What was your comment then ? >=20 > [dp] that you need to include these set of working conditions in the=20 > document itself, the document looks like quite simple in terms of=20 > conditions for having the proposed method working as expected=20 > while when=20 > you take a closer look at it this is not the case >=20 > Thanks. >=20 > JP. >=20 >=20 >=20 > thanks. >=20 > JP. >=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > 23/06/2006 16:11 >=20 > To: "Adrian Farrel" > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt >=20 >=20 > Many Thanks Adrian for the comments. >=20 > We incorporated the vast majority of them in the new revision (just > posted). >=20 > See below for the comments requesting some clarification. >=20 > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >=20 > Hi, >=20 > Thanks for keeping these ideas alive. >=20 > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. >=20 > Thanks, > Adrian >=20 > =3D=3D > Is this I-D likely to be Informational or Standards Track? From=20 > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > =3D=3D >=20 > Status has been updated (Informational) but let's discuss this=20 > later on. > FYI, it does not appear on the front page when using the xml2rfc=20 > editor > (which by the way is excellent), thus the appendix addition. >=20 > It would be nice if the Abstract contained a pithy summary of brpc=20 > and/or > gave the motivation for the draft. For example, what is the method=20 > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? >=20 > Agree. Here is the new Abstract: > "The ability to compute constrained shortest Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)=20 > and > Generalized MPLS (GMPLS) networks across multiple domains (where a=20 > domain > is referred to as a collection of network elements within a common=20 > sphere > of address management or path computational responsibility such as IGP > areas and Autonomous Systems) has been identified as a key=20 > requirement . > This document specifies a procedure relying on the use of multiple=20 > Path > Computation Elements (PCEs) in order to compute such inter-domain=20 > shortest > constraint paths, using a backward recursive path computation=20 > technique > while fully preserving confidentiality requirements across domains. " >=20 >=20 > =3D=3D > I'm assuming that section 1 is for short term information only and=20 > will be > deleted (in the next revision?) > =3D=3D >=20 > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. >=20 > =3D=3D > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would=20 > argue that > reachability information (i.e. external routes) constitutes=20 > topology and > resource information. >=20 >=20 > OK fine >=20 > =3D=3D > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed=20 > that, at > the domain boundary LSRs, there will exist some sort of local=20 > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? >=20 >=20 > It should actually read "pre-determined". Actually the best thing=20 > to do > here is to remove "off-line" >=20 > =3D=3D > Section 5 > No assumption is made on the actual path computation algorithm in=20 > use > by the PCE (it can be any variant of CSPF, algorithm based on=20 > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! >=20 > Well I'd suggest to keep it as is since the point is to=20 > differentiate the > path computation procedure from the algorithm to compute each intra-=20 > domain > path segment. Furthermore, we'd like to highlight the fact that the=20 > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. >=20 > =3D=3D > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous >=20 > It is actually a double tautology ;-) (fixed). >=20 > =3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point=20 > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual=20 > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the=20 > resultant > path *is* optimal within the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains=20 > to be > traversed can either be determined a priori or during the path=20 > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path=20 > across > each domain set in order to get to optimal constrained path between=20 > the > source and the destination of the TE LSP." >=20 > =3D=3D > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to=20 > parse > and > to my mind the definition is arse about tit. I think you could=20 > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en=20 > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! >=20 > This is an abstract form of representation but see below, >=20 > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP=20 > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. >=20 >=20 > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P=20 > tree). >=20 > =3D=3D > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where,=20 > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. >=20 > This only works for unidirectional LSPs: indeed, the exit boundary=20 > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP=20 > running on > the link but how would a node in domain (i) get the TE-related data=20 > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? >=20 > =3D=3D > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..."=20 > is a > nascent Applicability Statement. I suggest moving this to another=20 > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than=20 > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms >=20 > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. >=20 > =3D=3D > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1)=20 > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is=20 > supposed > to > respond to the path computation request saying that it does not=20 > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. >=20 > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. >=20 > =3D=3D > Section 8 > Metric normalisation is a great potential solution, but how does it=20 > fit > with > AS topology confidentiality? What is the solution to providing=20 > discretion > about what TE connectivity is available within an AS, and operating=20 > brpc? >=20 > Metric normalization is handled locally by the PCE and does not=20 > impact the > BRPC procedure per-say. As far as confidentiality is concerned,=20 > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost =3D F (link_bandwidth) with F (OC192)=3D1 > SP 2 Links Cost =3D F (link_bandwidth) with F (OC192)=3D10 >=20 > A simple metric normalization can then be performed on the PCE=20 > thanks to > simple cost mapping tables. >=20 > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you=20 > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would=20 > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of=20 > course) is > not > the case - per-domain optimisation will always improve or leave the=20 > same > end-to-end optimality (in the case where new resources are made=20 > available > this is obvious; in the case of a network failure, *any* path is=20 > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next=20 > section, > not > in this section. >=20 >=20 > Yes I wanted to leave that text to keep track of who would read the=20 > ID, > expecting reaction ;-)) Per-domain reoptimization would always=20 > improve the > current path *but* in case of stitched LSPs, TE LSP segments are=20 > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP,=20 > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a=20 > stitched LSP > and rely on BRPC when first signaled in an attempt to get an=20 > optimal path, > you need to consider the interaction between the local reopt mode=20 > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. >=20 > =3D=3D > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use=20 > this > technique in conjunction with path cookies, which is fine. But, are=20 > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. >=20 > Indeed. >=20 > Maybe the PCE(n+1) should carefully monitor and limit=20 > (statistically and > by > policy) brpc requests so that excessive information is not divulged? >=20 > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. >=20 > =3D=3D > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in=20 > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? >=20 > Absolutely ! I put a placeholder for a further revision. >=20 > Fully supportive of adding such section. >=20 > Many Thanks for your comments ! >=20 > JP. >=20 > etc. > =3D=3D >=20 >=20 >=20 >=20 >=20 > I think Jean-Louis' email address needs updating >=20 >=20 > =3D=3D > The document would benefit from a little care in the formatting,=20 > and you > could usefully re-read it for missing words, etc. > =3D=3D > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 11:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fusaf-0003CB-4r; Mon, 26 Jun 2006 11:01:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fusae-0003C6-3a for pce@ietf.org; Mon, 26 Jun 2006 11:01:28 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusaY-0000Dy-UO for pce@ietf.org; Mon, 26 Jun 2006 11:01:28 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fusam-0006fG-00 for pce@ietf.org; Mon, 26 Jun 2006 16:01:36 +0100 Received: from your029b8cecfe ([194.94.109.154] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 16:01:21 +0100 Message-ID: <03fd01c69931$60e97e40$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: References: Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Mon, 26 Jun 2006 16:01:03 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 26 Jun 2006 15:01:21.0355 (UTC) FILETIME=[629D21B0:01C69931] X-Spam-Score: 0.1 (/) X-Scan-Signature: 966811b049c4d80323826ee01e1b1ce9 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Thanks Dimitri, This is converging nicely. > ok (nice summary) - i think the whole debate is on point 2) since last > meeting discussions - if one agrees that we don't solve this issue - then > being aware upfront/descriptive of limitations, conditions and workability > is really appropriated - let's assume this is (hopefully) the case Then that is an action for the authors to make points 1 and 2 *very* clear in the I-D (at the top!) > the more important implication is point 3) - if this inter-domain link is > not provided - de facto - as part of the method what does this method > really provides ? i mean section 7. reads as if you can not flood just > makes PCE aware of that TE data; however, point on whether this info is > flooded or passed to the PCE or not the main issue is how this information > is locally obtained ? what does happen if this information is only > partially or not known, changing conditions, a unidirectional LSP reserves > bandwidth downstream how accounting occurs (edges need to be aware of > forward and reverse bandwidth), etc. I suspect you do not mean section 7? So, if I may rephrase.... You are concerned about how the brpc process would operate if there is an inter-domain link (e.g. inter-AS) and the TE information for this link is not fully known. Let's quickly look at who needs to know. The downstream PCE provides paths from entry points to its domain (BR-en(i)) to the destination. So the downstream PCE is not interested in the TE links entering the domain. The upstream PCE provides paths from the entry points to its domain (BR-en(i-1)) to the destination. It computes these by computing 'optimal' paths from each BR-en(i-1) to the destination [says the I-D in step 2]. But this is highly unclear! Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to each BR-ex(i-1), but in order to build the tree we need the paths to be computed from each BR-en(i-1) to each BR-en(i). These paths include the inter-domain TE links (where they exist). So.... Either there is an assumption that this TE link information is available, or there is a step missing in the process. Perhaps the authors could clarify here and in the I-D. Thanks, Adrian > "Adrian Farrel" > 26/06/2006 15:14 > Please respond to "Adrian Farrel" > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: > Subject: Re: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt > > > Hi, > > I'm trying to parse something out of this thread. > > 1. It is clear that brpc *demands* that the sequence of domains > is already known before brpc is executed. > In my opinion, this is clear in the I-D, but it would not hurt to > make it clearer. > A statement in the Abstract and Introduction would achieve > this. > > 2. The mechanism by which the sequence of domains is known > is out of scope for the procedure. > It is not clear whether this is a limitation of the process, or > not. But in my opinion this is consistent with the guidance > that the WG received from the IAB when we were chartered. > We are not trying to 'solve the Internet', so selection of > domains is out of scope. > > 3. brpc *does* include mechanisms for the selection of interdomain > links and/or nodes. This is more complex than the simple selection > of these points of attachment because the connection to use may > depend on the TE paths within the domains. > IMO, brpc is constructed specifically for this purpose. If we did > not need this function, we could use pd-path computation with > visibility of the inter-domain TE links. > > 4. The discussion is not helped by debate about the precise wording > around 'constraint'. > Let us say that "the sequence of domains to be traversed is > provided by an external source as a limiting factor to the computation > or choice of paths." > > Do we all agree with these statements? > > Cheers, > Adrian > > ----- Original Message ----- > From: > To: "JP Vasseur" > Cc: ; ; > > Sent: Monday, June 26, 2006 7:51 AM > Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt > > >> hi j-p - see in-line >> >> >> >> >> JP Vasseur >> 26/06/2006 02:42 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: nabil.n.bitar@verizon.com, pce@ietf.org, >> raymond_zhang@bt.infonet.com >> Subject: Re: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> hi dimitri, >> >> On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >> >> hi j-p - see in-line >> >> >> >> >> JP Vasseur >> 26/06/2006 01:14 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: "Adrian Farrel" , >> nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com >> Subject: Re: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> hi dimitiri, >> >> On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >> >> the following comment was also discussed during last meeting >> >> "== >> Section 5.1 >> I like the simplicity of section 5.1, but I think you need to point >> out >> that >> if the sequence of domains is known a priori (can you determine it a >> priori?) then the path computed might not be 'optimal' in the usual >> sense >> of >> the word, but that this is OK because the ordered list of domains >> constitutes an additional constraint on the computation so the >> resultant >> path *is* optimal within the constraints applied. >> >> Can't agree more. Good suggestion, thanks. >> >> Updated text: "The PCE-based BRPC procedure applies to the >> computation of >> an optimal constrained inter-domain TE LSP. The sequence of domains >> to be >> traversed can either be determined a priori or during the path >> computation >> procedure. The BRPC procedure guarantees to compute the optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> => in brief, how to determine the sequence through which path >> computation >> has to be performed because if this sequence was known there is no >> need >> for such procedure (only inter-domain link selection would be >> required) - >> >> Not correct; even if you know the sequence you still need the BRPC >> procedure to figure out the set of BN (boundary Nodes) to traverse to >> get the shortest inter-domain TE LSP: this is the whole issue with >> inter-domain, otherwise per-domain path computation would be sufficient. >> >> [dp] inter-domain link selection (as i mentioned) implies what you mean >> with boundary nodes selection - you could rephrase by access/exit point >> selection exact same business >> >> but again even if you know the sequence you still need BRPC to determine >> the set of BN (or exit point - same thing) that will give you the > shortest >> inter-domain path. Look you wrote "in brief, how to determine the > sequence >> through which path computation has to be performed because if this >> sequence was known there is no need for such procedure", which is not >> correct. Even if you know the sequence of domains, you still need the >> procedure to get the exit/entry point (named BN) that provide you the >> shortest inter-domain path. >> >> >> now adrian mentions that pre- determination becomes a new constraint - >> well actually this is not a constraint for the TE LSP itself but a >> restriction on the domain set known to be (a-priori) supportive of the >> method such as to make the method not returning an error message >> >> >> No, this is a constraint: "Give me the shortest path (potentially >> made of loose hops (the BNs)) that provides the shortest end to end >> path, considering that the additional constraint is to traverse the >> following set of domains . >> >> [dp] incorrect, this is not a "TE LSP" constraint - >> >> Who said that this was a TE LSP constraint ? This is *a* constraint. If >> you impose the set of domain, this is a constraint. >> >> Please read the text: "The BRPC procedure guarantees to compute the >> optimal path across a specific set of traversed domains (which > constitutes >> an additional constraint)." >> >> [dp] i read this, mind you, my point is that this is not a "constraint" > of >> the same nature as the one you're making use such as minimize delays or >> whatsover - this constraint is introduced from the computation technique >> and mechanism of this proposed method >> >> Note that at this point, I still do not see the point that you're trying >> to make here ? >> >> since so far when >> a set of domains do not support/or support a given computation has not >> yet become a constraint >> >> hence sentence "The BRPC procedure guarantees to compute the >> optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> should as far as i understand the method fulfill the following >> >> a) this method provides a result iff all domains traversed by the >> request >> support the proposed method >> >> BRPC is a multi-PCE based approach where you need at least one PCE >> per-domain. >> >> [dp] indeed, but one PCE supporting that method and having FULL >> visibility of the domain >> >> So what is your point here ? >> >> [dp] that the set of conditions to have this method workable is larger >> than the one listed in this doc. >> >> b) this method provides an "optimal" result iff >> >> b1) all possible sequences of domains have been traversed (starting >> from >> the root) and are supportive of that method - as there might be an >> optimal >> path through a domain not supporting this method - >> >> >> heu ... yes indeed. If a domain does not support the method, the >> method cannot be used to compute the path. >> >> b2) there is no discontinuity in the availability of the inter-AS link >> information on each PCE performing a given selection - indeed a domain >> might be supportive of the method without supporting inter-AS link >> flooding >> >> No this is not a requirement, just an optimization. The only >> requirement is for the PCE to get the TE-related data about the Inter- >> AS links. I'll detail a bit more in the next revision. >> >> [dp] then you can never achieve - >> >> You can never achieve what ? >> >> Sorry Dimitri, I'd love to accommodate your comment but I do not see > your >> point ... hopefully we'll have a bit of time in Montreal to discuss if >> that does not work by email. >> >> [dp] my point is that without this additional information you can not >> achieve the expected result - i pointed to your own text to indicate > that >> this information is a must have in order to achieve this objective >> >> using your own words to make it more >> straighforward - >> >> "you still need the BRPC procedure to figure out the set of BN (boundary >> Nodes) to traverse to get the shortest inter-domain TE LSP: this is the >> whole issue with inter-domain, otherwise per-domain path computation >> would >> >> be sufficient." >> >> b3) at each step there is no PCE that has partial visibility of a >> given >> domain >> >> >> This is not specific to BRPC. Even with intra-domain if you want to >> compute the path for a TE LSP, you cannot always use the PCE if it >> has a partial visibility. Note that this also applies to the case of >> co-located PCE (when the path is computed by the head-end). >> >> [dp] hence, to BRPC as well >> >> b4) during the selection process no network conditions changes >> (that would >> make the returned result void) >> >> >> Again, this applies to other cases as well. >> >> [dp] ditto >> >> >> Ah so we agree here :-) >> >> What was your comment then ? >> >> [dp] that you need to include these set of working conditions in the >> document itself, the document looks like quite simple in terms of >> conditions for having the proposed method working as expected while when >> you take a closer look at it this is not the case >> >> Thanks. >> >> JP. >> >> >> >> thanks. >> >> JP. >> >> >> >> >> >> >> JP Vasseur >> 23/06/2006 16:11 >> >> To: "Adrian Farrel" >> cc: raymond_zhang@bt.infonet.com, pce@ietf.org, >> nabil.n.bitar@verizon.com >> Subject: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> Many Thanks Adrian for the comments. >> >> We incorporated the vast majority of them in the new revision (just >> posted). >> >> See below for the comments requesting some clarification. >> >> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >> >> Hi, >> >> Thanks for keeping these ideas alive. >> >> Here are some picky thoughts that you may want to include in the next >> revision to make it more robust as a document. I don't have any issues >> with >> the basic process. >> >> Thanks, >> Adrian >> >> == >> Is this I-D likely to be Informational or Standards Track? From >> Appendix >> A, >> this looks like Standards Track. Can you remove Appendix A and put the >> status in the usual place in the header? >> == >> >> Status has been updated (Informational) but let's discuss this >> later on. >> FYI, it does not appear on the front page when using the xml2rfc >> editor >> (which by the way is excellent), thus the appendix addition. >> >> It would be nice if the Abstract contained a pithy summary of brpc >> and/or >> gave the motivation for the draft. For example, what is the method >> trying >> to >> achieve that isn't achievable by other methods? Or, what is the >> fundamental >> element of brpc that is not in other methods? >> >> Agree. Here is the new Abstract: >> "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 (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) has been identified as a key >> requirement . >> This document specifies a procedure relying on the use of multiple >> Path >> Computation Elements (PCEs) in order to compute such inter-domain >> shortest >> constraint paths, using a backward recursive path computation >> technique >> while fully preserving confidentiality requirements across domains. " >> >> >> == >> I'm assuming that section 1 is for short term information only and >> will be >> deleted (in the next revision?) >> == >> >> Indeed, just to provide a bit of history for the ones who have been >> following inter-domain path computation for a while. >> >> == >> Section 4 >> - No topology or resource information is distributed between domains >> (as mandated per [RFC4105] and [RFC4216]), which is critical to >> preserve IGP/BGP scalability and confidentiality in the case of TE >> LSPs spanning multiple domains. >> You should clarify what you are saying here, because many would >> argue that >> reachability information (i.e. external routes) constitutes >> topology and >> resource information. >> >> >> OK fine >> >> == >> Section 4 >> - While certain constraints like bandwidth can be used across >> different domains, certain other TE constraints like resource >> affinity, color, metric, etc. as listed in [RFC2702] could be >> translated at domain boundaries. If required, it is assumed >> that, at >> the domain boundary LSRs, there will exist some sort of local >> mapping >> based on offline policy agreement, in order to translate such >> constraints across domain boundaries during the inter-PCE >> communication process. >> Why does the policy agreement need to be offline? >> >> >> It should actually read "pre-determined". Actually the best thing >> to do >> here is to remove "off-line" >> >> == >> Section 5 >> No assumption is made on the actual path computation algorithm in >> use >> by the PCE (it can be any variant of CSPF, algorithm based on >> linear- >> programming to solve multi-constraints optimization problems and so >> on). >> Suggest that you delete the text in parenthesis because it is making >> suggestions that border on assumptions! >> >> Well I'd suggest to keep it as is since the point is to >> differentiate the >> path computation procedure from the algorithm to compute each intra- >> domain >> path segment. Furthermore, we'd like to highlight the fact that the >> BRPC >> procedure does not mandate for each PCE to use CSPF, could be other >> algorithm. >> >> == >> Section 5.1 and throughout >> "BRPC path computation" seems to be tautologous >> >> It is actually a double tautology ;-) (fixed). >> >> == >> Section 5.1 >> I like the simplicity of section 5.1, but I think you need to point >> out >> that >> if the sequence of domains is known a priori (can you determine it a >> priori?) then the path computed might not be 'optimal' in the usual >> sense >> of >> the word, but that this is OK because the ordered list of domains >> constitutes an additional constraint on the computation so the >> resultant >> path *is* optimal within the constraints applied. >> >> Can't agree more. Good suggestion, thanks. >> >> Updated text: "The PCE-based BRPC procedure applies to the >> computation of >> an optimal constrained inter-domain TE LSP. The sequence of domains >> to be >> traversed can either be determined a priori or during the path >> computation >> procedure. The BRPC procedure guarantees to compute the optimal path >> across a specific set of traversed domains (which constitutes >> an additional constraint). In the case of an arbitrary set of meshed >> domains, the BRPC procedure can be used to compute the optimal path >> across >> each domain set in order to get to optimal constrained path between >> the >> source and the destination of the TE LSP." >> >> == >> Section 5.2 >> The introduction of the term Virtual Shortest Path Tree is hard to >> parse >> and >> to my mind the definition is arse about tit. I think you could >> usefully >> add >> some textual definition of what the VSPT is trying to achieve, before >> presenting it in pictorial or abstract form. >> Even more important (I think) is the fact that the tree as presented >> "represents the shortest path between the destination and BR-en >> (j,i)..." >> Frankly, we are building directional paths in exactly the oposite >> direction! >> >> This is an abstract form of representation but see below, >> >> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP >> tree as >> described. >> I suspect that this is just a textual descriptive issue rather than >> anything >> broken in the process. >> >> >> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P >> tree). >> >> == >> Section 5.2 >> I suggest that you pull the note (Note: in term of computation...) out >> into >> a separate section. It doesn't belong in the middle of section 5.2. >> You will probably want to re-write the text as well since the >> unidirectional >> limit is not necessary. Also to explain 'flood' - flood to where, >> and how, >> and by whom? And you will want to add to pieces of information: >> - the link to the I-D that defines how to do this >> - a description of what happens if this process is not used. >> >> This only works for unidirectional LSPs: indeed, the exit boundary >> node >> can flood TE-related data in its LSA/LSP for the link >> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP >> running on >> the link but how would a node in domain (i) get the TE-related data >> for >> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on >> unidirectional link. Are we in sync ? >> >> == >> Section 5.2 >> The paragraph that begins "BRPC guarantees to find the optimal..." >> is a >> nascent Applicability Statement. I suggest moving this to another >> Section >> and significantly beefing it up. You need to describe more fully: >> - how ECMP works (the PCC has to request the return of more than >> one path) >> - how diversity works (i.e. section 9 fits in here) >> - how some freedom of selection of domains can be offered >> - how to mix the method with other mechanisms >> >> This was (and is) planned for future revision. Note that ECMP and >> diversity are discussed already but we're planning the flesh out these >> sections in further revision. >> >> == >> Section 7 >> If the BRPC procedure cannot be completed because a PCE along the >> domain path does not support the procedure, a PCErr message is >> returned by the upstream PCE with a Error-Type "BRPC procedure >> completion failure". The PCErr message MUST be relayed to the >> requesting PCC. >> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >>does not >> support brpc, presumably through capabilities >> configuration/advertisement/negotiation, or whether PCE(n+1) is >> supposed >> to >> respond to the path computation request saying that it does not >> support >> bit-V of the RP object. If the latter, presumably the PCErr comes from >> PCE(n+1) and not from PCE(n) as documented. >> >> Good catch, typo: it should read "a PCErr message is returned to the >> upstream". >> The plan is to define a capability bit (IGP) in a further revision. >> >> == >> Section 8 >> Metric normalisation is a great potential solution, but how does it >> fit >> with >> AS topology confidentiality? What is the solution to providing >> discretion >> about what TE connectivity is available within an AS, and operating >> brpc? >> >> Metric normalization is handled locally by the PCE and does not >> impact the >> BRPC procedure per-say. As far as confidentiality is concerned, >> this only >> requires for the SPs to exchange metric mapping information (nothing >> related to the network topology or resources); for example >> SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 >> SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 >> >> A simple metric normalization can then be performed on the PCE >> thanks to >> simple cost mapping tables. >> >> Section 10 >> Some of this text has been seen before in this I-D >> Why do you single out LSP stitching as possibly breaking end-to-end >> optimality. There is functionally no difference between stitching and >> nesting in this respect. >> But further, your statement about stitching is pejorative! If you >> say that >> "In the case where a domain has more than one BR-en or more than one >> BR-ex, >> optimality after some network change within the domain can only be >> guaranteed by re-executing the full brpc computation" then I would >> agree >> with you. But as phrased, it implies that making a per-domain >> re-optimisation could make the path *less* optimal. This (of >> course) is >> not >> the case - per-domain optimisation will always improve or leave the >> same >> end-to-end optimality (in the case where new resources are made >> available >> this is obvious; in the case of a network failure, *any* path is >> better >> than >> no path!) >> And, lastly, the text about re-optimisation belongs in the next >> section, >> not >> in this section. >> >> >> Yes I wanted to leave that text to keep track of who would read the >> ID, >> expecting reaction ;-)) Per-domain reoptimization would always >> improve the >> current path *but* in case of stitched LSPs, TE LSP segments are >> computed >> by the stitching point; thus in case of failure, they could end up >> following a non optimal path whereas in the case of contiguous LSP, >> the >> BRPC procedure would be called again thus leading to the optimal path >> again. The point that I was trying to make is "if you have a >> stitched LSP >> and rely on BRPC when first signaled in an attempt to get an >> optimal path, >> you need to consider the interaction between the local reopt mode >> and BRPC >> if the goal is to preserve an optimal path at any given time". Anyway, >> we're on the same page and I agree and the text should be reworded >> according to your proposal to avoid any misunderstanding. >> >> == >> Section 13 >> I would like you to discuss the issues of confidentiality of topology >> information at greater length. It seems that you would possibly use >> this >> technique in conjunction with path cookies, which is fine. But, are >> there >> two things you cannot escape from? >> - indicating which BR-en provides best connectivity >> - indicating the metric for multiple BR-ens >> Maybe there are some things that can be done here based on policy, >> including >> not reporting all of the BR-ens, ranking rather than giving absolute >> metrics, etc. But these would compromise optimality. >> >> Indeed. >> >> Maybe the PCE(n+1) should carefully monitor and limit >> (statistically and >> by >> policy) brpc requests so that excessive information is not divulged? >> >> Since one of objectives for using the BRPC procedure is to compute an >> optimal path, we need to know at least the BN (Boundary Nodes) and the >> cost. >> >> == >> I wouldn't mind seeing a Management Considerations section. >> Do we need to be able to examine the pruned pieces of VSPT at transit >> PCEs? >> What are the implications of reporting multiple VSPT branches in >> PCEP to >> the >> MIB modules? >> Is brpc support something that needs to be configured: per PCE?; per >> PCE-neighbor? >> What are the implications on existing protocols (IGPs? PCEP?) of using >> brpc? >> >> Absolutely ! I put a placeholder for a further revision. >> >> Fully supportive of adding such section. >> >> Many Thanks for your comments ! >> >> JP. >> >> etc. >> == >> >> >> >> >> >> I think Jean-Louis' email address needs updating >> >> >> == >> The document would benefit from a little care in the formatting, >> and you >> could usefully re-read it for missing words, etc. >> == >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce >> >> >> > > > > > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 11:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fusid-0004vz-RM; Mon, 26 Jun 2006 11:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fusid-0004vu-2c for pce@ietf.org; Mon, 26 Jun 2006 11:09:43 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fusib-0000rQ-NL for pce@ietf.org; Mon, 26 Jun 2006 11:09:43 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5QF9Ul9023261; Mon, 26 Jun 2006 17:09:30 +0200 In-Reply-To: To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Mon, 26 Jun 2006 17:09:27 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/26/2006 17:09:29, Serialize complete at 06/26/2006 17:09:29 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: 5a1acaa54b4cde5ab4439a319e9b7f91 Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-l - thanks for these clarifications - see in-line for a couple of=20 remarks "LE ROUX Jean-Louis RD-CORE-LAN" 26/06/2006 16:37 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur"=20 cc: ,=20 , Subject: RE: [Pce] Re: Comments on=20 draft-vasseur-pce-brpc-00.txt Hi Dimitri, =20 Please see inline,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : lundi 26 juin 2006 15:43 > =C0 : JP Vasseur > Cc : raymond=5Fzhang@bt.infonet.com; nabil.n.bitar@verizon.com;=20 > pce@ietf.org > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 > hi=20 >=20 > i don't think 1) and 2) have been captured=20 >=20 > on 1) there is a terminology issue - indeed - but there is=20 > also an issue that is the arbitrary selection/pruning of=20 > other potential alternatives - why that sequence ? and not=20 > another - was mentioned as the chicken-egg > (technical) problem; first there may be many available=20 > interdomain paths that are never learned by the LSRs,=20 >more=20 > generically the diversity of the BGP routes available at each=20 > LSR is not sufficient to successfully provide for a=20 > satisfactory sequence; on the other hand, you may have=20 > receive multiple let's take an example to illustrate there=20 > are two AS path between A and D, one A-B-C-D the other=20 > A-E-F-D disjoint (on intermediate ASs) either both sequences=20 > are valid both policing and filtering makes you selecting the=20 > inappropriate sequence for the real TE-LSP consrttaints In the inter-AS case, inter-AS selection is likely to be driven by=20 business considerations and will be the result of (static or dynamic)=20 inter-SP service negociation and execution. Note that, as recalled by=20 Adrian, the objective is NOT to setup TE-LSPs over the Internet... Also in your example, one may simply run two BRPC with the two AS-Path and = select the best result... [dp] in the inter AS case, which is the most challenging, are you telling=20 me that the whole policing and filtering is done but based on information=20 elements that require further negotiation phases - such that your=20 selection is not susceptible to lead you to a case where the AS=5Fpath=20 doesn't provide you any further information but your initial negotiation=20 makes it such that the probability of making the wrong selection is=20 minimized - taking the example i gave here above: two AS path between A=20 and D, one A-B-C-D the other=20 A-E-F-D disjoint (on intermediate ASs) and both sequences are valid - but=20 now policing and filtering makes you selecting the appropriate sequence=20 for the real TE-LSP consrttaints ? if this is the case some further=20 inlightment may be really helpful - In the inter-area case, areas selection is straightforward. > on 2) this is part of the answer - the comment was PCE per=20 > domain supporting that method - and in case of two PCEs or=20 > more per domain i am not sure how one could guarantee that=20 > the proposed (recursive) sequence works (assumption is made=20 > that the PCE as full visibility on the whole domain but what=20 > in case of multiple PCEs per domain) If these PCEs have the same visibility then there is NO issue. If these PCEs don't have the same visibility, then actually you have=20 multiple sub-domains within the domain (or multiple domains within a super = domain!), the pratical case being inter-AS path computation where each AS=20 is made of several areas. Is that your concern? [dp] my concern is that segmentation of PCE roles is not necessarily=20 mapping domain boundaries (intra-AS) and the other case is when for=20 instance could have as example that for a given "AS" a PCE taking care of=20 TDM links and another ETH links hence you would have a bifurcation - i=20 mean you get a sequence of AS from routing but for each AS there may be a=20 set of PCE which not structured such as to map the routing topology - i=20 can rephrase as for a sequence of AS there can be multiple sequences of=20 PCEs if these have not complete view you need to deal with intermediate=20 recombination of information on the return path or make a selection of=20 PCEs on the forward path - the doc. currently says "If multiple PCEs are=20 discovered, the PCE may select a subset of these PCEs based on some local=20 policies/heuristics." what in case it doesn't ? In this situation, the inter-AS BRPC procedure triggers a set of=20 inter-area BRPC procedures in each AS to compute intra-AS (ie inter-area)=20 path segments in each AS.=20 Regards, JL =20 Regards JL >=20 > i have also asked to have a better description of the working=20 > conditions along this draft - to complete section 5.1 -=20 >=20 > if you consider this as non-technical or technical feedback=20 > that's your own appreciation=20 >=20 > thanks, > - dimitri. >=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 14:54 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond=5Fzhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi, >=20 > ok so to summarize there was no technical feed-back just a=20 > few editorial comments.=20 >=20 > You'd like to add to the following to the document: > 1) The set of traversed domains has to be known and according=20 > to you this is not a constraint. > I think that the current text is quite clear: > "The BRPC procedure guarantees to compute the optimal path=20 > across a specific set of traversed domains (which constitutes=20 > an additional constraint)." > Now if you want to reword a bit to avoid using the word "constraint"=20 > although this *is* a constraint, this is no big deal. >=20 > Actually, interestingly enough there are quite a few cases=20 > where there's only one single set of traversed domains. >=20 > 2) We need at least one PCE per domain > Sounds quite obvious but I have no problem adding this.=20 > Actually we're planning in the next revision to elaborate a=20 > little bit on the inter-As link flooding (again this is not a=20 > requirement but an optimization) but this will be covered. >=20 > JP. >=20 > On Jun 26, 2006, at 2:51 AM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 02:42 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond=5Fzhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitri, >=20 > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > hi j-p - see in-line >=20 >=20 >=20 >=20 > JP Vasseur > 26/06/2006 01:14 >=20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > cc: "Adrian Farrel" ,=20 > nabil.n.bitar@verizon.com, pce@ietf.org, raymond=5Fzhang@bt.infonet.com > Subject: Re: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > hi dimitiri, >=20 > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >=20 > the following comment was also discussed during last meeting >=20 > "=3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to=20 > point out that if the sequence of domains is known a priori=20 > (can you determine it a > priori?) then the path computed might not be 'optimal' in the=20 > usual sense of the word, but that this is OK because the=20 > ordered list of domains constitutes an additional constraint=20 > on the computation so the resultant path *is* optimal within=20 > the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of an optimal constrained inter-domain TE LSP.=20 > The sequence of domains to be traversed can either be=20 > determined a priori or during the path computation procedure.=20 > The BRPC procedure guarantees to compute the optimal path=20 > across a specific set of traversed domains (which constitutes=20 > an additional constraint). In the case of an arbitrary set of=20 > meshed domains, the BRPC procedure can be used to compute the=20 > optimal path across each domain set in order to get to=20 > optimal constrained path between the source and the=20 > destination of the TE LSP." >=20 > =3D> in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure (only inter-domain=20 > link selection would be > required) - >=20 > Not correct; even if you know the sequence you still need the=20 > BRPC procedure to figure out the set of BN (boundary Nodes)=20 > to traverse to get the shortest inter-domain TE LSP: this is=20 > the whole issue with inter-domain, otherwise per-domain path=20 > computation would be sufficient. >=20 > [dp] inter-domain link selection (as i mentioned) implies=20 > what you mean with boundary nodes selection - you could=20 > rephrase by access/exit point selection exact same business >=20 > but again even if you know the sequence you still need BRPC=20 > to determine the set of BN (or exit point - same thing) that=20 > will give you the shortest inter-domain path. Look you wrote=20 > "in brief, how to determine the sequence through which path=20 > computation has to be performed because if this sequence was=20 > known there is no need for such procedure", which is not=20 > correct. Even if you know the sequence of domains, you still=20 > need the procedure to get the exit/entry point (named BN)=20 > that provide you the shortest inter-domain path. >=20 >=20 > now adrian mentions that pre- determination becomes a new=20 > constraint - well actually this is not a constraint for the=20 > TE LSP itself but a restriction on the domain set known to be=20 > (a-priori) supportive of the method such as to make the=20 > method not returning an error message >=20 >=20 > No, this is a constraint: "Give me the shortest path=20 > (potentially made of loose hops (the BNs)) that provides the=20 > shortest end to end path, considering that the additional=20 > constraint is to traverse the following set of domains . >=20 > [dp] incorrect, this is not a "TE LSP" constraint -=20 >=20 > Who said that this was a TE LSP constraint ? This is *a*=20 > constraint. If you impose the set of domain, this is a constraint. >=20 > Please read the text: "The BRPC procedure guarantees to=20 > compute the optimal path across a specific set of traversed=20 > domains (which constitutes an additional constraint)." >=20 > [dp] i read this, mind you, my point is that this is not a=20 > "constraint"=20 > of > the same nature as the one you're making use such as minimize=20 > delays or whatsover - this constraint is introduced from the=20 > computation technique and mechanism of this proposed method=20 >=20 > Note that at this point, I still do not see the point that=20 > you're trying to make here ? >=20 > since so far when > a set of domains do not support/or support a given=20 > computation has not yet become a constraint >=20 > hence sentence "The BRPC procedure guarantees to compute the=20 > optimal path across a specific set of traversed domains=20 > (which constitutes an additional constraint). In the case of=20 > an arbitrary set of meshed domains, the BRPC procedure can be=20 > used to compute the optimal path across each domain set in=20 > order to get to optimal constrained path between the source=20 > and the destination of the TE LSP." >=20 > should as far as i understand the method fulfill the following >=20 > a) this method provides a result iff all domains traversed by=20 > the request support the proposed method >=20 > BRPC is a multi-PCE based approach where you need at least=20 > one PCE per-domain. >=20 > [dp] indeed, but one PCE supporting that method and having=20 > FULL visibility of the domain >=20 > So what is your point here ? >=20 > [dp] that the set of conditions to have this method workable=20 > is larger than the one listed in this doc. >=20 > b) this method provides an "optimal" result iff >=20 > b1) all possible sequences of domains have been traversed=20 > (starting from the root) and are supportive of that method -=20 > as there might be an optimal path through a domain not=20 > supporting this method - >=20 >=20 > heu ... yes indeed. If a domain does not support the method,=20 > the method cannot be used to compute the path. >=20 > b2) there is no discontinuity in the availability of the=20 > inter-AS link information on each PCE performing a given=20 > selection - indeed a domain might be supportive of the method=20 > without supporting inter-AS link flooding >=20 > No this is not a requirement, just an optimization. The only=20 > requirement is for the PCE to get the TE-related data about=20 > the Inter- AS links. I'll detail a bit more in the next revision. >=20 > [dp] then you can never achieve - >=20 > You can never achieve what ? >=20 > Sorry Dimitri, I'd love to accommodate your comment but I do=20 > not see your point ... hopefully we'll have a bit of time in=20 > Montreal to discuss if that does not work by email. >=20 > [dp] my point is that without this additional information you=20 > can not achieve the expected result - i pointed to your own=20 > text to indicate that this information is a must have in=20 > order to achieve this objective=20 >=20 > using your own words to make it more > straighforward -=20 >=20 > "you still need the BRPC procedure to figure out the set of=20 > BN (boundary > Nodes) to traverse to get the shortest inter-domain TE LSP:=20 > this is the whole issue with inter-domain, otherwise=20 > per-domain path computation would=20 >=20 > be sufficient." >=20 > b3) at each step there is no PCE that has partial visibility=20 > of a given domain >=20 >=20 > This is not specific to BRPC. Even with intra-domain if you want to=20 > compute the path for a TE LSP, you cannot always use the PCE if it=20 > has a partial visibility. Note that this also applies to the case of=20 > co-located PCE (when the path is computed by the head-end). >=20 > [dp] hence, to BRPC as well >=20 > b4) during the selection process no network conditions changes=20 > (that would > make the returned result void) >=20 >=20 > Again, this applies to other cases as well. >=20 > [dp] ditto >=20 >=20 > Ah so we agree here :-) >=20 > What was your comment then ? >=20 > [dp] that you need to include these set of working conditions in the=20 > document itself, the document looks like quite simple in terms of=20 > conditions for having the proposed method working as expected=20 > while when=20 > you take a closer look at it this is not the case >=20 > Thanks. >=20 > JP. >=20 >=20 >=20 > thanks. >=20 > JP. >=20 >=20 >=20 >=20 >=20 >=20 > JP Vasseur > 23/06/2006 16:11 >=20 > To: "Adrian Farrel" > cc: raymond=5Fzhang@bt.infonet.com, pce@ietf.org, > nabil.n.bitar@verizon.com > Subject: [Pce] Re: Comments on > draft-vasseur-pce-brpc-00.txt >=20 >=20 > Many Thanks Adrian for the comments. >=20 > We incorporated the vast majority of them in the new revision (just > posted). >=20 > See below for the comments requesting some clarification. >=20 > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >=20 > Hi, >=20 > Thanks for keeping these ideas alive. >=20 > Here are some picky thoughts that you may want to include in the next > revision to make it more robust as a document. I don't have any issues > with > the basic process. >=20 > Thanks, > Adrian >=20 > =3D=3D > Is this I-D likely to be Informational or Standards Track? From=20 > Appendix > A, > this looks like Standards Track. Can you remove Appendix A and put the > status in the usual place in the header? > =3D=3D >=20 > Status has been updated (Informational) but let's discuss this=20 > later on. > FYI, it does not appear on the front page when using the xml2rfc=20 > editor > (which by the way is excellent), thus the appendix addition. >=20 > It would be nice if the Abstract contained a pithy summary of brpc=20 > and/or > gave the motivation for the draft. For example, what is the method=20 > trying > to > achieve that isn't achievable by other methods? Or, what is the > fundamental > element of brpc that is not in other methods? >=20 > Agree. Here is the new Abstract: > "The ability to compute constrained shortest Traffic Engineering (TE) > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)=20 > and > Generalized MPLS (GMPLS) networks across multiple domains (where a=20 > domain > is referred to as a collection of network elements within a common=20 > sphere > of address management or path computational responsibility such as IGP > areas and Autonomous Systems) has been identified as a key=20 > requirement . > This document specifies a procedure relying on the use of multiple=20 > Path > Computation Elements (PCEs) in order to compute such inter-domain=20 > shortest > constraint paths, using a backward recursive path computation=20 > technique > while fully preserving confidentiality requirements across domains. " >=20 >=20 > =3D=3D > I'm assuming that section 1 is for short term information only and=20 > will be > deleted (in the next revision?) > =3D=3D >=20 > Indeed, just to provide a bit of history for the ones who have been > following inter-domain path computation for a while. >=20 > =3D=3D > Section 4 > - No topology or resource information is distributed between domains > (as mandated per [RFC4105] and [RFC4216]), which is critical to > preserve IGP/BGP scalability and confidentiality in the case of TE > LSPs spanning multiple domains. > You should clarify what you are saying here, because many would=20 > argue that > reachability information (i.e. external routes) constitutes=20 > topology and > resource information. >=20 >=20 > OK fine >=20 > =3D=3D > Section 4 > - While certain constraints like bandwidth can be used across > different domains, certain other TE constraints like resource > affinity, color, metric, etc. as listed in [RFC2702] could be > translated at domain boundaries. If required, it is assumed=20 > that, at > the domain boundary LSRs, there will exist some sort of local=20 > mapping > based on offline policy agreement, in order to translate such > constraints across domain boundaries during the inter-PCE > communication process. > Why does the policy agreement need to be offline? >=20 >=20 > It should actually read "pre-determined". Actually the best thing=20 > to do > here is to remove "off-line" >=20 > =3D=3D > Section 5 > No assumption is made on the actual path computation algorithm in=20 > use > by the PCE (it can be any variant of CSPF, algorithm based on=20 > linear- > programming to solve multi-constraints optimization problems and so > on). > Suggest that you delete the text in parenthesis because it is making > suggestions that border on assumptions! >=20 > Well I'd suggest to keep it as is since the point is to=20 > differentiate the > path computation procedure from the algorithm to compute each intra-=20 > domain > path segment. Furthermore, we'd like to highlight the fact that the=20 > BRPC > procedure does not mandate for each PCE to use CSPF, could be other > algorithm. >=20 > =3D=3D > Section 5.1 and throughout > "BRPC path computation" seems to be tautologous >=20 > It is actually a double tautology ;-) (fixed). >=20 > =3D=3D > Section 5.1 > I like the simplicity of section 5.1, but I think you need to point=20 > out > that > if the sequence of domains is known a priori (can you determine it a > priori?) then the path computed might not be 'optimal' in the usual=20 > sense > of > the word, but that this is OK because the ordered list of domains > constitutes an additional constraint on the computation so the=20 > resultant > path *is* optimal within the constraints applied. >=20 > Can't agree more. Good suggestion, thanks. >=20 > Updated text: "The PCE-based BRPC procedure applies to the=20 > computation of > an optimal constrained inter-domain TE LSP. The sequence of domains=20 > to be > traversed can either be determined a priori or during the path=20 > computation > procedure. The BRPC procedure guarantees to compute the optimal path > across a specific set of traversed domains (which constitutes > an additional constraint). In the case of an arbitrary set of meshed > domains, the BRPC procedure can be used to compute the optimal path=20 > across > each domain set in order to get to optimal constrained path between=20 > the > source and the destination of the TE LSP." >=20 > =3D=3D > Section 5.2 > The introduction of the term Virtual Shortest Path Tree is hard to=20 > parse > and > to my mind the definition is arse about tit. I think you could=20 > usefully > add > some textual definition of what the VSPT is trying to achieve, before > presenting it in pictorial or abstract form. > Even more important (I think) is the fact that the tree as presented > "represents the shortest path between the destination and BR-en=20 > (j,i)..." > Frankly, we are building directional paths in exactly the oposite > direction! >=20 > This is an abstract form of representation but see below, >=20 > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP=20 > tree as > described. > I suspect that this is just a textual descriptive issue rather than > anything > broken in the process. >=20 >=20 > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P=20 > tree). >=20 > =3D=3D > Section 5.2 > I suggest that you pull the note (Note: in term of computation...) out > into > a separate section. It doesn't belong in the middle of section 5.2. > You will probably want to re-write the text as well since the > unidirectional > limit is not necessary. Also to explain 'flood' - flood to where,=20 > and how, > and by whom? And you will want to add to pieces of information: > - the link to the I-D that defines how to do this > - a description of what happens if this process is not used. >=20 > This only works for unidirectional LSPs: indeed, the exit boundary=20 > node > can flood TE-related data in its LSA/LSP for the link > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP=20 > running on > the link but how would a node in domain (i) get the TE-related data=20 > for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction on > unidirectional link. Are we in sync ? >=20 > =3D=3D > Section 5.2 > The paragraph that begins "BRPC guarantees to find the optimal..."=20 > is a > nascent Applicability Statement. I suggest moving this to another=20 > Section > and significantly beefing it up. You need to describe more fully: > - how ECMP works (the PCC has to request the return of more than=20 > one path) > - how diversity works (i.e. section 9 fits in here) > - how some freedom of selection of domains can be offered > - how to mix the method with other mechanisms >=20 > This was (and is) planned for future revision. Note that ECMP and > diversity are discussed already but we're planning the flesh out these > sections in further revision. >=20 > =3D=3D > Section 7 > If the BRPC procedure cannot be completed because a PCE along the > domain path does not support the procedure, a PCErr message is > returned by the upstream PCE with a Error-Type "BRPC procedure > completion failure". The PCErr message MUST be relayed to the > requesting PCC. > Not clear to me whether PCE(n) is supposed to know that PCE(n+1)=20 > does not > support brpc, presumably through capabilities > configuration/advertisement/negotiation, or whether PCE(n+1) is=20 > supposed > to > respond to the path computation request saying that it does not=20 > support > bit-V of the RP object. If the latter, presumably the PCErr comes from > PCE(n+1) and not from PCE(n) as documented. >=20 > Good catch, typo: it should read "a PCErr message is returned to the > upstream". > The plan is to define a capability bit (IGP) in a further revision. >=20 > =3D=3D > Section 8 > Metric normalisation is a great potential solution, but how does it=20 > fit > with > AS topology confidentiality? What is the solution to providing=20 > discretion > about what TE connectivity is available within an AS, and operating=20 > brpc? >=20 > Metric normalization is handled locally by the PCE and does not=20 > impact the > BRPC procedure per-say. As far as confidentiality is concerned,=20 > this only > requires for the SPs to exchange metric mapping information (nothing > related to the network topology or resources); for example > SP 1 Links Cost =3D F (link=5Fbandwidth) with F (OC192)=3D1 > SP 2 Links Cost =3D F (link=5Fbandwidth) with F (OC192)=3D10 >=20 > A simple metric normalization can then be performed on the PCE=20 > thanks to > simple cost mapping tables. >=20 > Section 10 > Some of this text has been seen before in this I-D > Why do you single out LSP stitching as possibly breaking end-to-end > optimality. There is functionally no difference between stitching and > nesting in this respect. > But further, your statement about stitching is pejorative! If you=20 > say that > "In the case where a domain has more than one BR-en or more than one > BR-ex, > optimality after some network change within the domain can only be > guaranteed by re-executing the full brpc computation" then I would=20 > agree > with you. But as phrased, it implies that making a per-domain > re-optimisation could make the path *less* optimal. This (of=20 > course) is > not > the case - per-domain optimisation will always improve or leave the=20 > same > end-to-end optimality (in the case where new resources are made=20 > available > this is obvious; in the case of a network failure, *any* path is=20 > better > than > no path!) > And, lastly, the text about re-optimisation belongs in the next=20 > section, > not > in this section. >=20 >=20 > Yes I wanted to leave that text to keep track of who would read the=20 > ID, > expecting reaction ;-)) Per-domain reoptimization would always=20 > improve the > current path *but* in case of stitched LSPs, TE LSP segments are=20 > computed > by the stitching point; thus in case of failure, they could end up > following a non optimal path whereas in the case of contiguous LSP,=20 > the > BRPC procedure would be called again thus leading to the optimal path > again. The point that I was trying to make is "if you have a=20 > stitched LSP > and rely on BRPC when first signaled in an attempt to get an=20 > optimal path, > you need to consider the interaction between the local reopt mode=20 > and BRPC > if the goal is to preserve an optimal path at any given time". Anyway, > we're on the same page and I agree and the text should be reworded > according to your proposal to avoid any misunderstanding. >=20 > =3D=3D > Section 13 > I would like you to discuss the issues of confidentiality of topology > information at greater length. It seems that you would possibly use=20 > this > technique in conjunction with path cookies, which is fine. But, are=20 > there > two things you cannot escape from? > - indicating which BR-en provides best connectivity > - indicating the metric for multiple BR-ens > Maybe there are some things that can be done here based on policy, > including > not reporting all of the BR-ens, ranking rather than giving absolute > metrics, etc. But these would compromise optimality. >=20 > Indeed. >=20 > Maybe the PCE(n+1) should carefully monitor and limit=20 > (statistically and > by > policy) brpc requests so that excessive information is not divulged? >=20 > Since one of objectives for using the BRPC procedure is to compute an > optimal path, we need to know at least the BN (Boundary Nodes) and the > cost. >=20 > =3D=3D > I wouldn't mind seeing a Management Considerations section. > Do we need to be able to examine the pruned pieces of VSPT at transit > PCEs? > What are the implications of reporting multiple VSPT branches in=20 > PCEP to > the > MIB modules? > Is brpc support something that needs to be configured: per PCE?; per > PCE-neighbor? > What are the implications on existing protocols (IGPs? PCEP?) of using > brpc? >=20 > Absolutely ! I put a placeholder for a further revision. >=20 > Fully supportive of adding such section. >=20 > Many Thanks for your comments ! >=20 > JP. >=20 > etc. > =3D=3D >=20 >=20 >=20 >=20 >=20 > I think Jean-Louis' email address needs updating >=20 >=20 > =3D=3D > The document would benefit from a little care in the formatting,=20 > and you > could usefully re-read it for missing words, etc. > =3D=3D > =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 > =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 >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jun 26 11:21:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusuH-0002JJ-W8; Mon, 26 Jun 2006 11:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FusuG-0002JC-94 for pce@ietf.org; Mon, 26 Jun 2006 11:21:44 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusuA-0001BT-Po for pce@ietf.org; Mon, 26 Jun 2006 11:21:44 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fusu7-0004RW-00 for pce@ietf.org; Mon, 26 Jun 2006 16:21:35 +0100 Received: from your029b8cecfe ([194.94.109.154] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 16:21:37 +0100 Message-ID: <041801c69934$357b25d0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "JP Vasseur" References: <02e001c68cae$d1f154d0$c2849ed9@your029b8cecfe> <81769A42-39BD-499A-9501-BA3EA61F000A@cisco.com> Date: Mon, 26 Jun 2006 16:19:59 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 26 Jun 2006 15:21:37.0822 (UTC) FILETIME=[37AF43E0:01C69934] X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com Subject: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt 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 >> == >> Is this I-D likely to be Informational or Standards Track? From >> Appendix A, >> this looks like Standards Track. Can you remove Appendix A and put the >> status in the usual place in the header? >> == > > Status has been updated (Informational) but let's discuss this later > on. FYI, it does not appear on the front page when using the xml2rfc > editor (which by the way is excellent), thus the appendix addition. You could always tell the tools team about this. >> It would be nice if the Abstract contained a pithy summary of brpc >> and/or gave the motivation for the draft. For example, what is the >> method trying to achieve that isn't achievable by other methods? >> Or, what is the fundamental element of brpc that is not in other >> methods? > > Agree. Here is the new Abstract: > "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 (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) has been > identified as a key requirement . This document specifies a procedure > relying on the use of multiple Path Computation Elements (PCEs) in > order to compute such inter-domain shortest constraint paths, using a > backward recursive path computation technique while fully preserving > confidentiality requirements across domains. " Good. >> == >> Section 5 >> No assumption is made on the actual path computation algorithm in >> use by the PCE (it can be any variant of CSPF, algorithm based >> on linear-programming to solve multi-constraints optimization >> problems and so on). >> Suggest that you delete the text in parenthesis because it is making >> suggestions that border on assumptions! > > Well I'd suggest to keep it as is since the point is to differentiate > the path computation procedure from the algorithm to compute each > intra-domain path segment. Furthermore, we'd like to highlight the > fact that the BRPC procedure does not mandate for each PCE to use > CSPF, could be other algorithm. Honetsly, I think that everything you want to say is covered by "No assumption is made on the actual path computation algorithm in use by the PCE" The text in parentheses is overly suggestive, and not as generic as you might hope. If you need/want to convey a more detailed message, I suggest you do it by explicit text, not by example. Add in place of the parentheses... "That is, the path computation procedure is separated from the computation algorithm and the algorithm need not be limited to simple CSPF." >> == >> Section 5.2 >> I suggest that you pull the note (Note: in term of computation...) >> out into a separate section. It doesn't belong in the middle of >> section 5.2. >> You will probably want to re-write the text as well since the >> unidirectional limit is not necessary. Also to explain 'flood' - >> flood to where, and how, and by whom? And you will want >> to add to pieces of information: >> - the link to the I-D that defines how to do this >> - a description of what happens if this process is not used. > > This only works for unidirectional LSPs: indeed, the exit boundary > node can flood TE-related data in its LSA/LSP for the link exit-BN > (i,k)->entry-BN(i+1,k') even in the absence of any IGP running on the > link but how would a node in domain (i) get the TE-related data for > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction > on unidirectional link. Are we in sync ? Ah. This seems to be Dimitri's point. Does that mean that brpc cannot be applied to bidirectional services where inter-domain links exist? Is that consistent with the use for GMPLS? >> === >> Section 10 >> Some of this text has been seen before in this I-D >> Why do you single out LSP stitching as possibly breaking end-to-end >> optimality. There is functionally no difference between stitching and >> nesting in this respect. >> But further, your statement about stitching is pejorative! If you >> say that >> "In the case where a domain has more than one BR-en or more than >> one BR-ex, optimality after some network change within the domain >> can only be guaranteed by re-executing the full brpc computation" >> then I would agree with you. But as phrased, it implies that >> making a per-domain re-optimisation could make the path >> *less* optimal. This (of course) is not the case - per-domain >> optimisation will always improve or leave the same >> end-to-end optimality (in the case where new resources are made >> available this is obvious; in the case of a network failure, *any* >> path is better than no path!) >> And, lastly, the text about re-optimisation belongs in the next >> section, not in this section. >> > > Yes I wanted to leave that text to keep track of who would read the > ID, expecting reaction ;-)) Per-domain reoptimization would always > improve the current path *but* in case of stitched LSPs, TE LSP > segments are computed by the stitching point; thus in case of > failure, they could end up following a non optimal path whereas in > the case of contiguous LSP, the BRPC procedure would be called again > thus leading to the optimal path again. The point that I was trying > to make is "if you have a stitched LSP and rely on BRPC when first > signaled in an attempt to get an optimal path, you need to consider > the interaction between the local reopt mode and BRPC if the goal is > to preserve an optimal path at any given time". Anyway, we're on the > same page and I agree and the text should be reworded according to > your proposal to avoid any misunderstanding. OK. Yes, some wordsmitthing is needed to explain local optimisation (for stitching *and* tunneling) compared to end-to-end optimisation. Cheers, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jun 27 13:42:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHZf-0006gC-PT; Tue, 27 Jun 2006 13:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHZd-0006g4-Vh for pce@ietf.org; Tue, 27 Jun 2006 13:42:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHZc-0004dK-KI for pce@ietf.org; Tue, 27 Jun 2006 13:42:05 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jun 2006 13:42:04 -0400 X-IronPort-AV: i="4.06,183,1149480000"; d="scan'208,217"; a="91121977:sNHT46759660" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5RHg4no021703; Tue, 27 Jun 2006 13:42:04 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 13:42:04 -0400 Received: from [161.44.68.240] ([161.44.68.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 13:42:03 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Tue, 27 Jun 2006 13:42:02 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 27 Jun 2006 17:42:03.0654 (UTC) FILETIME=[0048F260:01C69A11] X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Subject: [Pce] Draft PCE WG Meeting agenda 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="===============0025164852==" Errors-To: pce-bounces@lists.ietf.org --===============0025164852== Content-Type: multipart/alternative; boundary=Apple-Mail-41--823252921 --Apple-Mail-41--823252921 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed WG, A draft agenda of the next PCE WG meeting has been uploaded: http:// www3.ietf.org/proceedings/06jul/agenda/pce.txt If you've got comment, please unicast Adrian and myself. THURSDAY, July 13, 2006 1300-1500 Afternoon Session I Room 513B APP dmsp Distributed Multimodal Synchronization Protocol BOF Room 519B INT pana Protocol for carrying Authentication for Network Access WG Room 519A OPS bmwg Benchmarking Methodology WG Room 518AB RAI xcon Centralized Conferencing WG Room 515 RTG manet Mobile Ad-hoc Networks WG Room 513C-F RTG pce Path Computation Element WG Room 520DEF SEC saag Security Area Directorate Open Meeting Room 520ABC TSV tcpm TCP Maintenance and Minor Extensions WG Thanks. JP. --Apple-Mail-41--823252921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 WG,

A draft agenda of the next = PCE WG meeting has been uploaded:=A0http://www3= .ietf.org/proceedings/06jul/agenda/pce.txt

If you've got comment, = please unicast Adrian and myself.

THURSDAY, July 13, = 2006

1300-1500 Afternoon Session = I
Room 513B APP dmsp Distributed Multimodal Synchronization Protocol = BOF
Room 519B INT pana Protocol for carrying Authentication for Network = Access WG
Room 519A OPS bmwg Benchmarking Methodology = WG
Room 518AB RAI xcon Centralized Conferencing WG
Room 515 RTG manet Mobile Ad-hoc Networks WG
Room 513C-F RTG pce Path Computation Element WG
Room 520DEF SEC saag Security Area Directorate Open = Meeting
Room 520ABC TSV tcpm TCP Maintenance and Minor = Extensions WG

Thanks.

Date: Tue, 27 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-07.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 : Path Computation Element (PCE) Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-07.txt Pages : 19 Date : 2006-6-27 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-comm-protocol-gen-reqs-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-07.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-6-27113146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-comm-protocol-gen-reqs-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27113146.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 Tue Jun 27 16:51:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKXK-0003vG-ID; Tue, 27 Jun 2006 16:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKXI-0003tI-UR; Tue, 27 Jun 2006 16:51:52 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwS-0005RX-H2; Tue, 27 Jun 2006 16:13:48 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJaS-0003X5-DO; Tue, 27 Jun 2006 15:51:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo2jx016443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005HB-AD; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-req-02.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 : PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering Author(s) : E. Oki Filename : draft-ietf-pce-inter-layer-req-02.txt Pages : 9 Date : 2006-6-27 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-02.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-inter-layer-req-02.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-inter-layer-req-02.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-6-27125212.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27125212.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 Tue Jun 27 16:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKXc-0004be-TV; Tue, 27 Jun 2006 16:52:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKXb-0004ZB-PA; Tue, 27 Jun 2006 16:52:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwT-0005Ox-7Q; Tue, 27 Jun 2006 16:13:49 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJaS-0003X0-B4; Tue, 27 Jun 2006 15:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo2jx016445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005HW-DZ; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-frwk-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 --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 : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-frwk-01.txt Pages : 16 Date : 2006-6-27 A network may comprise of multiple layers. It is important to globally optimize network resources utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for the PCE-based path computation architecture to inter-layer MPLS and GMPLS traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-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-ietf-pce-inter-layer-frwk-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-ietf-pce-inter-layer-frwk-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. --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-6-27130923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-frwk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-frwk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27130923.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 Tue Jun 27 17:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKpe-0000VQ-UT; Tue, 27 Jun 2006 17:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKpd-0000Rj-AX; Tue, 27 Jun 2006 17:10:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwV-0005Q8-CW; Tue, 27 Jun 2006 16:13:51 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJZS-0003Tw-KZ; Tue, 27 Jun 2006 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo29F012459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZS-0005GS-1f; Tue, 27 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-disco-proto-igp-02.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 : IGP protocol extensions for Path Computation Element (PCE) Discovery Author(s) : J. Le Roux, et al. Filename : draft-ietf-pce-disco-proto-igp-02.txt Pages : 37 Date : 2006-6-27 There are various circumstances in which it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Element(s) (PCE), along with some of information that can be used for PCE selection. When the PCE is an LSR participating to the IGP, or even a server participating passively to the IGP, a simple and efficient way for PCE discovery consists of relying on IGP flooding. For that purpose this document defines OSPF and ISIS extensions for the advertisement of PCE Discovery information within an IGP area or within the entire routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-disco-proto-igp-02.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-disco-proto-igp-02.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-disco-proto-igp-02.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-6-27122401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-disco-proto-igp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-disco-proto-igp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27122401.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 Tue Jun 27 19:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMas-0000du-4U; Tue, 27 Jun 2006 19:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMaq-0000db-Se for pce@ietf.org; Tue, 27 Jun 2006 19:03:40 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FvMao-0007ce-FR for pce@ietf.org; Tue, 27 Jun 2006 19:03:40 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1151449313!12036688!17 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1611 invoked from network); 27 Jun 2006 23:03:37 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-120.messagelabs.com with SMTP; 27 Jun 2006 23:03:37 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 449EB45200053238 for pce@ietf.org; Tue, 27 Jun 2006 19:03:37 -0400 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 Subject: RE: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-07.txt Date: Tue, 27 Jun 2006 18:03:35 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7A05@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-07.txt Thread-Index: AcaaIvCnX6S/fEcyT3S6ap4vRedLcQAFqFDg From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 All, The updated PCECP Generic Requirements draft is available at http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-07.txt. Changes are made to respond to the IESG DISCUSS comments at https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dprint_ballot= & ballot_id=3D2000&filename=3Ddraft-ietf-pce-comm-protocol-gen-reqs. The = main changes are: 1. Section 6.1.3 (Transport) updated to require "The PCECP SHOULD utilize an existing transport protocol that supports congestion control." 2. Section 7 (Security Considerations) updated to require "Key management MUST be provided by the PCECP to provide for the authenticity and integrity of PCECP messages." 3. Section 6.1.9 (Secure Message Exchange) updated to discuss confidentiality and authorization. Changes made in response to the gen-art review include the following: 4. Eliminated Section 6.4 (Summary of Requirements) for the following reasons: - went on for almost 3 pages, not really a "summary" - significantly increased length, wanted to limit to 10 pages - not an exhaustive list (i.e., a summary), cannot eliminate reading all of Section 6 in any case - no such summary used in other requirements documents 5. Section 6.3.3 (LSP Rerouting & Reoptimization) updated to require "The PCE MAY or MAY not take into account a failure indication carried in a given request when handling subsequent requests. This should be driven by local policy decisions." 6. various other editorial changes. Please let us know of any comments. Thanks, Jerry=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, June 27, 2006 3:50 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-07.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-07.txt Pages : 19 Date : 2006-6-27 =09 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-07.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jun 28 03:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUOL-0000qt-8l; Wed, 28 Jun 2006 03:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvUOJ-0000qo-J3 for pce@ietf.org; Wed, 28 Jun 2006 03:23:15 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvUOH-0005yv-5s for pce@ietf.org; Wed, 28 Jun 2006 03:23:15 -0400 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5S7NC9s004762 for ; Wed, 28 Jun 2006 09:23:12 +0200 To: pce@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Wed, 28 Jun 2006 09:23:06 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/28/2006 09:23:11, Serialize complete at 06/28/2006 09:23:11 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Pce] on draft-oki-pce-vntm-def-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 folks reading this document the vnt functionality communicates with the pce; nevertheless it seems the operations the former allows are setup/triggers (note that the triggers are not exclusively coming from a pce/going toward a pce as the draft indicates, a simple lsr with could do the job), resource/ advertisement policing, etc. i.e. functions that are stricto sensu decoupled from pce ... hence shouldn't this document be not discussed in the context of the ccamp wg (as a vnt operations are independent of the presence of a pce, presence of the latter wrt to vnt is similar to the presence of a pce wrt to lsrs) ? thanks, - dimitri. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jun 28 10:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbS6-0002Qf-18; Wed, 28 Jun 2006 10:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbS5-0002Qa-DT for pce@ietf.org; Wed, 28 Jun 2006 10:55:37 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbS3-0008T3-Ue for pce@ietf.org; Wed, 28 Jun 2006 10:55:37 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 15:18:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Wed, 28 Jun 2006 15:18:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Thread-Index: AcaZMo7G89qpozZNTYm2pscbn0GyjwABM0mw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 28 Jun 2006 13:18:50.0807 (UTC) FILETIME=[656D7C70:01C69AB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9624d2f5d047d13a089d0be4702e088f Cc: raymond_zhang@bt.infonet.com, nabil.n.bitar@verizon.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, See inline,=20 > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel.be=20 > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > Envoy=E9 : lundi 26 juin 2006 17:09 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN > Cc : JP Vasseur; nabil.n.bitar@verizon.com; pce@ietf.org;=20 > raymond_zhang@bt.infonet.com > Objet : RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >=20 > hi j-l - thanks for these clarifications - see in-line for a=20 > couple of remarks >=20 >=20 >=20 >=20 > "LE ROUX Jean-Louis RD-CORE-LAN" > 26/06/2006 16:37 > =20 > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP=20 > Vasseur"=20 > > cc: ,=20 > , > Subject: RE: [Pce] Re: Comments on=20 > draft-vasseur-pce-brpc-00.txt >=20 >=20 > Hi Dimitri, > =20 > Please see inline,=20 >=20 > > -----Message d'origine----- > > De : Dimitri.Papadimitriou@alcatel.be=20 > > [mailto:Dimitri.Papadimitriou@alcatel.be]=20 > > Envoy=E9 : lundi 26 juin 2006 15:43 > > =C0 : JP Vasseur > > Cc : raymond_zhang@bt.infonet.com; nabil.n.bitar@verizon.com;=20 > > pce@ietf.org > > Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt > >=20 > > hi=20 > >=20 > > i don't think 1) and 2) have been captured=20 > >=20 > > on 1) there is a terminology issue - indeed - but there is=20 > > also an issue that is the arbitrary selection/pruning of=20 > > other potential alternatives - why that sequence ? and not=20 > > another - was mentioned as the chicken-egg > > (technical) problem; first there may be many available=20 > > interdomain paths that are never learned by the LSRs,=20 > >more=20 > > generically the diversity of the BGP routes available at each=20 > > LSR is not sufficient to successfully provide for a=20 > > satisfactory sequence; on the other hand, you may have=20 > > receive multiple let's take an example to illustrate there=20 > > are two AS path between A and D, one A-B-C-D the other=20 > > A-E-F-D disjoint (on intermediate ASs) either both sequences=20 > > are valid both policing and filtering makes you selecting the=20 > > inappropriate sequence for the real TE-LSP consrttaints >=20 > In the inter-AS case, inter-AS selection is likely to be driven by=20 > business considerations and will be the result of (static or dynamic)=20 > inter-SP service negociation and execution. Note that, as recalled by=20 > Adrian, the objective is NOT to setup TE-LSPs over the Internet... > Also in your example, one may simply run two BRPC with the=20 > two AS-Path and=20 > select the best result... >=20 > [dp] in the inter AS case, which is the most challenging, are=20 > you telling=20 > me that the whole policing and filtering is done but based on=20 > information=20 > elements that require further negotiation phases - such that your=20 > selection is not susceptible to lead you to a case where the AS_path=20 > doesn't provide you any further information but your initial=20 > negotiation=20 > makes it such that the probability of making the wrong selection is=20 > minimized - taking the example i gave here above: two AS path=20 > between A=20 > and D, one A-B-C-D the other=20 > A-E-F-D disjoint (on intermediate ASs) and both sequences are=20 > valid - but=20 > now policing and filtering makes you selecting the=20 > appropriate sequence=20 > for the real TE-LSP consrttaints ?=20 Yes, this is what I meant >if this is the case some further=20 > inlightment may be really helpful - This is already stated: "The domain path (set of domains traversed to reach the destination = domain) is either administratively pre-determined or discovered by some = means (outside of the scope of this document)". There is nothing more to say in this draft IMO. >=20 > In the inter-area case, areas selection is straightforward. >=20 > > on 2) this is part of the answer - the comment was PCE per=20 > > domain supporting that method - and in case of two PCEs or=20 > > more per domain i am not sure how one could guarantee that=20 > > the proposed (recursive) sequence works (assumption is made=20 > > that the PCE as full visibility on the whole domain but what=20 > > in case of multiple PCEs per domain) >=20 > If these PCEs have the same visibility then there is NO issue. > If these PCEs don't have the same visibility, then actually you have=20 > multiple sub-domains within the domain (or multiple domains=20 > within a super=20 > domain!), the pratical case being inter-AS path computation=20 > where each AS=20 > is made of several areas. > Is that your concern? >=20 > [dp] my concern is that segmentation of PCE roles is not necessarily=20 > mapping domain boundaries (intra-AS)=20 Please note that in PCE terminology a "domain" is a generic term, this = is a set of elements with a common sphere of path computation = responsiblity (this is not limited to IGP areas, ASes). Hence the set of = elements under PCE visibility is by definition a "domain", and = segmentation of PCE roles IS mapping "domain" boudaries. The procedures defined in this doc apply to multiple "domains", with = this generic definition of "domains". > and the other case is when for=20 > instance could have as example that for a given "AS" a PCE=20 > taking care of=20 > TDM links and another ETH links hence you would have a=20 > bifurcation - i=20 Then you have at least two "domains" (one for TDM and one for ETH), and = the procedures apply as is. More generally when you have a hierachy of domains (e.g. AS domains, on = top of area domains on top of techno domains) you need to run the BRPC = procedure at each level. When you run the BRCP procedure at level N you need to compute level N = path segments, and this requires calling BRPC at level N-1, this is = recursive. Best Regards JL > mean you get a sequence of AS from routing but for each AS=20 > there may be a=20 > set of PCE which not structured such as to map the routing=20 > topology - i=20 > can rephrase as for a sequence of AS there can be multiple=20 > sequences of=20 > PCEs if these have not complete view you need to deal with=20 > intermediate=20 > recombination of information on the return path or make a=20 > selection of=20 > PCEs on the forward path - the doc. currently says "If=20 > multiple PCEs are=20 > discovered, the PCE may select a subset of these PCEs based=20 > on some local=20 > policies/heuristics." what in case it doesn't ? >=20 > In this situation, the inter-AS BRPC procedure triggers a set of=20 > inter-area BRPC procedures in each AS to compute intra-AS (ie=20 > inter-area)=20 > path segments in each AS.=20 >=20 > Regards, >=20 > JL >=20 > =20 >=20 > Regards >=20 > JL >=20 >=20 > >=20 > > i have also asked to have a better description of the working=20 > > conditions along this draft - to complete section 5.1 -=20 > >=20 > > if you consider this as non-technical or technical feedback=20 > > that's your own appreciation=20 > >=20 > > thanks, > > - dimitri. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > JP Vasseur > > 26/06/2006 14:54 > >=20 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > > raymond_zhang@bt.infonet.com > > Subject: Re: [Pce] Re: Comments on=20 > > draft-vasseur-pce-brpc-00.txt > >=20 > >=20 > > hi, > >=20 > > ok so to summarize there was no technical feed-back just a=20 > > few editorial comments.=20 > >=20 > > You'd like to add to the following to the document: > > 1) The set of traversed domains has to be known and according=20 > > to you this is not a constraint. > > I think that the current text is quite clear: > > "The BRPC procedure guarantees to compute the optimal path=20 > > across a specific set of traversed domains (which constitutes=20 > > an additional constraint)." > > Now if you want to reword a bit to avoid using the word=20 > "constraint"=20 > > although this *is* a constraint, this is no big deal. > >=20 > > Actually, interestingly enough there are quite a few cases=20 > > where there's only one single set of traversed domains. > >=20 > > 2) We need at least one PCE per domain > > Sounds quite obvious but I have no problem adding this.=20 > > Actually we're planning in the next revision to elaborate a=20 > > little bit on the inter-As link flooding (again this is not a=20 > > requirement but an optimization) but this will be covered. > >=20 > > JP. > >=20 > > On Jun 26, 2006, at 2:51 AM, Dimitri.Papadimitriou@alcatel.be wrote: > >=20 > > hi j-p - see in-line > >=20 > >=20 > >=20 > >=20 > > JP Vasseur > > 26/06/2006 02:42 > >=20 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: nabil.n.bitar@verizon.com, pce@ietf.org,=20 > > raymond_zhang@bt.infonet.com > > Subject: Re: [Pce] Re: Comments on=20 > > draft-vasseur-pce-brpc-00.txt > >=20 > >=20 > > hi dimitri, > >=20 > > On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: > >=20 > > hi j-p - see in-line > >=20 > >=20 > >=20 > >=20 > > JP Vasseur > > 26/06/2006 01:14 > >=20 > > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL > > cc: "Adrian Farrel" ,=20 > > nabil.n.bitar@verizon.com, pce@ietf.org,=20 > raymond_zhang@bt.infonet.com > > Subject: Re: [Pce] Re: Comments on=20 > > draft-vasseur-pce-brpc-00.txt > >=20 > >=20 > > hi dimitiri, > >=20 > > On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: > >=20 > > the following comment was also discussed during last meeting > >=20 > > "=3D=3D > > Section 5.1 > > I like the simplicity of section 5.1, but I think you need to=20 > > point out that if the sequence of domains is known a priori=20 > > (can you determine it a > > priori?) then the path computed might not be 'optimal' in the=20 > > usual sense of the word, but that this is OK because the=20 > > ordered list of domains constitutes an additional constraint=20 > > on the computation so the resultant path *is* optimal within=20 > > the constraints applied. > >=20 > > Can't agree more. Good suggestion, thanks. > >=20 > > Updated text: "The PCE-based BRPC procedure applies to the=20 > > computation of an optimal constrained inter-domain TE LSP.=20 > > The sequence of domains to be traversed can either be=20 > > determined a priori or during the path computation procedure.=20 > > The BRPC procedure guarantees to compute the optimal path=20 > > across a specific set of traversed domains (which constitutes=20 > > an additional constraint). In the case of an arbitrary set of=20 > > meshed domains, the BRPC procedure can be used to compute the=20 > > optimal path across each domain set in order to get to=20 > > optimal constrained path between the source and the=20 > > destination of the TE LSP." > >=20 > > =3D> in brief, how to determine the sequence through which path=20 > > computation has to be performed because if this sequence was=20 > > known there is no need for such procedure (only inter-domain=20 > > link selection would be > > required) - > >=20 > > Not correct; even if you know the sequence you still need the=20 > > BRPC procedure to figure out the set of BN (boundary Nodes)=20 > > to traverse to get the shortest inter-domain TE LSP: this is=20 > > the whole issue with inter-domain, otherwise per-domain path=20 > > computation would be sufficient. > >=20 > > [dp] inter-domain link selection (as i mentioned) implies=20 > > what you mean with boundary nodes selection - you could=20 > > rephrase by access/exit point selection exact same business > >=20 > > but again even if you know the sequence you still need BRPC=20 > > to determine the set of BN (or exit point - same thing) that=20 > > will give you the shortest inter-domain path. Look you wrote=20 > > "in brief, how to determine the sequence through which path=20 > > computation has to be performed because if this sequence was=20 > > known there is no need for such procedure", which is not=20 > > correct. Even if you know the sequence of domains, you still=20 > > need the procedure to get the exit/entry point (named BN)=20 > > that provide you the shortest inter-domain path. > >=20 > >=20 > > now adrian mentions that pre- determination becomes a new=20 > > constraint - well actually this is not a constraint for the=20 > > TE LSP itself but a restriction on the domain set known to be=20 > > (a-priori) supportive of the method such as to make the=20 > > method not returning an error message > >=20 > >=20 > > No, this is a constraint: "Give me the shortest path=20 > > (potentially made of loose hops (the BNs)) that provides the=20 > > shortest end to end path, considering that the additional=20 > > constraint is to traverse the following set of domains D2, ....>. > >=20 > > [dp] incorrect, this is not a "TE LSP" constraint -=20 > >=20 > > Who said that this was a TE LSP constraint ? This is *a*=20 > > constraint. If you impose the set of domain, this is a constraint. > >=20 > > Please read the text: "The BRPC procedure guarantees to=20 > > compute the optimal path across a specific set of traversed=20 > > domains (which constitutes an additional constraint)." > >=20 > > [dp] i read this, mind you, my point is that this is not a=20 > > "constraint"=20 > > of > > the same nature as the one you're making use such as minimize=20 > > delays or whatsover - this constraint is introduced from the=20 > > computation technique and mechanism of this proposed method=20 > >=20 > > Note that at this point, I still do not see the point that=20 > > you're trying to make here ? > >=20 > > since so far when > > a set of domains do not support/or support a given=20 > > computation has not yet become a constraint > >=20 > > hence sentence "The BRPC procedure guarantees to compute the=20 > > optimal path across a specific set of traversed domains=20 > > (which constitutes an additional constraint). In the case of=20 > > an arbitrary set of meshed domains, the BRPC procedure can be=20 > > used to compute the optimal path across each domain set in=20 > > order to get to optimal constrained path between the source=20 > > and the destination of the TE LSP." > >=20 > > should as far as i understand the method fulfill the following > >=20 > > a) this method provides a result iff all domains traversed by=20 > > the request support the proposed method > >=20 > > BRPC is a multi-PCE based approach where you need at least=20 > > one PCE per-domain. > >=20 > > [dp] indeed, but one PCE supporting that method and having=20 > > FULL visibility of the domain > >=20 > > So what is your point here ? > >=20 > > [dp] that the set of conditions to have this method workable=20 > > is larger than the one listed in this doc. > >=20 > > b) this method provides an "optimal" result iff > >=20 > > b1) all possible sequences of domains have been traversed=20 > > (starting from the root) and are supportive of that method -=20 > > as there might be an optimal path through a domain not=20 > > supporting this method - > >=20 > >=20 > > heu ... yes indeed. If a domain does not support the method,=20 > > the method cannot be used to compute the path. > >=20 > > b2) there is no discontinuity in the availability of the=20 > > inter-AS link information on each PCE performing a given=20 > > selection - indeed a domain might be supportive of the method=20 > > without supporting inter-AS link flooding > >=20 > > No this is not a requirement, just an optimization. The only=20 > > requirement is for the PCE to get the TE-related data about=20 > > the Inter- AS links. I'll detail a bit more in the next revision. > >=20 > > [dp] then you can never achieve - > >=20 > > You can never achieve what ? > >=20 > > Sorry Dimitri, I'd love to accommodate your comment but I do=20 > > not see your point ... hopefully we'll have a bit of time in=20 > > Montreal to discuss if that does not work by email. > >=20 > > [dp] my point is that without this additional information you=20 > > can not achieve the expected result - i pointed to your own=20 > > text to indicate that this information is a must have in=20 > > order to achieve this objective=20 > >=20 > > using your own words to make it more > > straighforward -=20 > >=20 > > "you still need the BRPC procedure to figure out the set of=20 > > BN (boundary > > Nodes) to traverse to get the shortest inter-domain TE LSP:=20 > > this is the whole issue with inter-domain, otherwise=20 > > per-domain path computation would=20 > >=20 > > be sufficient." > >=20 > > b3) at each step there is no PCE that has partial visibility=20 > > of a given domain > >=20 > >=20 > > This is not specific to BRPC. Even with intra-domain if you want to=20 > > compute the path for a TE LSP, you cannot always use the PCE if it=20 > > has a partial visibility. Note that this also applies to=20 > the case of=20 > > co-located PCE (when the path is computed by the head-end). > >=20 > > [dp] hence, to BRPC as well > >=20 > > b4) during the selection process no network conditions changes=20 > > (that would > > make the returned result void) > >=20 > >=20 > > Again, this applies to other cases as well. > >=20 > > [dp] ditto > >=20 > >=20 > > Ah so we agree here :-) > >=20 > > What was your comment then ? > >=20 > > [dp] that you need to include these set of working=20 > conditions in the=20 > > document itself, the document looks like quite simple in terms of=20 > > conditions for having the proposed method working as expected=20 > > while when=20 > > you take a closer look at it this is not the case > >=20 > > Thanks. > >=20 > > JP. > >=20 > >=20 > >=20 > > thanks. > >=20 > > JP. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > JP Vasseur > > 23/06/2006 16:11 > >=20 > > To: "Adrian Farrel" > > cc: raymond_zhang@bt.infonet.com, pce@ietf.org, > > nabil.n.bitar@verizon.com > > Subject: [Pce] Re: Comments on > > draft-vasseur-pce-brpc-00.txt > >=20 > >=20 > > Many Thanks Adrian for the comments. > >=20 > > We incorporated the vast majority of them in the new revision (just > > posted). > >=20 > > See below for the comments requesting some clarification. > >=20 > > On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: > >=20 > > Hi, > >=20 > > Thanks for keeping these ideas alive. > >=20 > > Here are some picky thoughts that you may want to include=20 > in the next > > revision to make it more robust as a document. I don't have=20 > any issues > > with > > the basic process. > >=20 > > Thanks, > > Adrian > >=20 > > =3D=3D > > Is this I-D likely to be Informational or Standards Track? From=20 > > Appendix > > A, > > this looks like Standards Track. Can you remove Appendix A=20 > and put the > > status in the usual place in the header? > > =3D=3D > >=20 > > Status has been updated (Informational) but let's discuss this=20 > > later on. > > FYI, it does not appear on the front page when using the xml2rfc=20 > > editor > > (which by the way is excellent), thus the appendix addition. > >=20 > > It would be nice if the Abstract contained a pithy summary of brpc=20 > > and/or > > gave the motivation for the draft. For example, what is the method=20 > > trying > > to > > achieve that isn't achievable by other methods? Or, what is the > > fundamental > > element of brpc that is not in other methods? > >=20 > > Agree. Here is the new Abstract: > > "The ability to compute constrained shortest Traffic=20 > Engineering (TE) > > Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS)=20 > > and > > Generalized MPLS (GMPLS) networks across multiple domains (where a=20 > > domain > > is referred to as a collection of network elements within a common=20 > > sphere > > of address management or path computational responsibility=20 > such as IGP > > areas and Autonomous Systems) has been identified as a key=20 > > requirement . > > This document specifies a procedure relying on the use of multiple=20 > > Path > > Computation Elements (PCEs) in order to compute such inter-domain=20 > > shortest > > constraint paths, using a backward recursive path computation=20 > > technique > > while fully preserving confidentiality requirements across=20 > domains. " > >=20 > >=20 > > =3D=3D > > I'm assuming that section 1 is for short term information only and=20 > > will be > > deleted (in the next revision?) > > =3D=3D > >=20 > > Indeed, just to provide a bit of history for the ones who have been > > following inter-domain path computation for a while. > >=20 > > =3D=3D > > Section 4 > > - No topology or resource information is distributed=20 > between domains > > (as mandated per [RFC4105] and [RFC4216]), which is critical to > > preserve IGP/BGP scalability and confidentiality in the case of TE > > LSPs spanning multiple domains. > > You should clarify what you are saying here, because many would=20 > > argue that > > reachability information (i.e. external routes) constitutes=20 > > topology and > > resource information. > >=20 > >=20 > > OK fine > >=20 > > =3D=3D > > Section 4 > > - While certain constraints like bandwidth can be used across > > different domains, certain other TE constraints like resource > > affinity, color, metric, etc. as listed in [RFC2702] could be > > translated at domain boundaries. If required, it is assumed=20 > > that, at > > the domain boundary LSRs, there will exist some sort of local=20 > > mapping > > based on offline policy agreement, in order to translate such > > constraints across domain boundaries during the inter-PCE > > communication process. > > Why does the policy agreement need to be offline? > >=20 > >=20 > > It should actually read "pre-determined". Actually the best thing=20 > > to do > > here is to remove "off-line" > >=20 > > =3D=3D > > Section 5 > > No assumption is made on the actual path computation algorithm in=20 > > use > > by the PCE (it can be any variant of CSPF, algorithm based on=20 > > linear- > > programming to solve multi-constraints optimization=20 > problems and so > > on). > > Suggest that you delete the text in parenthesis because it is making > > suggestions that border on assumptions! > >=20 > > Well I'd suggest to keep it as is since the point is to=20 > > differentiate the > > path computation procedure from the algorithm to compute=20 > each intra-=20 > > domain > > path segment. Furthermore, we'd like to highlight the fact that the=20 > > BRPC > > procedure does not mandate for each PCE to use CSPF, could be other > > algorithm. > >=20 > > =3D=3D > > Section 5.1 and throughout > > "BRPC path computation" seems to be tautologous > >=20 > > It is actually a double tautology ;-) (fixed). > >=20 > > =3D=3D > > Section 5.1 > > I like the simplicity of section 5.1, but I think you need to point=20 > > out > > that > > if the sequence of domains is known a priori (can you determine it a > > priori?) then the path computed might not be 'optimal' in the usual=20 > > sense > > of > > the word, but that this is OK because the ordered list of domains > > constitutes an additional constraint on the computation so the=20 > > resultant > > path *is* optimal within the constraints applied. > >=20 > > Can't agree more. Good suggestion, thanks. > >=20 > > Updated text: "The PCE-based BRPC procedure applies to the=20 > > computation of > > an optimal constrained inter-domain TE LSP. The sequence of domains=20 > > to be > > traversed can either be determined a priori or during the path=20 > > computation > > procedure. The BRPC procedure guarantees to compute the optimal path > > across a specific set of traversed domains (which constitutes > > an additional constraint). In the case of an arbitrary set of meshed > > domains, the BRPC procedure can be used to compute the optimal path=20 > > across > > each domain set in order to get to optimal constrained path between=20 > > the > > source and the destination of the TE LSP." > >=20 > > =3D=3D > > Section 5.2 > > The introduction of the term Virtual Shortest Path Tree is hard to=20 > > parse > > and > > to my mind the definition is arse about tit. I think you could=20 > > usefully > > add > > some textual definition of what the VSPT is trying to=20 > achieve, before > > presenting it in pictorial or abstract form. > > Even more important (I think) is the fact that the tree as presented > > "represents the shortest path between the destination and BR-en=20 > > (j,i)..." > > Frankly, we are building directional paths in exactly the oposite > > direction! > >=20 > > This is an abstract form of representation but see below, > >=20 > > So the VSPT is still a tree, but it is an MP2P tree, not a P2MP=20 > > tree as > > described. > > I suspect that this is just a textual descriptive issue rather than > > anything > > broken in the process. > >=20 > >=20 > > I clarified the text to avoid any ambiguity (VSPT defined as a MP2P=20 > > tree). > >=20 > > =3D=3D > > Section 5.2 > > I suggest that you pull the note (Note: in term of=20 > computation...) out > > into > > a separate section. It doesn't belong in the middle of section 5.2. > > You will probably want to re-write the text as well since the > > unidirectional > > limit is not necessary. Also to explain 'flood' - flood to where,=20 > > and how, > > and by whom? And you will want to add to pieces of information: > > - the link to the I-D that defines how to do this > > - a description of what happens if this process is not used. > >=20 > > This only works for unidirectional LSPs: indeed, the exit boundary=20 > > node > > can flood TE-related data in its LSA/LSP for the link > > exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP=20 > > running on > > the link but how would a node in domain (i) get the TE-related data=20 > > for > > the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the=20 > restriction on > > unidirectional link. Are we in sync ? > >=20 > > =3D=3D > > Section 5.2 > > The paragraph that begins "BRPC guarantees to find the optimal..."=20 > > is a > > nascent Applicability Statement. I suggest moving this to another=20 > > Section > > and significantly beefing it up. You need to describe more fully: > > - how ECMP works (the PCC has to request the return of more than=20 > > one path) > > - how diversity works (i.e. section 9 fits in here) > > - how some freedom of selection of domains can be offered > > - how to mix the method with other mechanisms > >=20 > > This was (and is) planned for future revision. Note that ECMP and > > diversity are discussed already but we're planning the=20 > flesh out these > > sections in further revision. > >=20 > > =3D=3D > > Section 7 > > If the BRPC procedure cannot be completed because a PCE along the > > domain path does not support the procedure, a PCErr message is > > returned by the upstream PCE with a Error-Type "BRPC procedure > > completion failure". The PCErr message MUST be relayed to the > > requesting PCC. > > Not clear to me whether PCE(n) is supposed to know that PCE(n+1)=20 > > does not > > support brpc, presumably through capabilities > > configuration/advertisement/negotiation, or whether PCE(n+1) is=20 > > supposed > > to > > respond to the path computation request saying that it does not=20 > > support > > bit-V of the RP object. If the latter, presumably the PCErr=20 > comes from > > PCE(n+1) and not from PCE(n) as documented. > >=20 > > Good catch, typo: it should read "a PCErr message is returned to the > > upstream". > > The plan is to define a capability bit (IGP) in a further revision. > >=20 > > =3D=3D > > Section 8 > > Metric normalisation is a great potential solution, but how does it=20 > > fit > > with > > AS topology confidentiality? What is the solution to providing=20 > > discretion > > about what TE connectivity is available within an AS, and operating=20 > > brpc? > >=20 > > Metric normalization is handled locally by the PCE and does not=20 > > impact the > > BRPC procedure per-say. As far as confidentiality is concerned,=20 > > this only > > requires for the SPs to exchange metric mapping information (nothing > > related to the network topology or resources); for example > > SP 1 Links Cost =3D F (link_bandwidth) with F (OC192)=3D1 > > SP 2 Links Cost =3D F (link_bandwidth) with F (OC192)=3D10 > >=20 > > A simple metric normalization can then be performed on the PCE=20 > > thanks to > > simple cost mapping tables. > >=20 > > Section 10 > > Some of this text has been seen before in this I-D > > Why do you single out LSP stitching as possibly breaking end-to-end > > optimality. There is functionally no difference between=20 > stitching and > > nesting in this respect. > > But further, your statement about stitching is pejorative! If you=20 > > say that > > "In the case where a domain has more than one BR-en or more than one > > BR-ex, > > optimality after some network change within the domain can only be > > guaranteed by re-executing the full brpc computation" then I would=20 > > agree > > with you. But as phrased, it implies that making a per-domain > > re-optimisation could make the path *less* optimal. This (of=20 > > course) is > > not > > the case - per-domain optimisation will always improve or leave the=20 > > same > > end-to-end optimality (in the case where new resources are made=20 > > available > > this is obvious; in the case of a network failure, *any* path is=20 > > better > > than > > no path!) > > And, lastly, the text about re-optimisation belongs in the next=20 > > section, > > not > > in this section. > >=20 > >=20 > > Yes I wanted to leave that text to keep track of who would read the=20 > > ID, > > expecting reaction ;-)) Per-domain reoptimization would always=20 > > improve the > > current path *but* in case of stitched LSPs, TE LSP segments are=20 > > computed > > by the stitching point; thus in case of failure, they could end up > > following a non optimal path whereas in the case of contiguous LSP,=20 > > the > > BRPC procedure would be called again thus leading to the=20 > optimal path > > again. The point that I was trying to make is "if you have a=20 > > stitched LSP > > and rely on BRPC when first signaled in an attempt to get an=20 > > optimal path, > > you need to consider the interaction between the local reopt mode=20 > > and BRPC > > if the goal is to preserve an optimal path at any given=20 > time". Anyway, > > we're on the same page and I agree and the text should be reworded > > according to your proposal to avoid any misunderstanding. > >=20 > > =3D=3D > > Section 13 > > I would like you to discuss the issues of confidentiality=20 > of topology > > information at greater length. It seems that you would possibly use=20 > > this > > technique in conjunction with path cookies, which is fine. But, are=20 > > there > > two things you cannot escape from? > > - indicating which BR-en provides best connectivity > > - indicating the metric for multiple BR-ens > > Maybe there are some things that can be done here based on policy, > > including > > not reporting all of the BR-ens, ranking rather than giving absolute > > metrics, etc. But these would compromise optimality. > >=20 > > Indeed. > >=20 > > Maybe the PCE(n+1) should carefully monitor and limit=20 > > (statistically and > > by > > policy) brpc requests so that excessive information is not divulged? > >=20 > > Since one of objectives for using the BRPC procedure is to=20 > compute an > > optimal path, we need to know at least the BN (Boundary=20 > Nodes) and the > > cost. > >=20 > > =3D=3D > > I wouldn't mind seeing a Management Considerations section. > > Do we need to be able to examine the pruned pieces of VSPT=20 > at transit > > PCEs? > > What are the implications of reporting multiple VSPT branches in=20 > > PCEP to > > the > > MIB modules? > > Is brpc support something that needs to be configured: per PCE?; per > > PCE-neighbor? > > What are the implications on existing protocols (IGPs?=20 > PCEP?) of using > > brpc? > >=20 > > Absolutely ! I put a placeholder for a further revision. > >=20 > > Fully supportive of adding such section. > >=20 > > Many Thanks for your comments ! > >=20 > > JP. > >=20 > > etc. > > =3D=3D > >=20 > >=20 > >=20 > >=20 > >=20 > > I think Jean-Louis' email address needs updating > >=20 > >=20 > > =3D=3D > > The document would benefit from a little care in the formatting,=20 > > and you > > could usefully re-read it for missing words, etc. > > =3D=3D > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 > >=20 > >=20 > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > >=20 >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jun 28 11:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbip-00029W-CB; Wed, 28 Jun 2006 11:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbin-00021l-Kr for pce@ietf.org; Wed, 28 Jun 2006 11:12:53 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbbT-0000gq-Pr for pce@ietf.org; Wed, 28 Jun 2006 11:05:26 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fvbbh-0008Kw-00 for pce@ietf.org; Wed, 28 Jun 2006 16:05:33 +0100 Received: from your029b8cecfe ([194.94.109.154] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 16:05:18 +0100 Message-ID: <098901c69ac4$4281d3f0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Dimitri Papadimitriou" References: Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Wed, 28 Jun 2006 16:05:06 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 28 Jun 2006 15:05:18.0560 (UTC) FILETIME=[44D33E00:01C69AC4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org JL In line Adrian > This is already stated: > > "The domain path (set of domains traversed to reach > the destination domain) is either administratively > pre-determined or discovered by some means > (outside of the scope of this document)". > > There is nothing more to say in this draft IMO. Yes. But this is in section 4. I think that this could valuably be mentioned in the Abstract and in Section 3. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jun 28 15:21:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvfay-0001NZ-Nh; Wed, 28 Jun 2006 15:21:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvfax-0001JN-VI for pce@ietf.org; Wed, 28 Jun 2006 15:21:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvfaw-00019D-OD for pce@ietf.org; Wed, 28 Jun 2006 15:21:03 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Jun 2006 15:21:03 -0400 X-IronPort-AV: i="4.06,189,1149480000"; d="scan'208"; a="91227955:sNHT25729592" 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 k5SJL2YN023124 for ; Wed, 28 Jun 2006 15:21:02 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 15:21:02 -0400 Received: from [161.44.71.253] ([161.44.71.253]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 28 Jun 2006 15:21:01 -0400 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <798646EE-F94C-406D-9E56-B1851D87E9EA@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: pce@ietf.org From: JP Vasseur Date: Wed, 28 Jun 2006 15:21:00 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 28 Jun 2006 19:21:01.0815 (UTC) FILETIME=[FE1E2870:01C69AE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Pce] Slides 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, Presenter, could you send us your slides by July 7th ? Thanks. JP and Adrian. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jun 28 20:49:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvkif-0005uR-NP; Wed, 28 Jun 2006 20:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvkib-0005qw-P5; Wed, 28 Jun 2006 20:49:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvjbq-00072S-MB; Wed, 28 Jun 2006 19:38:14 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvj5u-0001HW-7I; Wed, 28 Jun 2006 19:05:15 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5SMo2jx017061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvirC-0004nm-8a; Wed, 28 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcecp-interarea-reqs-02.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 (G)MPLS Traffic Engineering Author(s) : J. Le Roux Filename : draft-ietf-pce-pcecp-interarea-reqs-02.txt Pages : 10 Date : 2006-6-28 For scalability purposes a network may comprise multiple IGP areas. An inter-area 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 LSR cannot compute alone 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. This document lists a detailed set of PCE Communication Protocol (PCECP) specific requirements for support of inter-area TE-LSP path computation. It complements 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-02.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-02.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-02.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-6-28165435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcecp-interarea-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcecp-interarea-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28165435.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 Thu Jun 29 04:59:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsMa-0001Af-KG; Thu, 29 Jun 2006 04:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsMZ-0001AL-UL for pce@ietf.org; Thu, 29 Jun 2006 04:59:03 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvsMO-0008GP-VD for pce@ietf.org; Thu, 29 Jun 2006 04:59:01 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FvsMV-00022c-00 for pce@ietf.org; Thu, 29 Jun 2006 09:58:59 +0100 Received: from your029b8cecfe ([194.94.109.154] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 09:58:46 +0100 Message-ID: <006201c69b5a$381351f0$9a6d5ec2@your029b8cecfe> From: "Adrian Farrel" To: , Date: Thu, 29 Jun 2006 09:54:59 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 29 Jun 2006 08:58:46.0533 (UTC) FILETIME=[3AF7FB50:01C69B5A] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: Subject: [Pce] Infomral status presented to ITU 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, I am at the Study Group 15, Question 14 interim meeting, and I was asked to present the status of IETF work related to the control plane for optical networks. Below is my text. Note that is was not a formal liaison, but an informal communication. Thanks, Adrian === Introduction In response to several requests, this contribution provides an interim and unofficial status of the activities within the IETF that are pertinent to optical networking. Overview Work continues to progress within the IETF in many working groups that are relevant to the activities of Study Group 15. Of most direct relevance to Question 14/15 are the activities in the Common Control and Measurement Plane (CCAMP) working group, the Path Computation Element (PCE) working group, and the Layer One Virtual Private Network (L1VPN) working group. CCAMP is responsible for the development and maintenance of the GMPLS family of protocols including signaling extensions for RSVP-TE, and routing extensions for OSPF and IS-IS. It also looks after LMP and LMP-WDM. CCAMP is also working on the frameworks and protocol extensions for multi-domain and multi-layer networks. The PCE working group is developing the architecture, requirements, protocols, and applicability for the Path Computation Element - a functional element responsible for determining paths (routes) that may span multiple domains. The L1VPN working group is responsible for the development of GMPLS protocol extensions and applicabilities in support of a service model that involves the supply by a service provider of layer one connectivity between customer sites. Recent Activity Control of TDM Switches a. Revision of RFC 3946 RFC 3946 is titled Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control. This RFC was published in October 2004, is stable, has been implemented by multiple vendors, and is deployed with live traffic. Recent exchanges with the OIF exposed some issues of clarity, and a minor editorial revision (equivalent to an Amendment within the ITU-T) was published as draft-ietf-ccamp-rfc3946-bis-01.txt in December 2005. This draft has now been fully reviewed by the IETF community and has been accepted for publication as an RFC. It is expected that it will be published within the next few months. b. Diversely routed VCAT groups RFC 3946 provides mechanisms for establishing and maintaining LSPs in support of virtual concatenation where the members of a VCG are co-routed; that is, where all group members follow the same path through the network. Recently, hardware vendors have become confident in their technical solutions to support diversely routed VCG members and have asked for protocol solutions to be developed. Members of the CCAMP working group are currently specifying the requirements for this work including the use of LCAS, and it is anticipated that this will soon become official CCAMP work. The development of appropriate protocol solutions has already been discussed and will most likely follow quickly after the requirements work. ASON Signaling a. Requirements Following from the completion of RFC 4139 (Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)) which was the product of successful cooperation and liaison between SG15 and CCAMP, CCAMP has also published RFC 4397 (A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture). RFC 4397 required extensive liaisons, discussion, and face-to-face meetings before both the CCAMP working group and SG15 were satisfied with its contents. This RFC provides the tools necessary to assess the GMPLS signaling protocol RFCs and determine how they may be used to satisfy the requirements set out in RFC 4139. b. Toolkit The CCAMP working group has just completed work on an important item in the protocol toolkit. Although not aimed directly at the ASON environment, draft-ietf-ccamp-gmpls-rsvp-te-call (Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls) has clear applicability to ASON. This work has completed working group last call and will receive a few minor editorial changes before advancing for wider IETF review and publication as an RFC. c. Solutions The CCAMP working group believes that all building blocks are now in place to use GMPLS signaling protocols to satisfy the ASON signaling requirements as expressed in RFC 4139. In particular, this includes the provision of signaling at the UNI, E-NNI, and I-NNI. CCAMP will soon start work on an Applicability Statement to document how the requirements are met, and it is anticipated that this will be liaised to Q14/15 as work in progress. d. Inter-working CCAMP recognizes that an important concern for some people is how they can achieve inter-working of G.7713.x (x = 1, 2, or 3) or OIF UNI reference points on either side of a domain where the I-NNI is achieved using GMPLS signaling protocols. Clearly this needs to be achieved using a standardized approach so that I-NNI nodes will not be disrupted, and so that UNI-N implementations can cooperate. It is also CCAMP's intention to produce an Applicability Statement for this situation, and it is anticipated that this work will be liaised to Q14/15 as work in progress. ASON Routing a. Requirements RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)) is the best evidence we have that the IETF, ITU-T, and OIF communities can work together. This document, finally published in November 2005, concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. It was produced by a joint team of people from (although not representing) there three bodies, and was agreed only after careful liaison with Q14/15. b. Evaluation of Existing Routing Protocols draft-ietf-ccamp-gmpls-ason-routing-eval was also a collaborative effort and, as well as experts from the OIF and SG15, the team included IETF routing protocol experts. The draft which has been reviewed by the IESG and the IETF community, and is ready for publication as an RFC, examines the requirements set out in RFC 4258 and compares them against the capabilities of the IETF routing protocols. Some small lacunae are identified as requiring protocol extensions. c. Solutions Design of the necessary protocol extensions to complete a solution that meets the requirements laid out in RFC 4258 (i.e. to supply the missing pieces identified in draft-ietf-ccamp-gmpls-ason-routing-eval) is well progressed in the IETF. draft-dimitri-ccamp-gmpls-ason-routing-sol-01 published in March proposes protocol solutions, and has just been split into separate work items for OSPF and IS-IS. Discussions are well advanced with the appropriate IGP working groups so that CCAMP will be able to adopt this work soon, and we have received indications that the OIF is looking to the completion of this work in order to determine a final E-NNI routing solution. d. PCE The Path Computation Element (PCE) is receiving attention in Q14/15 through the work on G.7715.2. The PCE working group has made good advances in the determination of an architecture and requirements statements. These have completed work in the working group and have been reviewed by the IESG. While work continues to develop a suitable communications protocol for path queries, the working group is also examining the applicability of PCE to inter-layer scenarios. Some clarification from SG15 of whether such scenarios are within the scope of the ASON model may be beneficial to the work in the PCE working group. Control-Plane / Management-Plane Migration A recent liaison from SG15 to CCAMP highlighted some of the problems with the concept of migrating an existing LSP between the control plane and the management plane. This has proven to be extremely useful to CCAMP members in developing a concise set of requirements for this function within specific and limited environments. There appears to be significant support from carriers for this work, and it is likely to progress within the CCAMP working group first as a requirements statement and then with the addition of simple signaling protocol extensions. Future Cooperation The CCAMP working group co-chairs plan to send a formal liaison to SG15 to communicate about CCAMP progress shortly after the IETF meeting that will be held in Montreal at the start of July. The CCAMP, L1VPN and PCE working groups always welcome questions and contributions from all sources on their mailing lists which have open access to everyone. More substantial contributions are welcomed in the form of Internet-Drafts. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jun 29 08:55:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvw3H-0006bi-5A; Thu, 29 Jun 2006 08:55:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvrsx-0008PE-NM for pce@ietf.org; Thu, 29 Jun 2006 04:28:27 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvrst-0005b4-9J for pce@ietf.org; Thu, 29 Jun 2006 04:28:27 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 10:28:21 +0200 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: Thu, 29 Jun 2006 10:28:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pcc pcedp mib Thread-Index: AcabBoGYpO3XzSu+STOVWZIXRPdRuQATBBWQ From: "STEPHAN Emile RD-CORE-LAN" To: X-OriginalArrivalTime: 29 Jun 2006 08:28:22.0021 (UTC) FILETIME=[FB798B50:01C69B55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Thu, 29 Jun 2006 08:55:22 -0400 Cc: jpv@cisco.com Subject: [Pce] pcc pcedp mib X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, I posted a first stable version of the pcc discovery mib (http://tools.ietf.org/wg/pce/draft-stephan-pce-pcedp-pcc-mib-01.txt ).=20 This memo defines objects for managing PCE Discovery Protocol (PCEDP) inside a PCC. Such a MIB module is part of PCE WG goal. So please go through this ID and raise any issues to the list. That will help to fix them during the meeting. Note: Several objects are missing. The next version will define notifications and objects describing PCEDP activity and errors. Regards Emile _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jun 29 10:10:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxDj-0003yz-El; Thu, 29 Jun 2006 10:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxDi-0003yu-4D for pce@ietf.org; Thu, 29 Jun 2006 10:10:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxDg-0001b8-2n for pce@ietf.org; Thu, 29 Jun 2006 10:10:14 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2006 10:10:12 -0400 X-IronPort-AV: i="4.06,192,1149480000"; d="scan'208"; a="91289669:sNHT38982228" 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 k5TEA1YV005929; Thu, 29 Jun 2006 10:10:11 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 10:10:07 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 10:10:05 -0400 In-Reply-To: <03fd01c69931$60e97e40$0a23fea9@your029b8cecfe> References: <03fd01c69931$60e97e40$0a23fea9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1471D6A2-CD1F-42F7-85FF-6C9782625AE5@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Thu, 29 Jun 2006 10:09:58 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 29 Jun 2006 14:10:05.0815 (UTC) FILETIME=[B8B03870:01C69B85] X-Spam-Score: 0.0 (/) X-Scan-Signature: af7c9eab0f208726cc6b32d194122b96 Cc: Dimitri.Papadimitriou@alcatel.be, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, Let me do this: 1) Reply to several emails individually 2) Send a summary to the list to make sure that all comments have been captured and will be addressed in the next revision. See below, On Jun 26, 2006, at 11:01 AM, Adrian Farrel wrote: > Thanks Dimitri, > > This is converging nicely. > >> ok (nice summary) - i think the whole debate is on point 2) since >> last >> meeting discussions - if one agrees that we don't solve this issue >> - then >> being aware upfront/descriptive of limitations, conditions and >> workability >> is really appropriated - let's assume this is (hopefully) the case > > Then that is an action for the authors to make points 1 and 2 > *very* clear in the I-D (at the top!) No problem to move some statement at the top ;-) Will do. Here is the proposed new abstract: Abstract 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 (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) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. > >> the more important implication is point 3) - if this inter-domain >> link is >> not provided - de facto - as part of the method what does this method >> really provides ? i mean section 7. reads as if you can not flood >> just >> makes PCE aware of that TE data; however, point on whether this >> info is >> flooded or passed to the PCE or not the main issue is how this >> information >> is locally obtained ? what does happen if this information is only >> partially or not known, changing conditions, a unidirectional LSP >> reserves >> bandwidth downstream how accounting occurs (edges need to be aware of >> forward and reverse bandwidth), etc. > > I suspect you do not mean section 7? > > So, if I may rephrase.... > You are concerned about how the brpc process would operate if there > is an inter-domain link (e.g. inter-AS) and the TE information for > this link is not fully known. > > Let's quickly look at who needs to know. > > The downstream PCE provides paths from entry points to its domain > (BR-en(i)) to the destination. So the downstream PCE is not > interested in the TE links entering the domain. > > The upstream PCE provides paths from the entry points to its domain > (BR-en(i-1)) to the destination. It computes these by computing > 'optimal' paths from each BR-en(i-1) to the destination [says the I- > D in step 2]. But this is highly unclear! > > Obviously, PCE(i-1) can compute the paths from each BR-en(i-1) to > each BR-ex(i-1), but in order to build the tree we need the paths > to be computed from each BR-en(i-1) to each BR-en(i). These paths > include the inter-domain TE links (where they exist). This is actually not needed - see below > > So.... > > Either there is an assumption that this TE link information is > available, or there is a step missing in the process. > > Perhaps the authors could clarify here and in the I-D. OK let's clarify then. The text in the draft says: Step i: - For i=n-1 to 2: PCE(i) concatenates the ASi topology (using its TED) with the received VSPT(i+1) and computes VSPT(i). And this is where we could elaborate if you will. What PCE(i) has to do is to concatenate the received VSPT from PCE(i+1) to its ASi topology (by the way, there's a typo there, it should read "domain" rather than "AS") including the inter-AS TE links (in the case of Inter-AS). Once such operation is performed, it is quite easy to compute the new VSPT (MP2P tree) from each BN(j,i) and return it to the upstream PCE. So I propose to rephrase as follows: Step i: - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) (using its TED) with the received VSPT(i+1). In the case of Inter-AS TE LSP computation, this requires to also add the inter-AS TE links connecting the domain (i) to the domain (i+1). Then PCE(i) computes VSPT(i) (P2MP tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination). Does that clarify ? Thanks. JP. > > Thanks, > Adrian > > > > > > >> "Adrian Farrel" >> 26/06/2006 15:14 >> Please respond to "Adrian Farrel" >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >> cc: >> Subject: Re: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> Hi, >> >> I'm trying to parse something out of this thread. >> >> 1. It is clear that brpc *demands* that the sequence of domains >> is already known before brpc is executed. >> In my opinion, this is clear in the I-D, but it would not hurt to >> make it clearer. >> A statement in the Abstract and Introduction would achieve >> this. >> >> 2. The mechanism by which the sequence of domains is known >> is out of scope for the procedure. >> It is not clear whether this is a limitation of the process, or >> not. But in my opinion this is consistent with the guidance >> that the WG received from the IAB when we were chartered. >> We are not trying to 'solve the Internet', so selection of >> domains is out of scope. >> >> 3. brpc *does* include mechanisms for the selection of interdomain >> links and/or nodes. This is more complex than the simple selection >> of these points of attachment because the connection to use may >> depend on the TE paths within the domains. >> IMO, brpc is constructed specifically for this purpose. If we did >> not need this function, we could use pd-path computation with >> visibility of the inter-domain TE links. >> >> 4. The discussion is not helped by debate about the precise wording >> around 'constraint'. >> Let us say that "the sequence of domains to be traversed is >> provided by an external source as a limiting factor to the >> computation >> or choice of paths." >> >> Do we all agree with these statements? >> >> Cheers, >> Adrian >> >> ----- Original Message ----- From: >> To: "JP Vasseur" >> Cc: ; ; >> >> Sent: Monday, June 26, 2006 7:51 AM >> Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >> >> >>> hi j-p - see in-line >>> >>> >>> >>> >>> JP Vasseur >>> 26/06/2006 02:42 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: nabil.n.bitar@verizon.com, pce@ietf.org, >>> raymond_zhang@bt.infonet.com >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> hi dimitri, >>> >>> On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >>> >>> hi j-p - see in-line >>> >>> >>> >>> >>> JP Vasseur >>> 26/06/2006 01:14 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "Adrian Farrel" , >>> nabil.n.bitar@verizon.com, pce@ietf.org, >>> raymond_zhang@bt.infonet.com >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> hi dimitiri, >>> >>> On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >>> >>> the following comment was also discussed during last meeting >>> >>> "== >>> Section 5.1 >>> I like the simplicity of section 5.1, but I think you need to point >>> out >>> that >>> if the sequence of domains is known a priori (can you determine it a >>> priori?) then the path computed might not be 'optimal' in the usual >>> sense >>> of >>> the word, but that this is OK because the ordered list of domains >>> constitutes an additional constraint on the computation so the >>> resultant >>> path *is* optimal within the constraints applied. >>> >>> Can't agree more. Good suggestion, thanks. >>> >>> Updated text: "The PCE-based BRPC procedure applies to the >>> computation of >>> an optimal constrained inter-domain TE LSP. The sequence of domains >>> to be >>> traversed can either be determined a priori or during the path >>> computation >>> procedure. The BRPC procedure guarantees to compute the optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of meshed >>> domains, the BRPC procedure can be used to compute the optimal path >>> across >>> each domain set in order to get to optimal constrained path between >>> the >>> source and the destination of the TE LSP." >>> >>> => in brief, how to determine the sequence through which path >>> computation >>> has to be performed because if this sequence was known there is no >>> need >>> for such procedure (only inter-domain link selection would be >>> required) - >>> >>> Not correct; even if you know the sequence you still need the BRPC >>> procedure to figure out the set of BN (boundary Nodes) to >>> traverse to >>> get the shortest inter-domain TE LSP: this is the whole issue with >>> inter-domain, otherwise per-domain path computation would be >>> sufficient. >>> >>> [dp] inter-domain link selection (as i mentioned) implies what >>> you mean >>> with boundary nodes selection - you could rephrase by access/exit >>> point >>> selection exact same business >>> >>> but again even if you know the sequence you still need BRPC to >>> determine >>> the set of BN (or exit point - same thing) that will give you the >> shortest >>> inter-domain path. Look you wrote "in brief, how to determine the >> sequence >>> through which path computation has to be performed because if this >>> sequence was known there is no need for such procedure", which is >>> not >>> correct. Even if you know the sequence of domains, you still need >>> the >>> procedure to get the exit/entry point (named BN) that provide you >>> the >>> shortest inter-domain path. >>> >>> >>> now adrian mentions that pre- determination becomes a new >>> constraint - >>> well actually this is not a constraint for the TE LSP itself but a >>> restriction on the domain set known to be (a-priori) supportive >>> of the >>> method such as to make the method not returning an error message >>> >>> >>> No, this is a constraint: "Give me the shortest path (potentially >>> made of loose hops (the BNs)) that provides the shortest end to end >>> path, considering that the additional constraint is to traverse the >>> following set of domains . >>> >>> [dp] incorrect, this is not a "TE LSP" constraint - >>> >>> Who said that this was a TE LSP constraint ? This is *a* >>> constraint. If >>> you impose the set of domain, this is a constraint. >>> >>> Please read the text: "The BRPC procedure guarantees to compute the >>> optimal path across a specific set of traversed domains (which >> constitutes >>> an additional constraint)." >>> >>> [dp] i read this, mind you, my point is that this is not a >>> "constraint" >> of >>> the same nature as the one you're making use such as minimize >>> delays or >>> whatsover - this constraint is introduced from the computation >>> technique >>> and mechanism of this proposed method >>> >>> Note that at this point, I still do not see the point that you're >>> trying >>> to make here ? >>> >>> since so far when >>> a set of domains do not support/or support a given computation >>> has not >>> yet become a constraint >>> >>> hence sentence "The BRPC procedure guarantees to compute the >>> optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of meshed >>> domains, the BRPC procedure can be used to compute the optimal path >>> across >>> each domain set in order to get to optimal constrained path between >>> the >>> source and the destination of the TE LSP." >>> >>> should as far as i understand the method fulfill the following >>> >>> a) this method provides a result iff all domains traversed by the >>> request >>> support the proposed method >>> >>> BRPC is a multi-PCE based approach where you need at least one PCE >>> per-domain. >>> >>> [dp] indeed, but one PCE supporting that method and having FULL >>> visibility of the domain >>> >>> So what is your point here ? >>> >>> [dp] that the set of conditions to have this method workable is >>> larger >>> than the one listed in this doc. >>> >>> b) this method provides an "optimal" result iff >>> >>> b1) all possible sequences of domains have been traversed (starting >>> from >>> the root) and are supportive of that method - as there might be an >>> optimal >>> path through a domain not supporting this method - >>> >>> >>> heu ... yes indeed. If a domain does not support the method, the >>> method cannot be used to compute the path. >>> >>> b2) there is no discontinuity in the availability of the inter-AS >>> link >>> information on each PCE performing a given selection - indeed a >>> domain >>> might be supportive of the method without supporting inter-AS link >>> flooding >>> >>> No this is not a requirement, just an optimization. The only >>> requirement is for the PCE to get the TE-related data about the >>> Inter- >>> AS links. I'll detail a bit more in the next revision. >>> >>> [dp] then you can never achieve - >>> >>> You can never achieve what ? >>> >>> Sorry Dimitri, I'd love to accommodate your comment but I do not see >> your >>> point ... hopefully we'll have a bit of time in Montreal to >>> discuss if >>> that does not work by email. >>> >>> [dp] my point is that without this additional information you can >>> not >>> achieve the expected result - i pointed to your own text to indicate >> that >>> this information is a must have in order to achieve this objective >>> >>> using your own words to make it more >>> straighforward - >>> >>> "you still need the BRPC procedure to figure out the set of BN >>> (boundary >>> Nodes) to traverse to get the shortest inter-domain TE LSP: this >>> is the >>> whole issue with inter-domain, otherwise per-domain path computation >>> would >>> >>> be sufficient." >>> >>> b3) at each step there is no PCE that has partial visibility of a >>> given >>> domain >>> >>> >>> This is not specific to BRPC. Even with intra-domain if you want to >>> compute the path for a TE LSP, you cannot always use the PCE if it >>> has a partial visibility. Note that this also applies to the case of >>> co-located PCE (when the path is computed by the head-end). >>> >>> [dp] hence, to BRPC as well >>> >>> b4) during the selection process no network conditions changes >>> (that would >>> make the returned result void) >>> >>> >>> Again, this applies to other cases as well. >>> >>> [dp] ditto >>> >>> >>> Ah so we agree here :-) >>> >>> What was your comment then ? >>> >>> [dp] that you need to include these set of working conditions in the >>> document itself, the document looks like quite simple in terms of >>> conditions for having the proposed method working as expected >>> while when >>> you take a closer look at it this is not the case >>> >>> Thanks. >>> >>> JP. >>> >>> >>> >>> thanks. >>> >>> JP. >>> >>> >>> >>> >>> >>> >>> JP Vasseur >>> 23/06/2006 16:11 >>> >>> To: "Adrian Farrel" >>> cc: raymond_zhang@bt.infonet.com, pce@ietf.org, >>> nabil.n.bitar@verizon.com >>> Subject: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> Many Thanks Adrian for the comments. >>> >>> We incorporated the vast majority of them in the new revision (just >>> posted). >>> >>> See below for the comments requesting some clarification. >>> >>> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >>> >>> Hi, >>> >>> Thanks for keeping these ideas alive. >>> >>> Here are some picky thoughts that you may want to include in the >>> next >>> revision to make it more robust as a document. I don't have any >>> issues >>> with >>> the basic process. >>> >>> Thanks, >>> Adrian >>> >>> == >>> Is this I-D likely to be Informational or Standards Track? From >>> Appendix >>> A, >>> this looks like Standards Track. Can you remove Appendix A and >>> put the >>> status in the usual place in the header? >>> == >>> >>> Status has been updated (Informational) but let's discuss this >>> later on. >>> FYI, it does not appear on the front page when using the xml2rfc >>> editor >>> (which by the way is excellent), thus the appendix addition. >>> >>> It would be nice if the Abstract contained a pithy summary of brpc >>> and/or >>> gave the motivation for the draft. For example, what is the method >>> trying >>> to >>> achieve that isn't achievable by other methods? Or, what is the >>> fundamental >>> element of brpc that is not in other methods? >>> >>> Agree. Here is the new Abstract: >>> "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 (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) has been identified as a key >>> requirement . >>> This document specifies a procedure relying on the use of multiple >>> Path >>> Computation Elements (PCEs) in order to compute such inter-domain >>> shortest >>> constraint paths, using a backward recursive path computation >>> technique >>> while fully preserving confidentiality requirements across >>> domains. " >>> >>> >>> == >>> I'm assuming that section 1 is for short term information only and >>> will be >>> deleted (in the next revision?) >>> == >>> >>> Indeed, just to provide a bit of history for the ones who have been >>> following inter-domain path computation for a while. >>> >>> == >>> Section 4 >>> - No topology or resource information is distributed between >>> domains >>> (as mandated per [RFC4105] and [RFC4216]), which is critical to >>> preserve IGP/BGP scalability and confidentiality in the case of TE >>> LSPs spanning multiple domains. >>> You should clarify what you are saying here, because many would >>> argue that >>> reachability information (i.e. external routes) constitutes >>> topology and >>> resource information. >>> >>> >>> OK fine >>> >>> == >>> Section 4 >>> - While certain constraints like bandwidth can be used across >>> different domains, certain other TE constraints like resource >>> affinity, color, metric, etc. as listed in [RFC2702] could be >>> translated at domain boundaries. If required, it is assumed >>> that, at >>> the domain boundary LSRs, there will exist some sort of local >>> mapping >>> based on offline policy agreement, in order to translate such >>> constraints across domain boundaries during the inter-PCE >>> communication process. >>> Why does the policy agreement need to be offline? >>> >>> >>> It should actually read "pre-determined". Actually the best thing >>> to do >>> here is to remove "off-line" >>> >>> == >>> Section 5 >>> No assumption is made on the actual path computation algorithm in >>> use >>> by the PCE (it can be any variant of CSPF, algorithm based on >>> linear- >>> programming to solve multi-constraints optimization problems and so >>> on). >>> Suggest that you delete the text in parenthesis because it is making >>> suggestions that border on assumptions! >>> >>> Well I'd suggest to keep it as is since the point is to >>> differentiate the >>> path computation procedure from the algorithm to compute each intra- >>> domain >>> path segment. Furthermore, we'd like to highlight the fact that the >>> BRPC >>> procedure does not mandate for each PCE to use CSPF, could be other >>> algorithm. >>> >>> == >>> Section 5.1 and throughout >>> "BRPC path computation" seems to be tautologous >>> >>> It is actually a double tautology ;-) (fixed). >>> >>> == >>> Section 5.1 >>> I like the simplicity of section 5.1, but I think you need to point >>> out >>> that >>> if the sequence of domains is known a priori (can you determine it a >>> priori?) then the path computed might not be 'optimal' in the usual >>> sense >>> of >>> the word, but that this is OK because the ordered list of domains >>> constitutes an additional constraint on the computation so the >>> resultant >>> path *is* optimal within the constraints applied. >>> >>> Can't agree more. Good suggestion, thanks. >>> >>> Updated text: "The PCE-based BRPC procedure applies to the >>> computation of >>> an optimal constrained inter-domain TE LSP. The sequence of domains >>> to be >>> traversed can either be determined a priori or during the path >>> computation >>> procedure. The BRPC procedure guarantees to compute the optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of meshed >>> domains, the BRPC procedure can be used to compute the optimal path >>> across >>> each domain set in order to get to optimal constrained path between >>> the >>> source and the destination of the TE LSP." >>> >>> == >>> Section 5.2 >>> The introduction of the term Virtual Shortest Path Tree is hard to >>> parse >>> and >>> to my mind the definition is arse about tit. I think you could >>> usefully >>> add >>> some textual definition of what the VSPT is trying to achieve, >>> before >>> presenting it in pictorial or abstract form. >>> Even more important (I think) is the fact that the tree as presented >>> "represents the shortest path between the destination and BR-en >>> (j,i)..." >>> Frankly, we are building directional paths in exactly the oposite >>> direction! >>> >>> This is an abstract form of representation but see below, >>> >>> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP >>> tree as >>> described. >>> I suspect that this is just a textual descriptive issue rather than >>> anything >>> broken in the process. >>> >>> >>> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P >>> tree). >>> >>> == >>> Section 5.2 >>> I suggest that you pull the note (Note: in term of >>> computation...) out >>> into >>> a separate section. It doesn't belong in the middle of section 5.2. >>> You will probably want to re-write the text as well since the >>> unidirectional >>> limit is not necessary. Also to explain 'flood' - flood to where, >>> and how, >>> and by whom? And you will want to add to pieces of information: >>> - the link to the I-D that defines how to do this >>> - a description of what happens if this process is not used. >>> >>> This only works for unidirectional LSPs: indeed, the exit boundary >>> node >>> can flood TE-related data in its LSA/LSP for the link >>> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP >>> running on >>> the link but how would a node in domain (i) get the TE-related data >>> for >>> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the >>> restriction on >>> unidirectional link. Are we in sync ? >>> >>> == >>> Section 5.2 >>> The paragraph that begins "BRPC guarantees to find the optimal..." >>> is a >>> nascent Applicability Statement. I suggest moving this to another >>> Section >>> and significantly beefing it up. You need to describe more fully: >>> - how ECMP works (the PCC has to request the return of more than >>> one path) >>> - how diversity works (i.e. section 9 fits in here) >>> - how some freedom of selection of domains can be offered >>> - how to mix the method with other mechanisms >>> >>> This was (and is) planned for future revision. Note that ECMP and >>> diversity are discussed already but we're planning the flesh out >>> these >>> sections in further revision. >>> >>> == >>> Section 7 >>> If the BRPC procedure cannot be completed because a PCE along the >>> domain path does not support the procedure, a PCErr message is >>> returned by the upstream PCE with a Error-Type "BRPC procedure >>> completion failure". The PCErr message MUST be relayed to the >>> requesting PCC. >>> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >>> does not >>> support brpc, presumably through capabilities >>> configuration/advertisement/negotiation, or whether PCE(n+1) is >>> supposed >>> to >>> respond to the path computation request saying that it does not >>> support >>> bit-V of the RP object. If the latter, presumably the PCErr comes >>> from >>> PCE(n+1) and not from PCE(n) as documented. >>> >>> Good catch, typo: it should read "a PCErr message is returned to the >>> upstream". >>> The plan is to define a capability bit (IGP) in a further revision. >>> >>> == >>> Section 8 >>> Metric normalisation is a great potential solution, but how does it >>> fit >>> with >>> AS topology confidentiality? What is the solution to providing >>> discretion >>> about what TE connectivity is available within an AS, and operating >>> brpc? >>> >>> Metric normalization is handled locally by the PCE and does not >>> impact the >>> BRPC procedure per-say. As far as confidentiality is concerned, >>> this only >>> requires for the SPs to exchange metric mapping information (nothing >>> related to the network topology or resources); for example >>> SP 1 Links Cost = F (link_bandwidth) with F (OC192)=1 >>> SP 2 Links Cost = F (link_bandwidth) with F (OC192)=10 >>> >>> A simple metric normalization can then be performed on the PCE >>> thanks to >>> simple cost mapping tables. >>> >>> Section 10 >>> Some of this text has been seen before in this I-D >>> Why do you single out LSP stitching as possibly breaking end-to-end >>> optimality. There is functionally no difference between stitching >>> and >>> nesting in this respect. >>> But further, your statement about stitching is pejorative! If you >>> say that >>> "In the case where a domain has more than one BR-en or more than one >>> BR-ex, >>> optimality after some network change within the domain can only be >>> guaranteed by re-executing the full brpc computation" then I would >>> agree >>> with you. But as phrased, it implies that making a per-domain >>> re-optimisation could make the path *less* optimal. This (of >>> course) is >>> not >>> the case - per-domain optimisation will always improve or leave the >>> same >>> end-to-end optimality (in the case where new resources are made >>> available >>> this is obvious; in the case of a network failure, *any* path is >>> better >>> than >>> no path!) >>> And, lastly, the text about re-optimisation belongs in the next >>> section, >>> not >>> in this section. >>> >>> >>> Yes I wanted to leave that text to keep track of who would read the >>> ID, >>> expecting reaction ;-)) Per-domain reoptimization would always >>> improve the >>> current path *but* in case of stitched LSPs, TE LSP segments are >>> computed >>> by the stitching point; thus in case of failure, they could end up >>> following a non optimal path whereas in the case of contiguous LSP, >>> the >>> BRPC procedure would be called again thus leading to the optimal >>> path >>> again. The point that I was trying to make is "if you have a >>> stitched LSP >>> and rely on BRPC when first signaled in an attempt to get an >>> optimal path, >>> you need to consider the interaction between the local reopt mode >>> and BRPC >>> if the goal is to preserve an optimal path at any given time". >>> Anyway, >>> we're on the same page and I agree and the text should be reworded >>> according to your proposal to avoid any misunderstanding. >>> >>> == >>> Section 13 >>> I would like you to discuss the issues of confidentiality of >>> topology >>> information at greater length. It seems that you would possibly use >>> this >>> technique in conjunction with path cookies, which is fine. But, are >>> there >>> two things you cannot escape from? >>> - indicating which BR-en provides best connectivity >>> - indicating the metric for multiple BR-ens >>> Maybe there are some things that can be done here based on policy, >>> including >>> not reporting all of the BR-ens, ranking rather than giving absolute >>> metrics, etc. But these would compromise optimality. >>> >>> Indeed. >>> >>> Maybe the PCE(n+1) should carefully monitor and limit >>> (statistically and >>> by >>> policy) brpc requests so that excessive information is not divulged? >>> >>> Since one of objectives for using the BRPC procedure is to >>> compute an >>> optimal path, we need to know at least the BN (Boundary Nodes) >>> and the >>> cost. >>> >>> == >>> I wouldn't mind seeing a Management Considerations section. >>> Do we need to be able to examine the pruned pieces of VSPT at >>> transit >>> PCEs? >>> What are the implications of reporting multiple VSPT branches in >>> PCEP to >>> the >>> MIB modules? >>> Is brpc support something that needs to be configured: per PCE?; per >>> PCE-neighbor? >>> What are the implications on existing protocols (IGPs? PCEP?) of >>> using >>> brpc? >>> >>> Absolutely ! I put a placeholder for a further revision. >>> >>> Fully supportive of adding such section. >>> >>> Many Thanks for your comments ! >>> >>> JP. >>> >>> etc. >>> == >>> >>> >>> >>> >>> >>> I think Jean-Louis' email address needs updating >>> >>> >>> == >>> The document would benefit from a little care in the formatting, >>> and you >>> could usefully re-read it for missing words, etc. >>> == >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >> >> >> >> >> >> > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jun 29 10:16:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxJs-0002cw-NR; Thu, 29 Jun 2006 10:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxJq-0002aZ-S7 for pce@ietf.org; Thu, 29 Jun 2006 10:16:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxJq-0001lR-G3 for pce@ietf.org; Thu, 29 Jun 2006 10:16:34 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2006 07:16:34 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="30754655:sNHT26031572" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5TEGXno010439; Thu, 29 Jun 2006 10:16:33 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 10:16:33 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 10:16:32 -0400 In-Reply-To: <041801c69934$357b25d0$0a23fea9@your029b8cecfe> References: <02e001c68cae$d1f154d0$c2849ed9@your029b8cecfe> <81769A42-39BD-499A-9501-BA3EA61F000A@cisco.com> <041801c69934$357b25d0$0a23fea9@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4985B06D-EEAA-4A56-9926-7E3E546BFEF7@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Thu, 29 Jun 2006 10:16:30 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 29 Jun 2006 14:16:32.0917 (UTC) FILETIME=[9F6B4C50:01C69B86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: raymond_zhang@bt.infonet.com, pce@ietf.org, nabil.n.bitar@verizon.com Subject: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Adrian, On Jun 26, 2006, at 11:19 AM, Adrian Farrel wrote: >>> == >>> Is this I-D likely to be Informational or Standards Track? From >>> Appendix A, >>> this looks like Standards Track. Can you remove Appendix A and >>> put the >>> status in the usual place in the header? >>> == >> >> Status has been updated (Informational) but let's discuss this later >> on. FYI, it does not appear on the front page when using the xml2rfc >> editor (which by the way is excellent), thus the appendix addition. > > You could always tell the tools team about this. We discussed it some time ago - will re-activate the discussion. > >>> It would be nice if the Abstract contained a pithy summary of brpc >>> and/or gave the motivation for the draft. For example, what is the >>> method trying to achieve that isn't achievable by other methods? >>> Or, what is the fundamental element of brpc that is not in other >>> methods? >> >> Agree. Here is the new Abstract: >> "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 (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) has been >> identified as a key requirement . This document specifies a procedure >> relying on the use of multiple Path Computation Elements (PCEs) in >> order to compute such inter-domain shortest constraint paths, using a >> backward recursive path computation technique while fully preserving >> confidentiality requirements across domains. " > > Good. > >>> == >>> Section 5 >>> No assumption is made on the actual path computation algorithm in >>> use by the PCE (it can be any variant of CSPF, algorithm based >>> on linear-programming to solve multi-constraints optimization >>> problems and so on). >>> Suggest that you delete the text in parenthesis because it is making >>> suggestions that border on assumptions! >> >> Well I'd suggest to keep it as is since the point is to differentiate >> the path computation procedure from the algorithm to compute each >> intra-domain path segment. Furthermore, we'd like to highlight the >> fact that the BRPC procedure does not mandate for each PCE to use >> CSPF, could be other algorithm. > > Honetsly, I think that everything you want to say is covered by "No > assumption is made on the actual path computation algorithm in use > by the PCE" > > The text in parentheses is overly suggestive, and not as generic as > you might hope. > > If you need/want to convey a more detailed message, I suggest you > do it by explicit text, not by example. Add in place of the > parentheses... > "That is, the path computation procedure is separated from the > computation algorithm and the algorithm need not be limited to > simple CSPF." > Like it, thanks. >>> == >>> Section 5.2 >>> I suggest that you pull the note (Note: in term of computation...) >>> out into a separate section. It doesn't belong in the middle of >>> section 5.2. >>> You will probably want to re-write the text as well since the >>> unidirectional limit is not necessary. Also to explain 'flood' - >>> flood to where, and how, and by whom? And you will want >>> to add to pieces of information: >>> - the link to the I-D that defines how to do this >>> - a description of what happens if this process is not used. >> >> This only works for unidirectional LSPs: indeed, the exit boundary >> node can flood TE-related data in its LSA/LSP for the link exit-BN >> (i,k)->entry-BN(i+1,k') even in the absence of any IGP running on the >> link but how would a node in domain (i) get the TE-related data for >> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the restriction >> on unidirectional link. Are we in sync ? > > Ah. This seems to be Dimitri's point. > > Does that mean that brpc cannot be applied to bidirectional > services where inter-domain links exist? Is that consistent with > the use for GMPLS? We'd need to slightly adjust the procedure. Will add a section on this in a further revision of the document. > >>> === >>> Section 10 >>> Some of this text has been seen before in this I-D >>> Why do you single out LSP stitching as possibly breaking end-to-end >>> optimality. There is functionally no difference between stitching >>> and >>> nesting in this respect. >>> But further, your statement about stitching is pejorative! If you >>> say that >>> "In the case where a domain has more than one BR-en or more than >>> one BR-ex, optimality after some network change within the domain >>> can only be guaranteed by re-executing the full brpc computation" >>> then I would agree with you. But as phrased, it implies that >>> making a per-domain re-optimisation could make the path >>> *less* optimal. This (of course) is not the case - per-domain >>> optimisation will always improve or leave the same >>> end-to-end optimality (in the case where new resources are made >>> available this is obvious; in the case of a network failure, *any* >>> path is better than no path!) >>> And, lastly, the text about re-optimisation belongs in the next >>> section, not in this section. >>> >> >> Yes I wanted to leave that text to keep track of who would read the >> ID, expecting reaction ;-)) Per-domain reoptimization would always >> improve the current path *but* in case of stitched LSPs, TE LSP >> segments are computed by the stitching point; thus in case of >> failure, they could end up following a non optimal path whereas in >> the case of contiguous LSP, the BRPC procedure would be called again >> thus leading to the optimal path again. The point that I was trying >> to make is "if you have a stitched LSP and rely on BRPC when first >> signaled in an attempt to get an optimal path, you need to consider >> the interaction between the local reopt mode and BRPC if the goal is >> to preserve an optimal path at any given time". Anyway, we're on the >> same page and I agree and the text should be reworded according to >> your proposal to avoid any misunderstanding. > > OK. Yes, some wordsmitthing is needed to explain local optimisation > (for stitching *and* tunneling) compared to end-to-end optimisation. OK, thanks for the comments. Cheers, JP. > > Cheers, > Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jun 29 14:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1Gf-0003co-1n; Thu, 29 Jun 2006 14:29:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxDx-0004O6-9W for pce@ietf.org; Thu, 29 Jun 2006 10:10:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxDp-0001bW-Ba for pce@ietf.org; Thu, 29 Jun 2006 10:10:29 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Jun 2006 10:10:22 -0400 X-IronPort-AV: i="4.06,192,1149480000"; d="scan'208,217"; a="91289705:sNHT141828186" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5TEAKno008650; Thu, 29 Jun 2006 10:10:20 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 10:10:20 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 10:10:13 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Message-Id: <302BEF18-F68F-4319-AB88-90E4B964553A@cisco.com> From: JP Vasseur Subject: Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt Date: Thu, 29 Jun 2006 10:10:12 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN , dimitri.papadimitriou@alcatel.be X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 29 Jun 2006 14:10:13.0643 (UTC) FILETIME=[BD5AADB0:01C69B85] X-Spam-Score: 0.5 (/) X-Scan-Signature: ebc71450a8ee35dd8eda7e4943773019 X-Mailman-Approved-At: Thu, 29 Jun 2006 14:29:31 -0400 Cc: Dimitri.Papadimitriou@alcatel.be, nabil.n.bitar@verizon.com, pce@ietf.org, raymond_zhang@bt.infonet.com X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2132495521==" Errors-To: pce-bounces@lists.ietf.org --===============2132495521== Content-Type: multipart/alternative; boundary=Apple-Mail-28--663163050 --Apple-Mail-28--663163050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi, Looks like we're converging, good. Cosmetic comments in line, On Jun 28, 2006, at 9:18 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Dimitri, > > See inline, > >> -----Message d'origine----- >> De : Dimitri.Papadimitriou@alcatel.be >> [mailto:Dimitri.Papadimitriou@alcatel.be] >> Envoy=E9 : lundi 26 juin 2006 17:09 >> =C0 : LE ROUX Jean-Louis RD-CORE-LAN >> Cc : JP Vasseur; nabil.n.bitar@verizon.com; pce@ietf.org; >> raymond_zhang@bt.infonet.com >> Objet : RE: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >> >> hi j-l - thanks for these clarifications - see in-line for a >> couple of remarks >> >> >> >> >> "LE ROUX Jean-Louis RD-CORE-LAN" >> 26/06/2006 16:37 >> >> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP >> Vasseur" >> >> cc: , >> , >> Subject: RE: [Pce] Re: Comments on >> draft-vasseur-pce-brpc-00.txt >> >> >> Hi Dimitri, >> >> Please see inline, >> >>> -----Message d'origine----- >>> De : Dimitri.Papadimitriou@alcatel.be >>> [mailto:Dimitri.Papadimitriou@alcatel.be] >>> Envoy=E9 : lundi 26 juin 2006 15:43 >>> =C0 : JP Vasseur >>> Cc : raymond_zhang@bt.infonet.com; nabil.n.bitar@verizon.com; >>> pce@ietf.org >>> Objet : Re: [Pce] Re: Comments on draft-vasseur-pce-brpc-00.txt >>> >>> hi >>> >>> i don't think 1) and 2) have been captured >>> >>> on 1) there is a terminology issue - indeed - but there is >>> also an issue that is the arbitrary selection/pruning of >>> other potential alternatives - why that sequence ? and not >>> another - was mentioned as the chicken-egg >>> (technical) problem; first there may be many available >>> interdomain paths that are never learned by the LSRs, >>> more >>> generically the diversity of the BGP routes available at each >>> LSR is not sufficient to successfully provide for a >>> satisfactory sequence; on the other hand, you may have >>> receive multiple let's take an example to illustrate there >>> are two AS path between A and D, one A-B-C-D the other >>> A-E-F-D disjoint (on intermediate ASs) either both sequences >>> are valid both policing and filtering makes you selecting the >>> inappropriate sequence for the real TE-LSP consrttaints >> >> In the inter-AS case, inter-AS selection is likely to be driven by >> business considerations and will be the result of (static or dynamic) >> inter-SP service negociation and execution. Note that, as recalled by >> Adrian, the objective is NOT to setup TE-LSPs over the Internet... >> Also in your example, one may simply run two BRPC with the >> two AS-Path and >> select the best result... >> >> [dp] in the inter AS case, which is the most challenging, are >> you telling >> me that the whole policing and filtering is done but based on >> information >> elements that require further negotiation phases - such that your >> selection is not susceptible to lead you to a case where the AS_path >> doesn't provide you any further information but your initial >> negotiation >> makes it such that the probability of making the wrong selection is >> minimized - taking the example i gave here above: two AS path >> between A >> and D, one A-B-C-D the other >> A-E-F-D disjoint (on intermediate ASs) and both sequences are >> valid - but >> now policing and filtering makes you selecting the >> appropriate sequence >> for the real TE-LSP consrttaints ? > > Yes, this is what I meant > >> if this is the case some further >> inlightment may be really helpful - > > This is already stated: > > "The domain path (set of domains traversed to reach the =20 > destination domain) is either administratively pre-determined or =20 > discovered by some means (outside of the scope of this document)". > > There is nothing more to say in this draft IMO. > >> >> In the inter-area case, areas selection is straightforward. >> >>> on 2) this is part of the answer - the comment was PCE per >>> domain supporting that method - and in case of two PCEs or >>> more per domain i am not sure how one could guarantee that >>> the proposed (recursive) sequence works (assumption is made >>> that the PCE as full visibility on the whole domain but what >>> in case of multiple PCEs per domain) >> >> If these PCEs have the same visibility then there is NO issue. >> If these PCEs don't have the same visibility, then actually you have >> multiple sub-domains within the domain (or multiple domains >> within a super >> domain!), the pratical case being inter-AS path computation >> where each AS >> is made of several areas. >> Is that your concern? >> >> [dp] my concern is that segmentation of PCE roles is not necessarily >> mapping domain boundaries (intra-AS) > > Please note that in PCE terminology a "domain" is a generic term, =20 > this is a set of elements with a common sphere of path computation =20 > responsiblity (this is not limited to IGP areas, ASes). Hence the =20 > set of elements under PCE visibility is by definition a "domain", =20 > and segmentation of PCE roles IS mapping "domain" boudaries. > The procedures defined in this doc apply to multiple "domains", =20 > with this generic definition of "domains". Right, as stated in the ID: - Each AS can be made of several IGP areas. The path computation procedure described in this document applies to the case of a single AS made of multiple IGP areas, multiples ASs made of a single IGP area or any combination of the above. For the sake of simplicity, each AS will be considered to be comprised of a single area in this document. The case of an Inter-AS TE LSP spanning multiple ASs =20 where some of those ASs are themselves made of multiple IGP areas can be easily derived from this case by applying the BRPC procedure described in this document, recursively. > > >> and the other case is when for >> instance could have as example that for a given "AS" a PCE >> taking care of >> TDM links and another ETH links hence you would have a >> bifurcation - i > > Then you have at least two "domains" (one for TDM and one for ETH), =20= > and the procedures apply as is. > > More generally when you have a hierachy of domains (e.g. AS =20 > domains, on top of area domains on top of techno domains) you need =20 > to run the BRPC procedure at each level. > When you run the BRCP procedure at level N you need to compute =20 > level N path segments, and this requires calling BRPC at level N-1, =20= > this is recursive. > > Best Regards Thanks. JP. > > JL > >> mean you get a sequence of AS from routing but for each AS >> there may be a >> set of PCE which not structured such as to map the routing >> topology - i >> can rephrase as for a sequence of AS there can be multiple >> sequences of >> PCEs if these have not complete view you need to deal with >> intermediate >> recombination of information on the return path or make a >> selection of >> PCEs on the forward path - the doc. currently says "If >> multiple PCEs are >> discovered, the PCE may select a subset of these PCEs based >> on some local >> policies/heuristics." what in case it doesn't ? >> >> In this situation, the inter-AS BRPC procedure triggers a set of >> inter-area BRPC procedures in each AS to compute intra-AS (ie >> inter-area) >> path segments in each AS. >> >> Regards, >> >> JL >> >> >> >> Regards >> >> JL >> >> >>> >>> i have also asked to have a better description of the working >>> conditions along this draft - to complete section 5.1 - >>> >>> if you consider this as non-technical or technical feedback >>> that's your own appreciation >>> >>> thanks, >>> - dimitri. >>> >>> >>> >>> >>> >>> >>> JP Vasseur >>> 26/06/2006 14:54 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: nabil.n.bitar@verizon.com, pce@ietf.org, >>> raymond_zhang@bt.infonet.com >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> hi, >>> >>> ok so to summarize there was no technical feed-back just a >>> few editorial comments. >>> >>> You'd like to add to the following to the document: >>> 1) The set of traversed domains has to be known and according >>> to you this is not a constraint. >>> I think that the current text is quite clear: >>> "The BRPC procedure guarantees to compute the optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint)." >>> Now if you want to reword a bit to avoid using the word >> "constraint" >>> although this *is* a constraint, this is no big deal. >>> >>> Actually, interestingly enough there are quite a few cases >>> where there's only one single set of traversed domains. >>> >>> 2) We need at least one PCE per domain >>> Sounds quite obvious but I have no problem adding this. >>> Actually we're planning in the next revision to elaborate a >>> little bit on the inter-As link flooding (again this is not a >>> requirement but an optimization) but this will be covered. >>> >>> JP. >>> >>> On Jun 26, 2006, at 2:51 AM, Dimitri.Papadimitriou@alcatel.be wrote: >>> >>> hi j-p - see in-line >>> >>> >>> >>> >>> JP Vasseur >>> 26/06/2006 02:42 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: nabil.n.bitar@verizon.com, pce@ietf.org, >>> raymond_zhang@bt.infonet.com >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> hi dimitri, >>> >>> On Jun 25, 2006, at 7:35 PM, Dimitri.Papadimitriou@alcatel.be wrote: >>> >>> hi j-p - see in-line >>> >>> >>> >>> >>> JP Vasseur >>> 26/06/2006 01:14 >>> >>> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL >>> cc: "Adrian Farrel" , >>> nabil.n.bitar@verizon.com, pce@ietf.org, >> raymond_zhang@bt.infonet.com >>> Subject: Re: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> hi dimitiri, >>> >>> On Jun 25, 2006, at 2:08 PM, Dimitri.Papadimitriou@alcatel.be wrote: >>> >>> the following comment was also discussed during last meeting >>> >>> "=3D=3D >>> Section 5.1 >>> I like the simplicity of section 5.1, but I think you need to >>> point out that if the sequence of domains is known a priori >>> (can you determine it a >>> priori?) then the path computed might not be 'optimal' in the >>> usual sense of the word, but that this is OK because the >>> ordered list of domains constitutes an additional constraint >>> on the computation so the resultant path *is* optimal within >>> the constraints applied. >>> >>> Can't agree more. Good suggestion, thanks. >>> >>> Updated text: "The PCE-based BRPC procedure applies to the >>> computation of an optimal constrained inter-domain TE LSP. >>> The sequence of domains to be traversed can either be >>> determined a priori or during the path computation procedure. >>> The BRPC procedure guarantees to compute the optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of >>> meshed domains, the BRPC procedure can be used to compute the >>> optimal path across each domain set in order to get to >>> optimal constrained path between the source and the >>> destination of the TE LSP." >>> >>> =3D> in brief, how to determine the sequence through which path >>> computation has to be performed because if this sequence was >>> known there is no need for such procedure (only inter-domain >>> link selection would be >>> required) - >>> >>> Not correct; even if you know the sequence you still need the >>> BRPC procedure to figure out the set of BN (boundary Nodes) >>> to traverse to get the shortest inter-domain TE LSP: this is >>> the whole issue with inter-domain, otherwise per-domain path >>> computation would be sufficient. >>> >>> [dp] inter-domain link selection (as i mentioned) implies >>> what you mean with boundary nodes selection - you could >>> rephrase by access/exit point selection exact same business >>> >>> but again even if you know the sequence you still need BRPC >>> to determine the set of BN (or exit point - same thing) that >>> will give you the shortest inter-domain path. Look you wrote >>> "in brief, how to determine the sequence through which path >>> computation has to be performed because if this sequence was >>> known there is no need for such procedure", which is not >>> correct. Even if you know the sequence of domains, you still >>> need the procedure to get the exit/entry point (named BN) >>> that provide you the shortest inter-domain path. >>> >>> >>> now adrian mentions that pre- determination becomes a new >>> constraint - well actually this is not a constraint for the >>> TE LSP itself but a restriction on the domain set known to be >>> (a-priori) supportive of the method such as to make the >>> method not returning an error message >>> >>> >>> No, this is a constraint: "Give me the shortest path >>> (potentially made of loose hops (the BNs)) that provides the >>> shortest end to end path, considering that the additional >>> constraint is to traverse the following set of domains > D2, ....>. >>> >>> [dp] incorrect, this is not a "TE LSP" constraint - >>> >>> Who said that this was a TE LSP constraint ? This is *a* >>> constraint. If you impose the set of domain, this is a constraint. >>> >>> Please read the text: "The BRPC procedure guarantees to >>> compute the optimal path across a specific set of traversed >>> domains (which constitutes an additional constraint)." >>> >>> [dp] i read this, mind you, my point is that this is not a >>> "constraint" >>> of >>> the same nature as the one you're making use such as minimize >>> delays or whatsover - this constraint is introduced from the >>> computation technique and mechanism of this proposed method >>> >>> Note that at this point, I still do not see the point that >>> you're trying to make here ? >>> >>> since so far when >>> a set of domains do not support/or support a given >>> computation has not yet become a constraint >>> >>> hence sentence "The BRPC procedure guarantees to compute the >>> optimal path across a specific set of traversed domains >>> (which constitutes an additional constraint). In the case of >>> an arbitrary set of meshed domains, the BRPC procedure can be >>> used to compute the optimal path across each domain set in >>> order to get to optimal constrained path between the source >>> and the destination of the TE LSP." >>> >>> should as far as i understand the method fulfill the following >>> >>> a) this method provides a result iff all domains traversed by >>> the request support the proposed method >>> >>> BRPC is a multi-PCE based approach where you need at least >>> one PCE per-domain. >>> >>> [dp] indeed, but one PCE supporting that method and having >>> FULL visibility of the domain >>> >>> So what is your point here ? >>> >>> [dp] that the set of conditions to have this method workable >>> is larger than the one listed in this doc. >>> >>> b) this method provides an "optimal" result iff >>> >>> b1) all possible sequences of domains have been traversed >>> (starting from the root) and are supportive of that method - >>> as there might be an optimal path through a domain not >>> supporting this method - >>> >>> >>> heu ... yes indeed. If a domain does not support the method, >>> the method cannot be used to compute the path. >>> >>> b2) there is no discontinuity in the availability of the >>> inter-AS link information on each PCE performing a given >>> selection - indeed a domain might be supportive of the method >>> without supporting inter-AS link flooding >>> >>> No this is not a requirement, just an optimization. The only >>> requirement is for the PCE to get the TE-related data about >>> the Inter- AS links. I'll detail a bit more in the next revision. >>> >>> [dp] then you can never achieve - >>> >>> You can never achieve what ? >>> >>> Sorry Dimitri, I'd love to accommodate your comment but I do >>> not see your point ... hopefully we'll have a bit of time in >>> Montreal to discuss if that does not work by email. >>> >>> [dp] my point is that without this additional information you >>> can not achieve the expected result - i pointed to your own >>> text to indicate that this information is a must have in >>> order to achieve this objective >>> >>> using your own words to make it more >>> straighforward - >>> >>> "you still need the BRPC procedure to figure out the set of >>> BN (boundary >>> Nodes) to traverse to get the shortest inter-domain TE LSP: >>> this is the whole issue with inter-domain, otherwise >>> per-domain path computation would >>> >>> be sufficient." >>> >>> b3) at each step there is no PCE that has partial visibility >>> of a given domain >>> >>> >>> This is not specific to BRPC. Even with intra-domain if you want to >>> compute the path for a TE LSP, you cannot always use the PCE if it >>> has a partial visibility. Note that this also applies to >> the case of >>> co-located PCE (when the path is computed by the head-end). >>> >>> [dp] hence, to BRPC as well >>> >>> b4) during the selection process no network conditions changes >>> (that would >>> make the returned result void) >>> >>> >>> Again, this applies to other cases as well. >>> >>> [dp] ditto >>> >>> >>> Ah so we agree here :-) >>> >>> What was your comment then ? >>> >>> [dp] that you need to include these set of working >> conditions in the >>> document itself, the document looks like quite simple in terms of >>> conditions for having the proposed method working as expected >>> while when >>> you take a closer look at it this is not the case >>> >>> Thanks. >>> >>> JP. >>> >>> >>> >>> thanks. >>> >>> JP. >>> >>> >>> >>> >>> >>> >>> JP Vasseur >>> 23/06/2006 16:11 >>> >>> To: "Adrian Farrel" >>> cc: raymond_zhang@bt.infonet.com, pce@ietf.org, >>> nabil.n.bitar@verizon.com >>> Subject: [Pce] Re: Comments on >>> draft-vasseur-pce-brpc-00.txt >>> >>> >>> Many Thanks Adrian for the comments. >>> >>> We incorporated the vast majority of them in the new revision (just >>> posted). >>> >>> See below for the comments requesting some clarification. >>> >>> On Jun 10, 2006, at 8:49 AM, Adrian Farrel wrote: >>> >>> Hi, >>> >>> Thanks for keeping these ideas alive. >>> >>> Here are some picky thoughts that you may want to include >> in the next >>> revision to make it more robust as a document. I don't have >> any issues >>> with >>> the basic process. >>> >>> Thanks, >>> Adrian >>> >>> =3D=3D >>> Is this I-D likely to be Informational or Standards Track? From >>> Appendix >>> A, >>> this looks like Standards Track. Can you remove Appendix A >> and put the >>> status in the usual place in the header? >>> =3D=3D >>> >>> Status has been updated (Informational) but let's discuss this >>> later on. >>> FYI, it does not appear on the front page when using the xml2rfc >>> editor >>> (which by the way is excellent), thus the appendix addition. >>> >>> It would be nice if the Abstract contained a pithy summary of brpc >>> and/or >>> gave the motivation for the draft. For example, what is the method >>> trying >>> to >>> achieve that isn't achievable by other methods? Or, what is the >>> fundamental >>> element of brpc that is not in other methods? >>> >>> Agree. Here is the new Abstract: >>> "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 (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) has been identified as a key >>> requirement . >>> This document specifies a procedure relying on the use of multiple >>> Path >>> Computation Elements (PCEs) in order to compute such inter-domain >>> shortest >>> constraint paths, using a backward recursive path computation >>> technique >>> while fully preserving confidentiality requirements across >> domains. " >>> >>> >>> =3D=3D >>> I'm assuming that section 1 is for short term information only and >>> will be >>> deleted (in the next revision?) >>> =3D=3D >>> >>> Indeed, just to provide a bit of history for the ones who have been >>> following inter-domain path computation for a while. >>> >>> =3D=3D >>> Section 4 >>> - No topology or resource information is distributed >> between domains >>> (as mandated per [RFC4105] and [RFC4216]), which is critical to >>> preserve IGP/BGP scalability and confidentiality in the case of TE >>> LSPs spanning multiple domains. >>> You should clarify what you are saying here, because many would >>> argue that >>> reachability information (i.e. external routes) constitutes >>> topology and >>> resource information. >>> >>> >>> OK fine >>> >>> =3D=3D >>> Section 4 >>> - While certain constraints like bandwidth can be used across >>> different domains, certain other TE constraints like resource >>> affinity, color, metric, etc. as listed in [RFC2702] could be >>> translated at domain boundaries. If required, it is assumed >>> that, at >>> the domain boundary LSRs, there will exist some sort of local >>> mapping >>> based on offline policy agreement, in order to translate such >>> constraints across domain boundaries during the inter-PCE >>> communication process. >>> Why does the policy agreement need to be offline? >>> >>> >>> It should actually read "pre-determined". Actually the best thing >>> to do >>> here is to remove "off-line" >>> >>> =3D=3D >>> Section 5 >>> No assumption is made on the actual path computation algorithm in >>> use >>> by the PCE (it can be any variant of CSPF, algorithm based on >>> linear- >>> programming to solve multi-constraints optimization >> problems and so >>> on). >>> Suggest that you delete the text in parenthesis because it is making >>> suggestions that border on assumptions! >>> >>> Well I'd suggest to keep it as is since the point is to >>> differentiate the >>> path computation procedure from the algorithm to compute >> each intra- >>> domain >>> path segment. Furthermore, we'd like to highlight the fact that the >>> BRPC >>> procedure does not mandate for each PCE to use CSPF, could be other >>> algorithm. >>> >>> =3D=3D >>> Section 5.1 and throughout >>> "BRPC path computation" seems to be tautologous >>> >>> It is actually a double tautology ;-) (fixed). >>> >>> =3D=3D >>> Section 5.1 >>> I like the simplicity of section 5.1, but I think you need to point >>> out >>> that >>> if the sequence of domains is known a priori (can you determine it a >>> priori?) then the path computed might not be 'optimal' in the usual >>> sense >>> of >>> the word, but that this is OK because the ordered list of domains >>> constitutes an additional constraint on the computation so the >>> resultant >>> path *is* optimal within the constraints applied. >>> >>> Can't agree more. Good suggestion, thanks. >>> >>> Updated text: "The PCE-based BRPC procedure applies to the >>> computation of >>> an optimal constrained inter-domain TE LSP. The sequence of domains >>> to be >>> traversed can either be determined a priori or during the path >>> computation >>> procedure. The BRPC procedure guarantees to compute the optimal path >>> across a specific set of traversed domains (which constitutes >>> an additional constraint). In the case of an arbitrary set of meshed >>> domains, the BRPC procedure can be used to compute the optimal path >>> across >>> each domain set in order to get to optimal constrained path between >>> the >>> source and the destination of the TE LSP." >>> >>> =3D=3D >>> Section 5.2 >>> The introduction of the term Virtual Shortest Path Tree is hard to >>> parse >>> and >>> to my mind the definition is arse about tit. I think you could >>> usefully >>> add >>> some textual definition of what the VSPT is trying to >> achieve, before >>> presenting it in pictorial or abstract form. >>> Even more important (I think) is the fact that the tree as presented >>> "represents the shortest path between the destination and BR-en >>> (j,i)..." >>> Frankly, we are building directional paths in exactly the oposite >>> direction! >>> >>> This is an abstract form of representation but see below, >>> >>> So the VSPT is still a tree, but it is an MP2P tree, not a P2MP >>> tree as >>> described. >>> I suspect that this is just a textual descriptive issue rather than >>> anything >>> broken in the process. >>> >>> >>> I clarified the text to avoid any ambiguity (VSPT defined as a MP2P >>> tree). >>> >>> =3D=3D >>> Section 5.2 >>> I suggest that you pull the note (Note: in term of >> computation...) out >>> into >>> a separate section. It doesn't belong in the middle of section 5.2. >>> You will probably want to re-write the text as well since the >>> unidirectional >>> limit is not necessary. Also to explain 'flood' - flood to where, >>> and how, >>> and by whom? And you will want to add to pieces of information: >>> - the link to the I-D that defines how to do this >>> - a description of what happens if this process is not used. >>> >>> This only works for unidirectional LSPs: indeed, the exit boundary >>> node >>> can flood TE-related data in its LSA/LSP for the link >>> exit-BN(i,k)->entry-BN(i+1,k') even in the absence of any IGP >>> running on >>> the link but how would a node in domain (i) get the TE-related data >>> for >>> the link entry(i+1,k')->exit-BN(i,k) ? I can't thus the >> restriction on >>> unidirectional link. Are we in sync ? >>> >>> =3D=3D >>> Section 5.2 >>> The paragraph that begins "BRPC guarantees to find the optimal..." >>> is a >>> nascent Applicability Statement. I suggest moving this to another >>> Section >>> and significantly beefing it up. You need to describe more fully: >>> - how ECMP works (the PCC has to request the return of more than >>> one path) >>> - how diversity works (i.e. section 9 fits in here) >>> - how some freedom of selection of domains can be offered >>> - how to mix the method with other mechanisms >>> >>> This was (and is) planned for future revision. Note that ECMP and >>> diversity are discussed already but we're planning the >> flesh out these >>> sections in further revision. >>> >>> =3D=3D >>> Section 7 >>> If the BRPC procedure cannot be completed because a PCE along the >>> domain path does not support the procedure, a PCErr message is >>> returned by the upstream PCE with a Error-Type "BRPC procedure >>> completion failure". The PCErr message MUST be relayed to the >>> requesting PCC. >>> Not clear to me whether PCE(n) is supposed to know that PCE(n+1) >>> does not >>> support brpc, presumably through capabilities >>> configuration/advertisement/negotiation, or whether PCE(n+1) is >>> supposed >>> to >>> respond to the path computation request saying that it does not >>> support >>> bit-V of the RP object. If the latter, presumably the PCErr >> comes from >>> PCE(n+1) and not from PCE(n) as documented. >>> >>> Good catch, typo: it should read "a PCErr message is returned to the >>> upstream". >>> The plan is to define a capability bit (IGP) in a further revision. >>> >>> =3D=3D >>> Section 8 >>> Metric normalisation is a great potential solution, but how does it >>> fit >>> with >>> AS topology confidentiality? What is the solution to providing >>> discretion >>> about what TE connectivity is available within an AS, and operating >>> brpc? >>> >>> Metric normalization is handled locally by the PCE and does not >>> impact the >>> BRPC procedure per-say. As far as confidentiality is concerned, >>> this only >>> requires for the SPs to exchange metric mapping information (nothing >>> related to the network topology or resources); for example >>> SP 1 Links Cost =3D F (link_bandwidth) with F (OC192)=3D1 >>> SP 2 Links Cost =3D F (link_bandwidth) with F (OC192)=3D10 >>> >>> A simple metric normalization can then be performed on the PCE >>> thanks to >>> simple cost mapping tables. >>> >>> Section 10 >>> Some of this text has been seen before in this I-D >>> Why do you single out LSP stitching as possibly breaking end-to-end >>> optimality. There is functionally no difference between >> stitching and >>> nesting in this respect. >>> But further, your statement about stitching is pejorative! If you >>> say that >>> "In the case where a domain has more than one BR-en or more than one >>> BR-ex, >>> optimality after some network change within the domain can only be >>> guaranteed by re-executing the full brpc computation" then I would >>> agree >>> with you. But as phrased, it implies that making a per-domain >>> re-optimisation could make the path *less* optimal. This (of >>> course) is >>> not >>> the case - per-domain optimisation will always improve or leave the >>> same >>> end-to-end optimality (in the case where new resources are made >>> available >>> this is obvious; in the case of a network failure, *any* path is >>> better >>> than >>> no path!) >>> And, lastly, the text about re-optimisation belongs in the next >>> section, >>> not >>> in this section. >>> >>> >>> Yes I wanted to leave that text to keep track of who would read the >>> ID, >>> expecting reaction ;-)) Per-domain reoptimization would always >>> improve the >>> current path *but* in case of stitched LSPs, TE LSP segments are >>> computed >>> by the stitching point; thus in case of failure, they could end up >>> following a non optimal path whereas in the case of contiguous LSP, >>> the >>> BRPC procedure would be called again thus leading to the >> optimal path >>> again. The point that I was trying to make is "if you have a >>> stitched LSP >>> and rely on BRPC when first signaled in an attempt to get an >>> optimal path, >>> you need to consider the interaction between the local reopt mode >>> and BRPC >>> if the goal is to preserve an optimal path at any given >> time". Anyway, >>> we're on the same page and I agree and the text should be reworded >>> according to your proposal to avoid any misunderstanding. >>> >>> =3D=3D >>> Section 13 >>> I would like you to discuss the issues of confidentiality >> of topology >>> information at greater length. It seems that you would possibly use >>> this >>> technique in conjunction with path cookies, which is fine. But, are >>> there >>> two things you cannot escape from? >>> - indicating which BR-en provides best connectivity >>> - indicating the metric for multiple BR-ens >>> Maybe there are some things that can be done here based on policy, >>> including >>> not reporting all of the BR-ens, ranking rather than giving absolute >>> metrics, etc. But these would compromise optimality. >>> >>> Indeed. >>> >>> Maybe the PCE(n+1) should carefully monitor and limit >>> (statistically and >>> by >>> policy) brpc requests so that excessive information is not divulged? >>> >>> Since one of objectives for using the BRPC procedure is to >> compute an >>> optimal path, we need to know at least the BN (Boundary >> Nodes) and the >>> cost. >>> >>> =3D=3D >>> I wouldn't mind seeing a Management Considerations section. >>> Do we need to be able to examine the pruned pieces of VSPT >> at transit >>> PCEs? >>> What are the implications of reporting multiple VSPT branches in >>> PCEP to >>> the >>> MIB modules? >>> Is brpc support something that needs to be configured: per PCE?; per >>> PCE-neighbor? >>> What are the implications on existing protocols (IGPs? >> PCEP?) of using >>> brpc? >>> >>> Absolutely ! I put a placeholder for a further revision. >>> >>> Fully supportive of adding such section. >>> >>> Many Thanks for your comments ! >>> >>> JP. >>> >>> etc. >>> =3D=3D >>> >>> >>> >>> >>> >>> I think Jean-Louis' email address needs updating >>> >>> >>> =3D=3D >>> The document would benefit from a little care in the formatting, >>> and you >>> could usefully re-read it for missing words, etc. >>> =3D=3D >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list >>> Pce@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/pce >>> >> >> >> --Apple-Mail-28--663163050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

Looks like we're = converging, good. Cosmetic comments in line,

On Jun = 28, 2006, at 9:18 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote:

Hi Dimitri,

See inline,=A0

-----Message d'origine-----
Envoy=E9 = : lundi 26 juin 2006 17:09
=C0 : LE ROUX = Jean-Louis RD-CORE-LAN
Cc : JP Vasseur; nabil.n.bitar@verizon.com; = pce@ietf.org;=A0





26/06/2006 16:37

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP=A0
=A0
=A0 =A0 =A0 =A0 = cc: =A0 =A0 <raymond_zhang@bt.infonet.com<= /A>>,=A0
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = RE: [Pce] Re: Comments on=A0


Hi Dimitri,

Please see inline,=A0

-----Message d'origine-----
Envoy=E9 = : lundi 26 juin 2006 15:43
=C0 : JP = Vasseur
Objet : Re: [Pce] Re: Comments on = draft-vasseur-pce-brpc-00.txt

hi=A0

i don't think = 1) and 2) have been captured=A0

on 1) there = is a terminology issue - indeed - but there is=A0
also an = issue that is the arbitrary selection/pruning of=A0
other = potential alternatives - why that sequence ? and not=A0
another = - was mentioned as the chicken-egg
(technical) = problem; first there may be many available=A0
=A0
=A0
generically the diversity of the BGP routes = available at each=A0
LSR is not sufficient to successfully provide for = a=A0
satisfactory sequence; on the other hand, you may = have=A0
receive multiple let's take an example to illustrate = there=A0
are two AS path between A and D, one A-B-C-D the = other=A0
A-E-F-D disjoint (on intermediate ASs) either both = sequences=A0
are valid both policing and filtering makes you = selecting the=A0
inappropriate sequence for the real TE-LSP = consrttaints

In the inter-AS case, inter-AS = selection is likely to be driven by=A0
business = considerations and will be the result of (static or dynamic)=A0
inter-SP = service negociation and execution. Note that, as recalled by=A0
Adrian, = the objective is NOT to setup TE-LSPs over the Internet...
Also in your example, one may simply run two BRPC = with the=A0
two AS-Path and=A0
select = the best result...
[dp] in the inter AS case, which = is the most challenging, are=A0
you = telling=A0
me that the whole policing and filtering is done but = based on=A0
information=A0
elements = that require further negotiation phases - such that your=A0
=A0
doesn't provide you any further information but your = initial=A0
negotiation=A0
makes it = such that the probability of making the wrong selection is=A0
=A0
between = A=A0
and D, one A-B-C-D the other=A0
A-E-F-D = disjoint (on intermediate ASs) and both sequences are=A0
valid - = but=A0
now policing and filtering makes you selecting = the=A0
appropriate sequence=A0
for the = real TE-LSP consrttaints ?=A0

Yes, = this is what I meant
if this is = the case some further=A0

This is = already stated:

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

There is nothing more to say in this draft = IMO.

=
In the inter-area case, areas = selection is straightforward.

on 2) = this is part of the answer - the comment was PCE per=A0
domain = supporting that method - and in case of two PCEs or=A0
more per = domain i am not sure how one could guarantee that=A0
the = proposed (recursive) sequence works (assumption is made=A0
that the = PCE as full visibility on the whole domain but what=A0
in case = of multiple PCEs per domain)

If these PCEs = have the same visibility then there is NO issue.
If these PCEs don't have the same visibility, then = actually you have=A0
multiple sub-domains within the domain (or multiple = domains=A0
within a super=A0
=A0
where = each AS=A0
is made of several areas.
Is that your concern?

[dp] my = concern is that segmentation of PCE roles is not necessarily=A0
mapping = domain boundaries (intra-AS)=A0

Please = note that in PCE terminology a "domain" is a generic term, this is a set = of elements with a common sphere of path computation responsiblity (this = is not limited to IGP areas, ASes). Hence the set of elements under PCE = visibility is by definition a "domain", and segmentation of PCE roles IS = mapping "domain" boudaries.
The = procedures defined in this doc apply to multiple "domains", with this = generic definition of "domains".

Right, as stated in the = ID:

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



and the other case is when for=A0
instance = could have as example that for a given "AS" a PCE=A0
taking = care of=A0
TDM links and another ETH links hence you would have = a=A0
bifurcation - i=A0

Then you = have at least two "domains" (one for TDM and one for ETH), and the = procedures apply as is.

More generally when you have a = hierachy of domains (e.g. AS domains, on top of area domains on top of = techno domains) you need to run the BRPC procedure at each = level.
When you run the BRCP procedure = at level N you need to compute level N path segments, and this requires = calling BRPC at level N-1, this is recursive.

Best = Regards

Thanks.

JP.


JL
mean you get = a sequence of AS from routing but for each AS=A0
there = may be a=A0
set of PCE which not structured such as to map the = routing=A0
topology - i=A0
can = rephrase as for a sequence of AS there can be multiple=A0
=A0
PCEs if these have not complete view you need to = deal with=A0
intermediate=A0
=A0
=A0
PCEs on the forward path - the doc. currently says = "If=A0
multiple PCEs are=A0
=A0
on some = local=A0
policies/heuristics." what in case it doesn't = ?

In this situation, the inter-AS BRPC procedure = triggers a set of=A0
inter-area BRPC procedures in each AS to compute = intra-AS (ie=A0
inter-area)=A0
path = segments in each AS.=A0


JL



JL

=
i have also asked to have a = better description of the working=A0
=A0

if you = consider this as non-technical or technical feedback=A0
that's = your own appreciation=A0

- dimitri.






JP Vasseur = <jvasseur@cisco.com>
26/06/2006 14:54

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 nabil.n.bitar@verizon.com, = pce@ietf.org,=A0




although this *is* a constraint, = this is no big deal.
Actually, interestingly enough = there are quite a few cases=A0
where = there's only one single set of traversed domains.

2) We = need at least one PCE per domain
Sounds quite = obvious but I have no problem adding this.=A0
Actually = we're planning in the next revision to elaborate a=A0
little = bit on the inter-As link flooding (again this is not a=A0


hi j-p - see in-line




JP Vasseur <jvasseur@cisco.com>
26/06/2006 02:42

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 nabil.n.bitar@verizon.com, = pce@ietf.org,=A0



hi j-p - see in-line




JP Vasseur <jvasseur@cisco.com>
26/06/2006 01:14

=A0 =A0 =A0 =A0 To: =A0 =A0 Dimitri = PAPADIMITRIOU/BE/ALCATEL@ALCATEL
=A0 =A0 =A0 =A0 cc: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>,=A0
=A0 =A0 =A0 =A0 Subject:=A0 =A0 =A0 =A0 Re: [Pce] Re: = Comments on=A0
draft-vasseur-pce-brpc-00.txt


hi = dimitiri,

the following comment was also = discussed during last meeting

"=3D=3D
Section 5.1
I like the = simplicity of section 5.1, but I think you need to=A0
point = out that if the sequence of domains is known a priori=A0
(can you = determine it a
priori?) then the path computed = might not be 'optimal' in the=A0
usual = sense of the word, but that this is OK because the=A0
ordered = list of domains constitutes an additional constraint=A0
on the = computation so the resultant path *is* optimal within=A0
the = constraints applied.
Can't agree more. Good = suggestion, thanks.
Updated text: "The PCE-based = BRPC procedure applies to the=A0
=A0
The = sequence of domains to be traversed can either be=A0
=A0
The BRPC = procedure guarantees to compute the optimal path=A0
across a = specific set of traversed domains (which constitutes=A0
an = additional constraint). In the case of an arbitrary set of=A0
meshed = domains, the BRPC procedure can be used to compute the=A0
optimal = path across each domain set in order to get to=A0
optimal = constrained path between the source and the=A0

=3D> in brief, how to = determine the sequence through which path=A0
=A0
known = there is no need for such procedure (only inter-domain=A0
link = selection would be
required) -

Not = correct; even if you know the sequence you still need the=A0
BRPC = procedure to figure out the set of BN (boundary Nodes)=A0
to = traverse to get the shortest inter-domain TE LSP: this is=A0
the = whole issue with inter-domain, otherwise per-domain path=A0

[dp] inter-domain link selection = (as i mentioned) implies=A0
what you = mean with boundary nodes selection - you could=A0
rephrase = by access/exit point selection exact same business

but = again even if you know the sequence you still need BRPC=A0
to = determine the set of BN (or exit point - same thing) that=A0
will = give you the shortest inter-domain path. Look you wrote=A0
"in = brief, how to determine the sequence through which path=A0
=A0
known = there is no need for such procedure", which is not=A0
correct. = Even if you know the sequence of domains, you still=A0
need the = procedure to get the exit/entry point (named BN)=A0
that = provide you the shortest inter-domain path.


now adrian mentions that pre- = determination becomes a new=A0
=A0
TE LSP = itself but a restriction on the domain set known to be=A0
=A0
method = not returning an error message


No, this is a constraint: "Give me the shortest = path=A0
(potentially made of loose hops (the BNs)) that = provides the=A0
shortest end to end path, considering that the = additional=A0
constraint is to traverse the following set of = domains <D1,=A0
=
D2, ....>.

[dp] incorrect, this is not a "TE LSP" constraint = -=A0

Who said = that this was a TE LSP constraint ? This is *a*=A0

Please read the text: "The BRPC procedure guarantees = to=A0
compute the optimal path across a specific set of = traversed=A0
domains (which constitutes an additional = constraint)."

[dp] i read this, mind you, my point is that this is = not a=A0
"constraint"=A0
the same nature as the one = you're making use such as minimize=A0
delays = or whatsover - this constraint is introduced from the=A0
=A0

Note that at = this point, I still do not see the point that=A0
you're = trying to make here ?
since so far when
a set of domains do not support/or support a = given=A0
computation has not yet become a = constraint

hence sentence "The BRPC procedure guarantees to = compute the=A0
optimal path across a specific set of traversed = domains=A0
(which constitutes an additional constraint). In the = case of=A0
an arbitrary set of meshed domains, the BRPC = procedure can be=A0
used to compute the optimal path across each domain = set in=A0
order to get to optimal constrained path between the = source=A0
and the destination of the TE LSP."

should = as far as i understand the method fulfill the following

a) this = method provides a result iff all domains traversed by=A0
the = request support the proposed method

BRPC is a multi-PCE based = approach where you need at least=A0
one PCE = per-domain.

[dp] indeed, but one PCE supporting that method and = having=A0
FULL visibility of the domain

So what = is your point here ?
[dp] that the set of conditions = to have this method workable=A0
is = larger than the one listed in this doc.

b) this = method provides an "optimal" result iff

b1) all = possible sequences of domains have been traversed=A0
=A0
as there = might be an optimal path through a domain not=A0


heu ... yes indeed. If a domain does not support the = method,=A0
the method cannot be used to compute the = path.

b2) there is no discontinuity in the availability of = the=A0
inter-AS link information on each PCE performing a = given=A0
selection - indeed a domain might be supportive of = the method=A0
without supporting inter-AS link flooding

No this = is not a requirement, just an optimization. The only=A0
=A0
the = Inter- AS links. I'll detail a bit more in the next revision.

[dp] = then you can never achieve -

You can never achieve what = ?

Sorry Dimitri, I'd love to accommodate your comment = but I do=A0
not see your point ... hopefully we'll have a bit of = time in=A0
Montreal to discuss if that does not work by = email.

[dp] my point is that without this additional = information you=A0
can not achieve the expected result - i pointed to = your own=A0
text to indicate that this information is a must = have in=A0
order to achieve this objective=A0

using your = own words to make it more
=A0

"you = still need the BRPC procedure to figure out the set of=A0
BN = (boundary
Nodes) to traverse to get the = shortest inter-domain TE LSP:=A0
this is = the whole issue with inter-domain, otherwise=A0
=A0

be = sufficient."

b3) at each step there is no PCE that has partial = visibility=A0
of a given domain


This is not specific to BRPC. = Even with intra-domain if you want to=A0
compute = the path for a TE LSP, you cannot always use the PCE if it=A0
has a = partial visibility. Note that this also applies to=A0
the case of=A0
co-located PCE (when the path is = computed by the head-end).

[dp] hence, to BRPC as = well

b4) during the selection process no network = conditions changes=A0
(that would
make the = returned result void)

Again, this applies to other cases as = well.

[dp] ditto


Ah so we agree here :-)

What was your = comment then ?

[dp] that you need to include these set of = working=A0
=
conditions in the=A0
document itself, the document = looks like quite simple in terms of=A0
=A0
while = when=A0
you take a closer look at it this is not the = case

Thanks.

JP.



thanks.

JP.






JP Vasseur <jvasseur@cisco.com>
23/06/2006 16:11

=A0 =A0 =A0 =A0 To: =A0 =A0 "Adrian Farrel" <adrian@olddog.co.uk>
nabil.n.bitar@verizon.com
=A0 =A0 =A0 =A0 = Subject:=A0 =A0 =A0 =A0 = [Pce] Re: Comments on


Many Thanks Adrian for the comments.

We = incorporated the vast majority of them in the new revision = (just
posted).

See = below for the comments requesting some clarification.

On Jun = 10, 2006, at 8:49 AM, Adrian Farrel wrote:

Hi,

Thanks = for keeping these ideas alive.

Here are some picky thoughts = that you may want to include=A0
in the next
revision to make it more robust as a document. I = don't have=A0
=
any issues
with
the basic process.

Adrian

Is this I-D likely to be = Informational or Standards Track? From=A0
A,
this = looks like Standards Track. Can you remove Appendix A=A0
and put the
status in the usual place in the header?
=3D=3D

Status has been updated = (Informational) but let's discuss this=A0
later = on.
FYI, it does not appear on the = front page when using the xml2rfc=A0
(which by the way is excellent), = thus the appendix addition.

It would be nice if the Abstract = contained a pithy summary of brpc=A0
gave the motivation for the = draft. For example, what is the method=A0
to
achieve = that isn't achievable by other methods? Or, what is the
fundamental
element of = brpc that is not in other methods?

Agree. Here is the new = Abstract:
"The ability to compute = constrained shortest Traffic=A0
Engineering (TE)
Label Switched Paths (LSPs) in Multiprotocol Label = Switching (MPLS)=A0
and
Generalized = MPLS (GMPLS) networks across multiple domains (where a=A0
is referred to as a collection = of network elements within a common=A0
of address management or path = computational responsibility=A0
such as IGP
areas and Autonomous Systems) has been identified as = a key=A0
requirement .
This document = specifies a procedure relying on the use of multiple=A0
Computation Elements (PCEs) in = order to compute such inter-domain=A0
constraint paths, using a = backward recursive path computation=A0
while fully preserving = confidentiality requirements across=A0
domains. "


=3D=3D
I'm assuming that section 1 is for short term = information only and=A0
will = be
deleted (in the next revision?)
=3D=3D

Indeed, just to provide a bit of = history for the ones who have been
following = inter-domain path computation for a while.

=3D=3D
Section 4
=A0 - No topology or resource = information is distributed=A0
between domains
=A0 (as = mandated per [RFC4105] and [RFC4216]), which is critical to
=A0 = preserve IGP/BGP scalability and confidentiality in the case of = TE
=A0 = LSPs spanning multiple domains.
You = should clarify what you are saying here, because many would=A0
argue = that
reachability information (i.e. = external routes) constitutes=A0
topology = and
resource information.


OK = fine

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

It should actually read "pre-determined". Actually = the best thing=A0
to do
here is to = remove "off-line"

=3D=3D
Section = 5
=A0 = No assumption is made on the actual path computation algorithm = in=A0
use
=A0 by the PCE (it can be any = variant of CSPF, algorithm based on=A0
=A0 programming to solve = multi-constraints optimization=A0
problems and so
=A0 = on).
Suggest that you delete the text = in parenthesis because it is making
suggestions = that border on assumptions!

Well I'd suggest to keep it as = is since the point is to=A0
path computation procedure = from the algorithm to compute=A0
each intra-=A0
domain
path segment. Furthermore, we'd like to highlight = the fact that the=A0
BRPC
procedure = does not mandate for each PCE to use CSPF, could be other
algorithm.

=3D=3D
Section 5.1 and throughout
"BRPC path computation" seems to be = tautologous

It is actually a double tautology ;-) = (fixed).

=3D=3D
Section = 5.1
I like the simplicity of section = 5.1, but I think you need to point=A0
that
if the sequence of domains is known a priori (can = you determine it a
priori?) then the path = computed might not be 'optimal' in the usual=A0
of
the = word, but that this is OK because the ordered list of domains
constitutes an additional constraint on the = computation so the=A0
resultant
path *is* = optimal within the constraints applied.

Can't agree = more. Good suggestion, thanks.

Updated text: "The PCE-based = BRPC procedure applies to the=A0
an optimal constrained = inter-domain TE LSP. The sequence of domains=A0
to = be
traversed can either be determined a priori or = during the path=A0
computation
procedure. = The BRPC procedure guarantees to compute the optimal path
across a specific set of traversed domains (which = constitutes
an additional constraint). In = the case of an arbitrary set of meshed
domains, = the BRPC procedure can be used to compute the optimal path=A0
each domain set in order to get = to optimal constrained path between=A0
source and the destination of = the TE LSP."

=3D=3D
Section = 5.2
The introduction of the term = Virtual Shortest Path Tree is hard to=A0
and
to my = mind the definition is arse about tit. I think you could=A0
add
some = textual definition of what the VSPT is trying to=A0
achieve, before
presenting it in pictorial or abstract = form.
Even more important (I think) is = the fact that the tree as presented
"represents = the shortest path between the destination and BR-en=A0
Frankly, we are building = directional paths in exactly the oposite

This is an abstract form of representation but see = below,

So the VSPT is still a tree, but it is an MP2P tree, = not a P2MP=A0
tree as
I suspect that this is just a = textual descriptive issue rather than
broken in the process.


I clarified = the text to avoid any ambiguity (VSPT defined as a MP2P=A0

=3D=3D
Section = 5.2
I suggest that you pull the note = (Note: in term of=A0
=
computation...) out
=
into
a separate section. It doesn't belong in the middle = of section 5.2.
You will probably want to = re-write the text as well since the
limit is not necessary. Also to = explain 'flood' - flood to where,=A0
and = how,
and by whom? And you will want = to add to pieces of information:
- the link to = the I-D that defines how to do this
- a = description of what happens if this process is not used.

This = only works for unidirectional LSPs: indeed, the exit boundary=A0
can flood TE-related data in its = LSA/LSP for the link
=A0
running = on
the link but how would a node in domain (i) get = the TE-related data=A0
the link = entry(i+1,k')->exit-BN(i,k) ? I can't thus the=A0
restriction on
unidirectional link. Are we in sync ?

Section 5.2
The paragraph that begins "BRPC guarantees to find = the optimal..."=A0
is a
nascent = Applicability Statement. I suggest moving this to another=A0
and significantly beefing it up. = You need to describe more fully:
- how ECMP = works (the PCC has to request the return of more than=A0
one = path)
- how diversity works (i.e. = section 9 fits in here)
- how some = freedom of selection of domains can be offered
- how to mix the method with other = mechanisms

This was (and is) planned for future revision. Note = that ECMP and
diversity are discussed already = but we're planning the=A0
flesh out these
=
sections in further = revision.

=3D=3D
Section = 7
=A0 = If the BRPC procedure cannot be completed because a PCE along = the
=A0 domain path does not support = the procedure, a PCErr message is
=A0 returned by the upstream PCE = with a Error-Type "BRPC procedure
=A0 completion failure".=A0 The PCErr message MUST be = relayed to the
=A0 requesting PCC.
Not clear to me whether PCE(n) is supposed to know = that PCE(n+1)=A0
does not
support brpc, = presumably through capabilities
=A0
to
respond = to the path computation request saying that it does not=A0
bit-V of the RP object. If the = latter, presumably the PCErr=A0
comes from
PCE(n+1) and not from PCE(n) as = documented.

Good catch, typo: it should read "a PCErr message is = returned to the
upstream".
The plan is to define a capability bit (IGP) in a = further revision.

=3D=3D
Section = 8
Metric normalisation is a great potential = solution, but how does it=A0
with
AS topology confidentiality? What is the solution to = providing=A0
discretion
about what TE = connectivity is available within an AS, and operating=A0

Metric normalization is handled locally by the PCE = and does not=A0
impact the
BRPC = procedure per-say. As far as confidentiality is concerned,=A0
this = only
requires for the SPs to exchange = metric mapping information (nothing
related to = the network topology or resources); for example
SP 1 Links Cost =3D F (link_bandwidth) with F = (OC192)=3D1
SP 2 Links Cost =3D F = (link_bandwidth) with F (OC192)=3D10

A simple metric normalization = can then be performed on the PCE=A0
thanks = to
simple cost mapping tables.

Section = 10
Some of this text has been seen before in this = I-D
Why do you single out LSP = stitching as possibly breaking end-to-end
=A0
stitching and
nesting in this respect.
But further, your statement about stitching is = pejorative! If you=A0
say that
"In the case = where a domain has more than one BR-en or more than one
BR-ex,
optimality = after some network change within the domain can only be
guaranteed by re-executing the full brpc = computation" then I would=A0
with you. But as phrased, it = implies that making a per-domain
=A0
course) = is
not
the case - = per-domain optimisation will always improve or leave the=A0
end-to-end optimality (in the = case where new resources are made=A0
this is obvious; in the case of = a network failure, *any* path is=A0
than
no path!)
And, lastly, = the text about re-optimisation belongs in the next=A0
not
in this = section.


Yes I = wanted to leave that text to keep track of who would read the=A0
expecting reaction ;-)) = Per-domain reoptimization would always=A0
improve = the
current path *but* in case of = stitched LSPs, TE LSP segments are=A0
by the stitching point; thus in = case of failure, they could end up
following a = non optimal path whereas in the case of contiguous LSP,=A0
BRPC procedure would be called = again thus leading to the=A0
optimal path
again. The point that I was trying to make is "if = you have a=A0
stitched LSP
and rely on = BRPC when first signaled in an attempt to get an=A0
optimal = path,
you need to consider the = interaction between the local reopt mode=A0
and = BRPC
if the goal is to preserve an = optimal path at any given=A0
time". Anyway,
we're on the same page and I agree and the text = should be reworded
according to your proposal = to avoid any misunderstanding.

=3D=3D
Section 13
I would like = you to discuss the issues of confidentiality=A0
of topology
information at greater length. It seems that you = would possibly use=A0
this
technique in = conjunction with path cookies, which is fine. But, are=A0
two things you cannot escape = from?
- indicating which BR-en = provides best connectivity
- indicating = the metric for multiple BR-ens
Maybe there = are some things that can be done here based on policy,
including
not reporting = all of the BR-ens, ranking rather than giving absolute
metrics, etc. But these would compromise = optimality.

Indeed.

Maybe the PCE(n+1) should = carefully monitor and limit=A0
by
policy) brpc requests so that excessive information = is not divulged?

Since one of objectives for using the BRPC procedure = is to=A0
=
compute an
optimal path, we need to know at = least the BN (Boundary=A0
Nodes) and the
cost.

I wouldn't mind seeing a = Management Considerations section.
Do we need to = be able to examine the pruned pieces of VSPT=A0
at transit
PCEs?
What are the = implications of reporting multiple VSPT branches in=A0
PCEP = to
the
MIB = modules?
Is brpc support something that = needs to be configured: per PCE?; per
What are the implications on = existing protocols (IGPs?=A0
PCEP?) of using
brpc?

Absolutely ! I put a placeholder = for a further revision.

Fully supportive of adding such = section.

Many Thanks for your comments !


etc.
=3D=3D





I think = Jean-Louis' email address needs updating


=3D=3D
The document would benefit from a little care in the = formatting,=A0
and you
could = usefully re-read it for missing words, etc.
Pce mailing list
Pce mailing list



Pce mailing list




=
= --Apple-Mail-28--663163050-- --===============2132495521== 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 --===============2132495521==-- From pce-bounces@lists.ietf.org Thu Jun 29 14:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1gk-0006Da-5R; Thu, 29 Jun 2006 14:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw1gi-00067x-Ot; Thu, 29 Jun 2006 14:56:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw1gi-0002WB-Mo; Thu, 29 Jun 2006 14:56:28 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw1gg-0001HT-PG; Thu, 29 Jun 2006 14:56:28 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5TItPjx008050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 18:55:25 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw1fh-0007ER-KA; Thu, 29 Jun 2006 14:55:25 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 29 Jun 2006 14:55:25 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Internet Architecture Board , pce mailing list , pce chair , RFC Editor Subject: [Pce] Document Action: 'Path Computation Element (PCE) Communication Protocol Generic Requirements' to Informational RFC X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org The IESG has approved the following document: - 'Path Computation Element (PCE) Communication Protocol Generic Requirements ' as an Informational RFC This document is the product of the Path Computation Element Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-07.txt Technical Summary This document specifies generic requirements for a communications protocol between Path Computation Clients and Path Computation Elements. Working Group Summary No dissent. There were a few comments for clarification during last call that were addressed. Protocol Quality Ross Callon reviewed the document for the IESG, and sent a very short list of comments to the authors who have updated the spec. The document was also updatedbased on DISCUSS comments. IANA Note This document does not have any IANA implications. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce

Begin forwarded = message:

Date: June 23, 2006 3:50:01 PM = EDT
To: i-d-announce@ietf.org
Subject: = [Pce] I-D ACTION:draft-ietf-pce-pcep-02.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the = Path Computation Element Working Group of the IETF.

= Title = = : Path Computation Element (PCE) communication Protocol (PCEP) - = Version 1
Author(s) : J. = Vasseur, et al.
Filename : = draft-ietf-pce-pcep-02.txt
= Pages = = : 62
Date : 2006-6-23


This document = specifies the Path Computation Element communication
Protocol (PCEP) for communications between a Path = Computation Client
(PCC) and a Path = Computation Element (PCE), or between two PCEs.
Such interactions include path computation requests = and path
computation replies as well as = notifications of specific states
related to = the use of a PCE in the context of MPLS and GMPLS Traffic
Engineering.=A0 = The PCEP protocol is designed to be flexible and
extensible so as to easily allow for the addition of = further messages
and objects, should further = requirements be expressed in the future.

A URL for = this Internet-Draft is:

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


Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" = and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get = draft-ietf-pce-pcep-02.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-ietf-pce-pcep-02.txt".


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

= =


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