From jpv@cisco.com Mon May 2 10:44:05 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021F7E0780 for ; Mon, 2 May 2011 10:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEjazidq-TGJ for ; Mon, 2 May 2011 10:44:04 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 17257E0722 for ; Mon, 2 May 2011 10:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4246; q=dns/txt; s=iport; t=1304358244; x=1305567844; h=from:subject:date:references:to:message-id:mime-version; bh=cSg56/MyzEinyX6M/9O5Xcai3qu4KYidymDBUSpmBTQ=; b=GJNY1TXlRnzn545tXc4bWe/oIidkS8DHHkaqNW/f+FloiLTAmr4+LKpj pMPTjrGgmrfIQiQewAWOLzU9SQG6YD8MLltjqRozg3Id83dGiJHx4TtoG JTDcfY7NEFFkc5L0X8cviYmbKLrPN+wnH6qAXukBo1aAhMEiJmbkWJBDh Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYHAIfsvk2rRDoI/2dsb2JhbACYVI1Kd4hxnD2cFYYABI55hBkJigI X-IronPort-AV: E=Sophos;i="4.64,303,1301875200"; d="scan'208,217";a="306669313" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 02 May 2011 17:43:55 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p42Hhrqu009319 for ; Mon, 2 May 2011 17:43:54 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 10:43:43 -0700 Received: from [10.60.114.233] ([10.60.114.233]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 May 2011 10:43:42 -0700 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-26--366492073 Date: Mon, 2 May 2011 19:43:42 +0200 References: <20110425063018.GA3039@amsl.com> To: pce@ietf.org Message-Id: <5EE0E108-BC0D-48A1-BBC2-A488A6FF0508@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 02 May 2011 17:43:43.0111 (UTC) FILETIME=[7ABA6170:01CC08F0] Subject: [Pce] Fwd: Reminder - Contacting the IETF X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 17:44:05 -0000 --Apple-Mail-26--366492073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: "Glen Barney" > Date: April 25, 2011 8:30:18 AM GMT+02:00 > To: , > Subject: Reminder - Contacting the IETF >=20 > Dear IETF Community - >=20 > As a follow-up to the outage reminder sent earlier, please be advised = and > reminded that you can report technical and/or website problems to the = IETF > by sending email to the IETF Secretariat staff at: = ietf-action@ietf.org >=20 > Further information about ways to contact the secretariat and report = problems > can be seen at: http://www.ietf.org/secretariat/ >=20 > All community members should be aware of this contact information, in = the > event it is ever required. As always, if there are any questions, = please > let us know. >=20 > Glen > Glen Barney > IT Director > AMS (IETF Secretariat) >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 --Apple-Mail-26--366492073 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: "Glen Barney" = <glen@amsl.com>
Date: April 25, 2011 = 8:30:18 AM GMT+02:00
Subject: Reminder - = Contacting the IETF

Dear IETF = Community -

As a follow-up to the outage reminder sent earlier, please be advised = and
reminded that you can report technical and/or website problems to the = IETF
by sending email to the IETF Secretariat staff at:  ietf-action@ietf.org

Further information about ways to contact the secretariat and report = problems
can be seen at:  http://www.ietf.org/secretariat/=

All community members should be aware of this contact information, in = the
event it is ever required.  As always, if there are any questions, = please
let us know.

Glen
Glen Barney
IT Director
AMS (IETF Secretariat)

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.i= etf.org/mailman/listinfo/ietf-announce


= --Apple-Mail-26--366492073-- From db3546@att.com Tue May 3 12:28:45 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0A4E066E; Tue, 3 May 2011 12:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiRjUfvKaMcz; Tue, 3 May 2011 12:28:44 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8A58BE06F4; Tue, 3 May 2011 12:28:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1304450923!8738138!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24228 invoked from network); 3 May 2011 19:28:43 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 May 2011 19:28:43 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p43JReWr023114; Tue, 3 May 2011 15:27:40 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p43JRb8L023058; Tue, 3 May 2011 15:27: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 Date: Tue, 3 May 2011 15:28:39 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on draft-ietf-ccamp-wson-impairments-07.txt Thread-Index: AcwJyE3tevycrdwGQRmn+4YYG7L7Mg== From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Cc: pce@ietf.org Subject: [Pce] WG last call on draft-ietf-ccamp-wson-impairments-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 19:28:45 -0000 This mail begins a WG last call on: http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-07.txt This working group last call ends on May 17th. Please send comments to the CCAMP mailing list. Deborah (and Lou) From zhangfatai@huawei.com Wed May 4 00:42:45 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25092E0765 for ; Wed, 4 May 2011 00:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=3.471, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj-84-0IdKVf for ; Wed, 4 May 2011 00:42:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 179E3E075B for ; Wed, 4 May 2011 00:42:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN004D8UM2XZ@szxga03-in.huawei.com> for pce@ietf.org; Wed, 04 May 2011 15:39:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKN00D27UM249@szxga03-in.huawei.com> for pce@ietf.org; Wed, 04 May 2011 15:39:38 +0800 (CST) Received: from z41162a ([10.70.76.157]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKN00LVJUM2V4@szxml04-in.huawei.com> for pce@ietf.org; Wed, 04 May 2011 15:39:38 +0800 (CST) Date: Wed, 04 May 2011 15:39:38 +0800 From: Fatai Zhang To: pce@ietf.org Message-id: <02C309133F454E75A0D5EE03A17D311B@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_EzBFU6Opm1m5pYLdGjSM9g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Pce] Collect input about draft-ietf-pce-gmpls-aps-req-03 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 07:42:45 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EzBFU6Opm1m5pYLdGjSM9g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi PCEers, You may notice that this draft is expired and I plan to update it. If you have any suggestions or comments, please send them to me or to the list. Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 --Boundary_(ID_EzBFU6Opm1m5pYLdGjSM9g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi PCEers,
 
You may notice that this draft is expired and I plan to update it.
 
If you have any suggestions or comments, please send them to me or to the list.
 
 

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
--Boundary_(ID_EzBFU6Opm1m5pYLdGjSM9g)-- From Internet-Drafts@ietf.org Fri May 6 11:00:02 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF21E07BC; Fri, 6 May 2011 11:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQWSNa1I0oeY; Fri, 6 May 2011 11:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CABE077A; Fri, 6 May 2011 11:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110506180001.12930.40602.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 11:00:01 -0700 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-vendor-constraints-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 18:00:02 -0000 --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 : Conveying Vendor-Specific Constraints in the Path Computation Element Protocol Author(s) : F. Zhang, et al Filename : draft-ietf-pce-vendor-constraints-04.txt Pages : 9 Date : 2011-05-04 The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-vendor-constraints-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pce-vendor-constraints-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-06105751.I-D@ietf.org> --NextPart-- From Christian.Kaas-Petersen@tieto.com Mon May 9 00:11:32 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77B0E069A for ; Mon, 9 May 2011 00:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btj-dIZe-8oe for ; Mon, 9 May 2011 00:11:31 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 561F9E062A for ; Mon, 9 May 2011 00:11:29 -0700 (PDT) X-AuditID: 83cfa824-b7cd3ae000001e93-71-4dc7890f9004 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 12.57.07827.F0987CD4; Mon, 9 May 2011 09:26:23 +0300 (EEST) Received: from EXMB02.eu.tieto.com ([169.254.1.27]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Mon, 9 May 2011 09:26:23 +0300 From: To: Date: Mon, 9 May 2011 09:26:21 +0300 Thread-Topic: VENDOR-CONSTRAINT Thread-Index: AQHMDhIDa4bUtl3f/UeosLKOIzY6Kg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B7C8CAEF6689FC46814288FC8BB694BC1D5513B0B3EXMB02eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 07:11:33 -0000 --_000_B7C8CAEF6689FC46814288FC8BB694BC1D5513B0B3EXMB02eutieto_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT obje= ct. I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allo= wing vendor specific additions to for example the END-POINTS object. Christian --_000_B7C8CAEF6689FC46814288FC8BB694BC1D5513B0B3EXMB02eutieto_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
draft-i= etf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object.&nbs= p; I should like the draft also to introduce a VENDOR-CONSTRAINT TLV a= llowing vendor specific additions to for example the END-POINTS object.
 
Christian
--_000_B7C8CAEF6689FC46814288FC8BB694BC1D5513B0B3EXMB02eutieto_-- From zhangfatai@huawei.com Tue May 10 20:14:21 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557A3E06CE for ; Tue, 10 May 2011 20:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rVRwh22Dpmc for ; Tue, 10 May 2011 20:14:20 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE6E065D for ; Tue, 10 May 2011 20:14:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL00004TGZQ51@szxga04-in.huawei.com> for pce@ietf.org; Wed, 11 May 2011 11:14:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL000EJ0GZQYH@szxga04-in.huawei.com> for pce@ietf.org; Wed, 11 May 2011 11:14:14 +0800 (CST) Received: from z41162a ([10.70.76.157]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL000GBHGZP9N@szxml06-in.huawei.com> for pce@ietf.org; Wed, 11 May 2011 11:14:14 +0800 (CST) Date: Wed, 11 May 2011 11:14:13 +0800 From: Fatai Zhang To: Christian.Kaas-Petersen@tieto.com, pce@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_2G6NbSGCof9rIHPnGikNkQ)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 03:14:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_2G6NbSGCof9rIHPnGikNkQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Christian, Thanks for your comments. Could you explain a little more about what are requirements for the VENOR-CONSTRAINT TLV? Why VENOR-CONSTRAINT object can not meet these requirements? How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV? Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Christian.Kaas-Petersen@tieto.com To: pce@ietf.org Sent: Monday, May 09, 2011 2:26 PM Subject: [Pce] VENDOR-CONSTRAINT draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object. I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allowing vendor specific additions to for example the END-POINTS object. Christian ------------------------------------------------------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_2G6NbSGCof9rIHPnGikNkQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Christian,
 
Thanks for your comments.
 
Could you explain a little more about what are requirements for the VENOR-CONSTRAINT TLV?
Why VENOR-CONSTRAINT object can not meet these requirements?
How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV?
 
 

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Monday, May 09, 2011 2:26 PM
Subject: [Pce] VENDOR-CONSTRAINT

draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object.  I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allowing vendor specific additions to for example the END-POINTS object.
 
Christian

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
--Boundary_(ID_2G6NbSGCof9rIHPnGikNkQ)-- From Christian.Kaas-Petersen@tieto.com Tue May 10 23:55:29 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05ECE0771 for ; Tue, 10 May 2011 23:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZmHTtea0SSG for ; Tue, 10 May 2011 23:55:28 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 988BBE0733 for ; Tue, 10 May 2011 23:55:27 -0700 (PDT) X-AuditID: 83cfa824-b7cd3ae000001e93-59-4dca32dec461 Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 15.82.07827.ED23ACD4; Wed, 11 May 2011 09:55:26 +0300 (EEST) Received: from EXMB02.eu.tieto.com ([169.254.1.27]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Wed, 11 May 2011 09:55:25 +0300 From: To: , Date: Wed, 11 May 2011 09:53:57 +0300 Thread-Topic: [Pce] VENDOR-CONSTRAINT Thread-Index: AcwPiYUroVJmnPmUQWiChLZKWcPTJAAHq4I5 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 06:55:29 -0000 Certainly. The VENDOR-CONSTRAINT TLV could be formatted this way (similar to the VENDOR-CONSTRAINT object) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Enterprise-Specific Information ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the VENDOR-CONSTRAINT object to give additional information, so that it is possible to correlate the contents of the VENDOR-CONSTRAINT object with other objects in the message. By having a VENDOR-CONSTRAINT TLV, that TLV can be directly added to the object for which such additional information is wanted. Examples of use of VENDOR-CONSTRAINT TLV are as follows. * in PCNtf messages for vendor specific additions; * in END-POINTS object, specifically the Generalized Endpoints object type= , with vendor specific additions The addition of a VENDOR-CONSTRAINT TLV would free me from picking an unused value for the Type. The type I have picked is currently unused,=20 but may be assigned in the near future, and then follows the general proble= m=20 of updating not just future software (which is simple), but also existing software already delivered to customers (which is not so simple). Christian ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, May 11, 2011 05:14 To: Kaas-Petersen Christian; pce@ietf.org Subject: Re: [Pce] VENDOR-CONSTRAINT Hi Christian, Thanks for your comments. Could you explain a little more about what are requirements for the VENOR-C= ONSTRAINT TLV? Why VENOR-CONSTRAINT object can not meet these requirements? How many (and which) objects should be extended to include VENOR-CONSTRAINT= TLV? Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Christian.Kaas-Petersen@tieto.com To: pce@ietf.org Sent: Monday, May 09, 2011 2:26 PM Subject: [Pce] VENDOR-CONSTRAINT draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT obje= ct. I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allo= wing vendor specific additions to for example the END-POINTS object. Christian ________________________________ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From zhangfatai@huawei.com Wed May 11 00:46:49 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F97FE0781 for ; Wed, 11 May 2011 00:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhGOGi9AlNgt for ; Wed, 11 May 2011 00:46:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB80E067B for ; Wed, 11 May 2011 00:46:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL00066QTIEWA@szxga03-in.huawei.com> for pce@ietf.org; Wed, 11 May 2011 15:44:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL0004V5TIEX0@szxga03-in.huawei.com> for pce@ietf.org; Wed, 11 May 2011 15:44:38 +0800 (CST) Received: from z41162a ([10.70.76.157]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL000C7UTIEJG@szxml04-in.huawei.com> for pce@ietf.org; Wed, 11 May 2011 15:44:38 +0800 (CST) Date: Wed, 11 May 2011 15:44:38 +0800 From: Fatai Zhang To: Christian.Kaas-Petersen@tieto.com, pce@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_JkKiDBsQyDlTd3SVmcY+jg)" X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 07:46:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_JkKiDBsQyDlTd3SVmcY+jg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Christian, You said "If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the VENDOR-CONSTRAINT object to give additional information, so that it is possible to correlate the contents of the VENDOR-CONSTRAINT object with other objects in the message." I don't think that it needs any additional information if only the VENDOR-CONSTRAINT object is used. You can look at the description for "Enterprise-Specific Information": ======================================================= Enterprise-Specific Information The detailed enterprise-specific constraint information carried by the object. The format and interpretation of this information is a matter for the enterprise identified by the Enterprise Number. Such formats and interpretation MAY be published by the enterprise (possibly through an informational RFC or through commercial documentation) so that PCCs or PCEs that are not part of the organization can use the information. ============================================================== By using only the VENDOR-CONSTRAINT object, I think it can keep the PCEP protocol much simple without touching so many different existing objects. Hope this can clarify your concern. Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: To: ; Sent: Wednesday, May 11, 2011 2:53 PM Subject: RE: [Pce] VENDOR-CONSTRAINT Certainly. The VENDOR-CONSTRAINT TLV could be formatted this way (similar to the VENDOR-CONSTRAINT object) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Enterprise-Specific Information ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the VENDOR-CONSTRAINT object to give additional information, so that it is possible to correlate the contents of the VENDOR-CONSTRAINT object with other objects in the message. By having a VENDOR-CONSTRAINT TLV, that TLV can be directly added to the object for which such additional information is wanted. Examples of use of VENDOR-CONSTRAINT TLV are as follows. * in PCNtf messages for vendor specific additions; * in END-POINTS object, specifically the Generalized Endpoints object type, with vendor specific additions The addition of a VENDOR-CONSTRAINT TLV would free me from picking an unused value for the Type. The type I have picked is currently unused, but may be assigned in the near future, and then follows the general problem of updating not just future software (which is simple), but also existing software already delivered to customers (which is not so simple). Christian ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, May 11, 2011 05:14 To: Kaas-Petersen Christian; pce@ietf.org Subject: Re: [Pce] VENDOR-CONSTRAINT Hi Christian, Thanks for your comments. Could you explain a little more about what are requirements for the VENOR-CONSTRAINT TLV? Why VENOR-CONSTRAINT object can not meet these requirements? How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV? Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Christian.Kaas-Petersen@tieto.com To: pce@ietf.org Sent: Monday, May 09, 2011 2:26 PM Subject: [Pce] VENDOR-CONSTRAINT draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object. I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allowing vendor specific additions to for example the END-POINTS object. Christian ________________________________ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_JkKiDBsQyDlTd3SVmcY+jg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Christian,
 
You said "If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the VENDOR-CONSTRAINT object to give additional information, so that it is possible to correlate the contents of the VENDOR-CONSTRAINT object with other objects in the message."
 
I don't think that it needs any additional information if only the VENDOR-CONSTRAINT object is used. You can look at the description for "Enterprise-Specific Information":
 
=======================================================  
Enterprise-Specific Information

The detailed enterprise-specific constraint information carried by the object. The format and interpretation of this information is a matter for the enterprise identified by the Enterprise Number. Such formats and interpretation MAY be published by the enterprise (possibly through an informational RFC or through commercial documentation) so that PCCs or PCEs that are not part of the organization can use the information.
==============================================================
By using only the VENDOR-CONSTRAINT object, I think it can keep the PCEP protocol much simple without touching so many different existing objects.
 
Hope this can clarify your concern.
 

Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Wednesday, May 11, 2011 2:53 PM
Subject: RE: [Pce] VENDOR-CONSTRAINT

Certainly.

The VENDOR-CONSTRAINT TLV could be formatted this way (similar to
the VENDOR-CONSTRAINT object)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type                |          Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Enterprise Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                 Enterprise-Specific Information               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere
in the VENDOR-CONSTRAINT object to give additional information, so that
it is possible to correlate the contents of the VENDOR-CONSTRAINT object
with other objects in the message.  By having a VENDOR-CONSTRAINT TLV,
that TLV can be directly added to the object for which such additional
information is wanted.

Examples of use of VENDOR-CONSTRAINT TLV are as follows.
 * in PCNtf messages for vendor specific additions;
 * in END-POINTS object, specifically the Generalized Endpoints object type,
   with vendor specific additions
The addition of a VENDOR-CONSTRAINT TLV would free me from picking an
unused value for the Type.  The type I have picked is currently unused,
but may be assigned in the near future, and then follows the general problem
of updating not just future software (which is simple),
but also existing software already delivered to customers (which is not so
simple).

Christian


________________________________________
From: Fatai Zhang [zhangfatai@huawei.com]
Sent: Wednesday, May 11, 2011 05:14
To: Kaas-Petersen Christian; pce@ietf.org
Subject: Re: [Pce] VENDOR-CONSTRAINT

Hi Christian,

Thanks for your comments.

Could you explain a little more about what are requirements for the VENOR-CONSTRAINT TLV?
Why VENOR-CONSTRAINT object can not meet these requirements?
How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV?



Thanks

Fatai

Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
From: Christian.Kaas-Petersen@tieto.com<mailto:Christian.Kaas-Petersen@tieto.com>
To: pce@ietf.org<mailto:pce@ietf.org>
Sent: Monday, May 09, 2011 2:26 PM
Subject: [Pce] VENDOR-CONSTRAINT

draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object.  I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allowing vendor specific additions to for example the END-POINTS object.

Christian

________________________________

_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
--Boundary_(ID_JkKiDBsQyDlTd3SVmcY+jg)-- From cyril.margaria@nsn.com Wed May 11 03:45:01 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B952E0720 for ; Wed, 11 May 2011 03:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CORLds1iaoCa for ; Wed, 11 May 2011 03:44:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9E690E0679 for ; Wed, 11 May 2011 03:44:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p4BAimun014474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 12:44:48 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4BAimM0021973; Wed, 11 May 2011 12:44:48 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 12:44:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC0FC8.7310900F" Date: Wed, 11 May 2011 12:44:47 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] VENDOR-CONSTRAINT Thread-Index: AcwPr51mGcStQRmRQbGaqLypOSyBGwAFSDLQ References: From: "Margaria, Cyril (NSN - DE/Munich)" To: "ext Fatai Zhang" , , X-OriginalArrivalTime: 11 May 2011 10:44:47.0983 (UTC) FILETIME=[72BDF7F0:01CC0FC8] Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 10:45:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC0FC8.7310900F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Hi Fatai, Christian, PCE-ers,=20 =20 I think that having one extra TLV is usefull when you want to add object-specific vendor constraints and not general one, the information carried will remain the same but in another place and more accessible. =20 Having a generic vendor specific object seems a catch-all solution that is likely to include any vendor private information and might leave too much room for private information. Another possible angle to carry vendor-specific constraint is not to have a generic object but rather a set of very specifically scoped TLVs or sub-objects. =20 This can be applied to the PCEP as follow : - Objective function : private OF code is already defined, an private_of_parameter_tlv (only valid inside the OF object) would carry possible operator-specific parameters - Metric : a private metric type can be defined, with vendors specific body and metric value. - For GMPLS endpoint constraint a TLV for vendor-private label constraint (valid for endpoints and label_set only for instance) can be defined. - For WSON-specifics this is for example covered in draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding from draft-ietf-ccamp-wson-signaling-01 =20 For sure it's possible to put all those in one object, but I am not sure it's the best strategy in order to avoid all private extensions. =20 I think some feedback from the WG on this topic, especially from people have implementation background, would be helpful. =20 Best Regards. =20 From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of ext Fatai Zhang Sent: Wednesday, May 11, 2011 9:45 AM To: Christian.Kaas-Petersen@tieto.com; pce@ietf.org Subject: Re: [Pce] VENDOR-CONSTRAINT =20 Hi Christian, =20 You said "If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the VENDOR-CONSTRAINT object to give additional information, so that it is possible to correlate the contents of the VENDOR-CONSTRAINT object with other objects in the message." =20 I don't think that it needs any additional information if only the VENDOR-CONSTRAINT object is used. You can look at the description for "Enterprise-Specific Information": =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=3D=3D=3D=3D =20 Enterprise-Specific Information The detailed enterprise-specific constraint information carried by the object. The format and interpretation of this information is a matter for the enterprise identified by the Enterprise Number. Such formats and interpretation MAY be published by the enterprise (possibly through an informational RFC or through commercial documentation) so that PCCs or PCEs that are not part of the organization can use the information. =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D By using only the VENDOR-CONSTRAINT object, I think it can keep the PCEP protocol much simple without touching so many different existing objects. =20 Hope this can clarify your concern. =20 Thanks =20 Fatai =20 Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message -----=20 From: > To: >; > Sent: Wednesday, May 11, 2011 2:53 PM Subject: RE: [Pce] VENDOR-CONSTRAINT =20 Certainly. The VENDOR-CONSTRAINT TLV could be formatted this way (similar to the VENDOR-CONSTRAINT object) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Enterprise-Specific Information ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If only the VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the VENDOR-CONSTRAINT object to give additional information, so that it is possible to correlate the contents of the VENDOR-CONSTRAINT object with other objects in the message. By having a VENDOR-CONSTRAINT TLV, that TLV can be directly added to the object for which such additional information is wanted. Examples of use of VENDOR-CONSTRAINT TLV are as follows. * in PCNtf messages for vendor specific additions; * in END-POINTS object, specifically the Generalized Endpoints object type, with vendor specific additions The addition of a VENDOR-CONSTRAINT TLV would free me from picking an unused value for the Type. The type I have picked is currently unused,=20 but may be assigned in the near future, and then follows the general problem=20 of updating not just future software (which is simple), but also existing software already delivered to customers (which is not so simple). Christian ________________________________________ From: Fatai Zhang [zhangfatai@huawei.com] Sent: Wednesday, May 11, 2011 05:14 To: Kaas-Petersen Christian; pce@ietf.org =20 Subject: Re: [Pce] VENDOR-CONSTRAINT Hi Christian, Thanks for your comments. Could you explain a little more about what are requirements for the VENOR-CONSTRAINT TLV? Why VENOR-CONSTRAINT object can not meet these requirements? How many (and which) objects should be extended to include VENOR-CONSTRAINT TLV? Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Christian.Kaas-Petersen@tieto.com > To: pce@ietf.org > Sent: Monday, May 09, 2011 2:26 PM Subject: [Pce] VENDOR-CONSTRAINT draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT object. I should like the draft also to introduce a VENDOR-CONSTRAINT TLV allowing vendor specific additions to for example the END-POINTS object. Christian ________________________________ _______________________________________________ Pce mailing list Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce =20 ------_=_NextPart_001_01CC0FC8.7310900F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Hi Fatai, Christian, PCE-ers,

 

I think that having one extra TLV is usefull  when you want to = add object-specific vendor constraints and not general one, the = information carried will remain the same but in another place and more = accessible.

 

Having a generic vendor specific object seems a catch-all solution = that is likely to  include any vendor private information and might =  leave too much room for private = information.

Another possible angle to carry vendor-specific constraint is not to = have a generic object but rather a set of very specifically scoped TLVs = or sub-objects.

 

This can be applied to the PCEP as follow :

-          Objective = function : private OF code is already defined, an = private_of_parameter_tlv (only valid inside the OF object) would carry = possible operator-specific parameters

-          Metric : a = private metric type can be defined, with vendors specific body and = metric value.

-          For GMPLS = endpoint constraint a TLV for vendor-private label constraint (valid for = endpoints and label_set only for instance) can be = defined.

-          For = WSON-specifics this is for example covered in = draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding = from draft-ietf-ccamp-wson-signaling-01

 

For sure it’s possible to put all those in one object, but I am = not sure it’s the best strategy in order to avoid all private = extensions.

 

I think some feedback from the WG on this topic, especially from = people have implementation background, would be = helpful.

 

Best Regards.

 

From:= = pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of = ext Fatai Zhang
Sent: Wednesday, May 11, 2011 9:45 = AM
To: Christian.Kaas-Petersen@tieto.com; = pce@ietf.org
Subject: Re: [Pce] = VENDOR-CONSTRAINT

 

Hi = Christian,

 

You said = "If only the = VENDOR-CONSTRAINT object is possible, it is necessary somewhere in the = VENDOR-CONSTRAINT object to give additional information, so that it is = possible to correlate the contents of the VENDOR-CONSTRAINT object with = other objects in the message."

 

I don't think = that it needs any additional information if only = the VENDOR-CONSTRAINT object is used. You can look at the = description for "Enterprise-Specific = Information":

 

=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=3D=3D=3D=3D<= /span>  

Enterprise-Specific Information

The detailed = enterprise-specific constraint information carried by the object. The format and interpretation of this information is = a matter for the enterprise identified by the Enterprise = Number. Such formats and interpretation = MAY be published by the enterprise (possibly through an = informational RFC or through commercial documentation) so that PCCs or = PCEs that are not part of the organization can use the = information.
=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=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

By using only = the VENDOR-CONSTRAINT object, I think it can keep the PCEP = protocol much simple without touching so many different existing = objects.

 

Hope this can = clarify your concern.

 


Thanks
 <= br>Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, = Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: = +86-755-28972912
Fax: = +86-755-28972935

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

From: <Christian.Kaas-P= etersen@tieto.com>

To: <zhangfatai@huawe= i.com>; = <pce@ietf.org>

Sent: Wednesday, May 11, = 2011 2:53 PM

Subject: RE: [Pce] = VENDOR-CONSTRAINT

 

Certainly.

The = VENDOR-CONSTRAINT TLV could be formatted this way (similar to
the = VENDOR-CONSTRAINT object)

      = 0            =        = 1            =        = 2            =        3
      = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    = |            = = Type           &nb= sp;    = |          = Length           &= nbsp; |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    = |            =            Enterprise = Number           &= nbsp;           = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
&nbs= p;    = ~            =      Enterprise-Specific = Information          &n= bsp;    ~
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

= If only the VENDOR-CONSTRAINT object is possible, it is necessary = somewhere
in the VENDOR-CONSTRAINT object to give additional = information, so that
it is possible to correlate the contents of the = VENDOR-CONSTRAINT object
with other objects in the message.  By = having a VENDOR-CONSTRAINT TLV,
that TLV can be directly added to the = object for which such additional
information is = wanted.

Examples of use of VENDOR-CONSTRAINT TLV are as = follows.
 * in PCNtf messages for vendor specific = additions;
 * in END-POINTS object, specifically the Generalized = Endpoints object type,
   with vendor specific = additions
The addition of a VENDOR-CONSTRAINT TLV would free me from = picking an
unused value for the Type.  The type I have picked is = currently unused,
but may be assigned in the near future, and then = follows the general problem
of updating not just future software = (which is simple),
but also existing software already delivered to = customers (which is not = so
simple).

Christian


______________________________= __________
From: Fatai Zhang [zhangfatai@huawei.com]
Sent: = Wednesday, May 11, 2011 05:14
To: Kaas-Petersen Christian; pce@ietf.org
Subject: = Re: [Pce] VENDOR-CONSTRAINT

Hi Christian,

Thanks for your = comments.

Could you explain a little more about what are = requirements for the VENOR-CONSTRAINT TLV?
Why VENOR-CONSTRAINT = object can not meet these requirements?
How many (and which) objects = should be extended to include VENOR-CONSTRAINT = TLV?



Thanks

Fatai

Huawei Technologies Co., = LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 = P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- = Original Message -----
From: Christian.Kaas-P= etersen@tieto.com<mailto:Christian.Kaas-Petersen@tieto.com<= span style=3D'font-family:"Calibri","sans-serif"'>>
To: pce@ietf.org<= mailto:pce@ietf.org>
Sent: Monday, May = 09, 2011 2:26 PM
Subject: [Pce] = VENDOR-CONSTRAINT

draft-ietf-pce-vendor-constraints-04 describes = a new VENDOR-CONSTRAINT object.  I should like the draft also to = introduce a VENDOR-CONSTRAINT TLV allowing vendor specific additions to = for example the END-POINTS = object.

Christian

________________________________

_= ______________________________________________
Pce mailing = list
Pce@ietf.org<= mailto:Pce@ietf.org>
https://www.ietf= .org/mailman/listinfo/pce

------_=_NextPart_001_01CC0FC8.7310900F-- From cyril.margaria@nsn.com Wed May 11 04:53:40 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7CE0746 for ; Wed, 11 May 2011 04:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5eDLG8rsmcy for ; Wed, 11 May 2011 04:53:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A1082E06D6 for ; Wed, 11 May 2011 04:53:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p4BBrapr021842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2011 13:53:36 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p4BBrZ67003958; Wed, 11 May 2011 13:53:36 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 May 2011 13:53: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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 May 2011 13:53:31 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] VENDOR-CONSTRAINT Thread-Index: AcwPiYUroVJmnPmUQWiChLZKWcPTJAAHq4I5AAoHvnA= References: , From: "Margaria, Cyril (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 11 May 2011 11:53:32.0328 (UTC) FILETIME=[0D0B1280:01CC0FD2] Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 11:53:40 -0000 Hi Fatai,=20 One additional comment on that is when the constraint may apply to only one occurrence of an object, for instance additional BANDWIDTH constraint=20 or in case of P2MP to ENDPOINT, it is additional work to define a vendor format that take into account which occurrence of the object the constraint apply to. In addition the grammar proposed in draft-ietf-pce-vendor-constraints-04 is not clear regarding to RFC6006 : should the also be present in the ? The RFC6006 does also introduce a capability indication in the OPEN=20 message, was this possibility considered the PCC/PCE to discover the=20 supported vendor-constraints? Would it make sense or should the PCC=20 try to use it on the requests? Best regards. > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > ext Christian.Kaas-Petersen@tieto.com > Sent: Wednesday, May 11, 2011 8:54 AM > To: zhangfatai@huawei.com; pce@ietf.org > Subject: Re: [Pce] VENDOR-CONSTRAINT >=20 > Certainly. >=20 > The VENDOR-CONSTRAINT TLV could be formatted this way (similar to the > VENDOR-CONSTRAINT object) >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Enterprise-Specific Information ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > If only the VENDOR-CONSTRAINT object is possible, it is necessary > somewhere in the VENDOR-CONSTRAINT object to give additional > information, so that it is possible to correlate the contents of the > VENDOR-CONSTRAINT object with other objects in the message. By having > a VENDOR-CONSTRAINT TLV, that TLV can be directly added to the object > for which such additional information is wanted. >=20 > Examples of use of VENDOR-CONSTRAINT TLV are as follows. > * in PCNtf messages for vendor specific additions; > * in END-POINTS object, specifically the Generalized Endpoints object > type, > with vendor specific additions > The addition of a VENDOR-CONSTRAINT TLV would free me from picking an > unused value for the Type. The type I have picked is currently unused, > but may be assigned in the near future, and then follows the general > problem of updating not just future software (which is simple), but > also existing software already delivered to customers (which is not so > simple). >=20 > Christian >=20 >=20 > ________________________________________ > From: Fatai Zhang [zhangfatai@huawei.com] > Sent: Wednesday, May 11, 2011 05:14 > To: Kaas-Petersen Christian; pce@ietf.org > Subject: Re: [Pce] VENDOR-CONSTRAINT >=20 > Hi Christian, >=20 > Thanks for your comments. >=20 > Could you explain a little more about what are requirements for the > VENOR-CONSTRAINT TLV? > Why VENOR-CONSTRAINT object can not meet these requirements? > How many (and which) objects should be extended to include VENOR- > CONSTRAINT TLV? >=20 >=20 >=20 > Thanks >=20 > Fatai >=20 > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 > ----- Original Message ----- > From: Christian.Kaas-Petersen@tieto.com Petersen@tieto.com> > To: pce@ietf.org > Sent: Monday, May 09, 2011 2:26 PM > Subject: [Pce] VENDOR-CONSTRAINT >=20 > draft-ietf-pce-vendor-constraints-04 describes a new VENDOR-CONSTRAINT > object. I should like the draft also to introduce a VENDOR-CONSTRAINT > TLV allowing vendor specific additions to for example the END-POINTS > object. >=20 > Christian >=20 > ________________________________ >=20 > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From ramon.casellas@cttc.es Wed May 11 05:29:27 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1BE0746 for ; Wed, 11 May 2011 05:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLWfbQjXc0f2 for ; Wed, 11 May 2011 05:29:25 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 63643E06D1 for ; Wed, 11 May 2011 05:29:24 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4BCT3pN000662 for ; Wed, 11 May 2011 14:29:08 +0200 Received: from [84.88.61.50] (pcrcasellas.cttc.es [84.88.61.50]) by castor (Postfix) with ESMTP id 3898C2FC22C for ; Wed, 11 May 2011 14:29:09 +0200 (CEST) Message-ID: <4DCA81F9.2080807@cttc.es> Date: Wed, 11 May 2011 14:32:57 +0200 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "pce@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010907080407010601060105" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Wed, 11 May 2011 14:29:09 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 12:29:28 -0000 This is a multi-part message in MIME format. --------------010907080407010601060105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cyril, all, First, speaking from a personal point of view, I would say that I am not a big fan of VENDOR_X extensions. I would rather like to see those constraints / TLVs etc. open for standardization. Having vendor extensions will indeed limit interoperability, e.g. having a VENDOR_CONTRAINT object with the P-bit set basically means that only that vendor (and associated "partners") can do path computation for that request ?. This is analogue to having the whole PCEP interface as proprietary defeating the standardization purpose. It may be argued that a TLV may provide finer granularity to qualify a given object, rather than some more generic, packed object, but as long as the contents are opaque I worry that the default "ignore TLV" action would not be respecting the PCC constraints. Finally, if there is an VENDOR_CONSTRAINT object, VENDOR_CONSTRAINT_TLV why not a VENDOR_ message? :) For the rest of the mail, please see inline On 11/05/2011 12:44, Margaria, Cyril (NSN - DE/Munich) wrote: > > Hi Fatai, Christian, PCE-ers, > > I think that having one extra TLV is usefull when you want to add > object-specific vendor constraints and not general one, the > information carried will remain the same but in another place and more > accessible. > In this sense, it is unfortunate that not all objects are potentially TLV containers, (e.g. we had to define GENERALIZED_BANDWIDTH due to this) so only objects that are actually defined by RFC5440 as "containers" could have "vendor extensions" as TLVs. There is no way to add a VENDOR TLV to the bandwidth object, for example > Having a generic vendor specific object seems a catch-all solution > that is likely to include any vendor private information and might > leave too much room for private information. > Agreed. > Another possible angle to carry vendor-specific constraint is not to > have a generic object but rather a set of very specifically scoped > TLVs or sub-objects. > To some extent, yes, but then we shift the problem elsewhere. First, I am not sure if the standard way to proceed when a proprietary (unknown) TLV is found in an object (RFC 5440 $7.1, "Unrecognized TLVs MUST be ignored") would be the best thing to do. Without that vendor-specific information I am not sure if the resulting path is ignoring some MUST-USE TLV. However, at least, I know what object is "extended with vendor information" by virtue of being a TLV of that object. > This can be applied to the PCEP as follow : > > - Objective function : private OF code is already defined, an > private_of_parameter_tlv (only valid inside the OF object) would carry > possible operator-specific parameters > > - Metric : a private metric type can be defined, with vendors > specific body and metric value. > Being nitpicking here .-) , but contrary to OF, metric types are assigned by IETF review process. Nothing precludes defining a private range but afaik it is not the case now. > > - For GMPLS endpoint constraint a TLV for vendor-private > label constraint (valid for endpoints and label_set only for instance) > can be defined. > > - For WSON-specifics this is for example covered in > draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding > from draft-ietf-ccamp-wson-signaling-01 > I would be less against the proliferation of vendor TLVs if there is a clear "consensus" that those TLVs are only meaningful in the context of "private" ranges as Cyril examples. In other words, if the OF object with a code in the range 32768- has vendor TLVs I am fine. If I can't apply that OF code I don't care about the TLVs, and the processing rules for OF objects are standard and clear. > For sure it's possible to put all those in one object, but I am not > sure it's the best strategy in order to avoid all private extensions. > Honestly, thinking that discussing whether private extensions either in objects or in TLVs would lead us to a best strategy in order to avoid private extensions seems weird :-) That said, "less of two evils"? the TLVs seem more granular, provide some information of what object they qualify, the processing rules are clear leading to "ignore the TLV", (it is important to note that I understand that an object that a PCE can "process" with P-bit set but with unknown TLVs does not imply the request being rejected) but not all object support TLVs. Best regards Ramon --------------010907080407010601060105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cyril, all,


First, speaking from a personal point of view, I would say that I am not a big fan of VENDOR_X extensions. I would rather like to see those constraints / TLVs etc. open for standardization.

Having vendor extensions will indeed limit interoperability, e.g. having a VENDOR_CONTRAINT object with the P-bit set basically means that only that vendor (and associated "partners") can do path computation for that request ?. This is analogue to having the whole PCEP interface as proprietary defeating the standardization purpose.

It may be argued that a TLV may provide finer granularity to qualify a given object, rather than some more generic, packed object, but as long as the contents are opaque I worry that the default "ignore TLV" action would not be respecting the PCC constraints.

<sarcastic> Finally, if there is an VENDOR_CONSTRAINT object, VENDOR_CONSTRAINT_TLV why not a VENDOR_ message? :) </sarcastic>


For the rest of the mail, please see inline


On 11/05/2011 12:44, Margaria, Cyril (NSN - DE/Munich) wrote:

 

Hi Fatai, Christian, PCE-ers,

 

I think that having one extra TLV is usefull  when you want to add object-specific vendor constraints and not general one, the information carried will remain the same but in another place and more accessible.


In this sense, it is unfortunate that not all objects are potentially TLV containers, (e.g. we had to define GENERALIZED_BANDWIDTH due to this) so only objects that are actually defined by RFC5440 as "containers" could have "vendor extensions" as TLVs. There is no way to add a VENDOR TLV to the bandwidth object, for example


 

Having a generic vendor specific object seems a catch-all solution that is likely to  include any vendor private information and might  leave too much room for private information.

Agreed.


Another possible angle to carry vendor-specific constraint is not to have a generic object but rather a set of very specifically scoped TLVs or sub-objects.

 

To some extent, yes, but then we shift the problem elsewhere. First, I am not sure if the standard way to proceed when a proprietary (unknown) TLV is found in an object (RFC 5440 $7.1,  "Unrecognized TLVs MUST be ignored") would be the best thing to do.
Without that vendor-specific information I am not sure if the resulting path is ignoring some MUST-USE TLV. However, at least, I know what object is "extended with vendor information" by virtue of being a TLV of that object.



This can be applied to the PCEP as follow :

-          Objective function : private OF code is already defined, an private_of_parameter_tlv (only valid inside the OF object) would carry possible operator-specific parameters

-          Metric : a private metric type can be defined, with vendors specific body and metric value.

Being nitpicking here .-) , but contrary to OF, metric types are assigned by IETF review process. Nothing precludes defining a private range but afaik it is not the case now.

-          For GMPLS endpoint constraint a TLV for vendor-private label constraint (valid for endpoints and label_set only for instance) can be defined.

-          For WSON-specifics this is for example covered in draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding from draft-ietf-ccamp-wson-signaling-01

 

I would be less against the proliferation of vendor TLVs if there is a clear "consensus"  that those TLVs are only meaningful in the context of "private" ranges as Cyril examples. In other words, if the OF object with a code in the range 32768- has vendor TLVs I am fine. If I can't apply that OF code I don't care about the TLVs, and the processing rules for OF objects are standard and clear.


For sure it’s possible to put all those in one object, but I am not sure it’s the best strategy in order to avoid all private extensions.

 

Honestly, thinking that discussing whether private extensions either in objects or in TLVs would lead us to a best strategy in order to avoid private extensions seems weird :-)

That said, "less of two evils"?  the TLVs seem more granular, provide some information of what object they qualify, the processing rules are clear leading to "ignore the TLV", (it is important to note that I understand that an object that a PCE can "process" with P-bit set but with unknown TLVs does not imply the request being rejected) but not all object support TLVs.


Best regards
Ramon --------------010907080407010601060105-- From db3546@att.com Thu May 19 06:34:40 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11CDE06FA; Thu, 19 May 2011 06:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVqb64PT-4cB; Thu, 19 May 2011 06:34:40 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4191BE066A; Thu, 19 May 2011 06:34:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1305812078!18433633!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 14332 invoked from network); 19 May 2011 13:34:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 May 2011 13:34:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4JDXY7P008265; Thu, 19 May 2011 09:33:34 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4JDXTSg008163; Thu, 19 May 2011 09:33:30 -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 Date: Thu, 19 May 2011 09:34:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG last call on draft-ietf-ccamp-wson-impairments-07.txt Thread-Index: AcwJyE3tevycrdwGQRmn+4YYG7L7MgMYPreg References: From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Cc: pce@ietf.org Subject: Re: [Pce] WG last call on draft-ietf-ccamp-wson-impairments-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 13:34:40 -0000 This working group last call has ended. The chairs will prepare for forwarding for publication. -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTSI) Sent: Tuesday, May 03, 2011 3:29 PM To: CCAMP Cc: pce@ietf.org Subject: [Pce] WG last call on draft-ietf-ccamp-wson-impairments-07.txt This mail begins a WG last call on: http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-07.txt This working group last call ends on May 17th. Please send comments to the CCAMP mailing list. Deborah (and Lou) _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From zhangfatai@huawei.com Tue May 24 19:22:47 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BA2E0751 for ; Tue, 24 May 2011 19:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=-2.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpToSgvJDpHz for ; Tue, 24 May 2011 19:22:46 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0D686E067B for ; Tue, 24 May 2011 19:22:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ009XJBXNXK@szxga05-in.huawei.com> for pce@ietf.org; Wed, 25 May 2011 10:22:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00EE4BXMPS@szxga05-in.huawei.com> for pce@ietf.org; Wed, 25 May 2011 10:22:34 +0800 (CST) Received: from z41162a ([10.70.76.157]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLQ00A16BXKPV@szxml04-in.huawei.com> for pce@ietf.org; Wed, 25 May 2011 10:22:34 +0800 (CST) Date: Wed, 25 May 2011 10:22:32 +0800 From: Fatai Zhang To: Ramon Casellas , pce@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_55kiF2t6UNhk5QRer4XNeQ)" X-Priority: 3 X-MSMail-priority: Normal References: <4DCA81F9.2080807@cttc.es> Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 02:22:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_55kiF2t6UNhk5QRer4XNeQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Ramon, If I understand you correctly, do you meant that you prefer "only the VENDOR-CONSTRAINT object" to "one extra TLV"? Thanks Fatai Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Ramon Casellas To: pce@ietf.org Sent: Wednesday, May 11, 2011 8:32 PM Subject: Re: [Pce] VENDOR-CONSTRAINT Cyril, all, First, speaking from a personal point of view, I would say that I am not a big fan of VENDOR_X extensions. I would rather like to see those constraints / TLVs etc. open for standardization. Having vendor extensions will indeed limit interoperability, e.g. having a VENDOR_CONTRAINT object with the P-bit set basically means that only that vendor (and associated "partners") can do path computation for that request ?. This is analogue to having the whole PCEP interface as proprietary defeating the standardization purpose. It may be argued that a TLV may provide finer granularity to qualify a given object, rather than some more generic, packed object, but as long as the contents are opaque I worry that the default "ignore TLV" action would not be respecting the PCC constraints. Finally, if there is an VENDOR_CONSTRAINT object, VENDOR_CONSTRAINT_TLV why not a VENDOR_ message? :) For the rest of the mail, please see inline On 11/05/2011 12:44, Margaria, Cyril (NSN - DE/Munich) wrote: Hi Fatai, Christian, PCE-ers, I think that having one extra TLV is usefull when you want to add object-specific vendor constraints and not general one, the information carried will remain the same but in another place and more accessible. In this sense, it is unfortunate that not all objects are potentially TLV containers, (e.g. we had to define GENERALIZED_BANDWIDTH due to this) so only objects that are actually defined by RFC5440 as "containers" could have "vendor extensions" as TLVs. There is no way to add a VENDOR TLV to the bandwidth object, for example Having a generic vendor specific object seems a catch-all solution that is likely to include any vendor private information and might leave too much room for private information. Agreed. Another possible angle to carry vendor-specific constraint is not to have a generic object but rather a set of very specifically scoped TLVs or sub-objects. To some extent, yes, but then we shift the problem elsewhere. First, I am not sure if the standard way to proceed when a proprietary (unknown) TLV is found in an object (RFC 5440 $7.1, "Unrecognized TLVs MUST be ignored") would be the best thing to do. Without that vendor-specific information I am not sure if the resulting path is ignoring some MUST-USE TLV. However, at least, I know what object is "extended with vendor information" by virtue of being a TLV of that object. This can be applied to the PCEP as follow : - Objective function : private OF code is already defined, an private_of_parameter_tlv (only valid inside the OF object) would carry possible operator-specific parameters - Metric : a private metric type can be defined, with vendors specific body and metric value. Being nitpicking here .-) , but contrary to OF, metric types are assigned by IETF review process. Nothing precludes defining a private range but afaik it is not the case now. - For GMPLS endpoint constraint a TLV for vendor-private label constraint (valid for endpoints and label_set only for instance) can be defined. - For WSON-specifics this is for example covered in draft-lee-pce-wson-rwa-ext-01, which reuse the private ranges encoding from draft-ietf-ccamp-wson-signaling-01 I would be less against the proliferation of vendor TLVs if there is a clear "consensus" that those TLVs are only meaningful in the context of "private" ranges as Cyril examples. In other words, if the OF object with a code in the range 32768- has vendor TLVs I am fine. If I can't apply that OF code I don't care about the TLVs, and the processing rules for OF objects are standard and clear. For sure it's possible to put all those in one object, but I am not sure it's the best strategy in order to avoid all private extensions. Honestly, thinking that discussing whether private extensions either in objects or in TLVs would lead us to a best strategy in order to avoid private extensions seems weird :-) That said, "less of two evils"? the TLVs seem more granular, provide some information of what object they qualify, the processing rules are clear leading to "ignore the TLV", (it is important to note that I understand that an object that a PCE can "process" with P-bit set but with unknown TLVs does not imply the request being rejected) but not all object support TLVs. Best regards Ramon ------------------------------------------------------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce --Boundary_(ID_55kiF2t6UNhk5QRer4XNeQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC42MDgyIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSB0ZXh0PSMwMDAw MDAgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDA4 MD5IaSBSYW1vbiw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0j MDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9y PSMwMDAwODA+SWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHksIGRvIHlvdSANCm1lYW50IHRo YXQgeW91IHByZWZlciAib25seSB0aGUmbmJzcDtWRU5ET1ItQ09OU1RSQUlOVCBvYmplY3QiIHRv ICJvbmUgZXh0cmEgDQpUTFYiPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMDgwPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUNhbGlicmkgDQpjb2xvcj0jMDAwMDgwPjwvRk9OVD48QlI+VGhhbmtz PEJSPiZuYnNwOzxCUj5GYXRhaTxCUj4mbmJzcDs8QlI+SHVhd2VpIA0KVGVjaG5vbG9naWVzIENv LiwgTFRELjxCUj5IdWF3ZWkgQmFzZSwgQmFudGlhbiwgTG9uZ2dhbmcsPEJSPlNoZW56aGVuIDUx ODEyOSANClAuUi5DaGluYTxCUj5UZWw6ICs4Ni03NTUtMjg5NzI5MTI8QlI+RmF4OiArODYtNzU1 LTI4OTcyOTM1PEJSPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDog MHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMw MDAwODAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElW Pg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9cmFt b24uY2FzZWxsYXNAY3R0Yy5lcyBocmVmPSJtYWlsdG86cmFtb24uY2FzZWxsYXNAY3R0Yy5lcyI+ UmFtb24gDQogIENhc2VsbGFzPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYj MjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9cGNlQGlldGYub3JnIA0KICBocmVm PSJtYWlsdG86cGNlQGlldGYub3JnIj5wY2VAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwg TWF5IDExLCAyMDExIDg6MzIgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSZTogW1BjZV0gVkVORE9SLUNPTlNUUkFJTlQ8 L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+Q3lyaWwsIGFsbCwgPEJSPjxCUj48QlI+Rmlyc3QsIHNw ZWFraW5nIGZyb20gYSBwZXJzb25hbCBwb2ludCANCiAgb2YgdmlldywgSSB3b3VsZCBzYXkgdGhh dCBJIGFtIG5vdCBhIGJpZyBmYW4gb2YgVkVORE9SX1ggZXh0ZW5zaW9ucy4gSSB3b3VsZCANCiAg cmF0aGVyIGxpa2UgdG8gc2VlIHRob3NlIGNvbnN0cmFpbnRzIC8gVExWcyBldGMuIG9wZW4gZm9y IHN0YW5kYXJkaXphdGlvbi4gDQogIDxCUj48QlI+SGF2aW5nIHZlbmRvciBleHRlbnNpb25zIHdp bGwgaW5kZWVkIGxpbWl0IGludGVyb3BlcmFiaWxpdHksIGUuZy4gDQogIGhhdmluZyBhIFZFTkRP Ul9DT05UUkFJTlQgb2JqZWN0IHdpdGggdGhlIFAtYml0IHNldCBiYXNpY2FsbHkgbWVhbnMgdGhh dCBvbmx5IA0KICB0aGF0IHZlbmRvciAoYW5kIGFzc29jaWF0ZWQgInBhcnRuZXJzIikgY2FuIGRv IHBhdGggY29tcHV0YXRpb24gZm9yIHRoYXQgDQogIHJlcXVlc3QgPy4gVGhpcyBpcyBhbmFsb2d1 ZSB0byBoYXZpbmcgdGhlIHdob2xlIFBDRVAgaW50ZXJmYWNlIGFzIHByb3ByaWV0YXJ5IA0KICBk ZWZlYXRpbmcgdGhlIHN0YW5kYXJkaXphdGlvbiBwdXJwb3NlLjxCUj48QlI+SXQgbWF5IGJlIGFy Z3VlZCB0aGF0IGEgVExWIG1heSANCiAgcHJvdmlkZSBmaW5lciBncmFudWxhcml0eSB0byBxdWFs aWZ5IGEgZ2l2ZW4gb2JqZWN0LCByYXRoZXIgdGhhbiBzb21lIG1vcmUgDQogIGdlbmVyaWMsIHBh Y2tlZCBvYmplY3QsIGJ1dCBhcyBsb25nIGFzIHRoZSBjb250ZW50cyBhcmUgb3BhcXVlIEkgd29y cnkgdGhhdCANCiAgdGhlIGRlZmF1bHQgImlnbm9yZSBUTFYiIGFjdGlvbiB3b3VsZCBub3QgYmUg cmVzcGVjdGluZyB0aGUgUENDIA0KICBjb25zdHJhaW50cy48QlI+PEJSPiZsdDtzYXJjYXN0aWMm Z3Q7IEZpbmFsbHksIGlmIHRoZXJlIGlzIGFuIA0KICBWRU5ET1JfQ09OU1RSQUlOVCBvYmplY3Qs IFZFTkRPUl9DT05TVFJBSU5UX1RMViB3aHkgbm90IGEgVkVORE9SXyBtZXNzYWdlPyA6KSANCiAg Jmx0Oy9zYXJjYXN0aWMmZ3Q7PEJSPjxCUj48QlI+Rm9yIHRoZSByZXN0IG9mIHRoZSBtYWlsLCBw bGVhc2Ugc2VlIA0KICBpbmxpbmU8QlI+PEJSPjxCUj5PbiAxMS8wNS8yMDExIDEyOjQ0LCBNYXJn YXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCkgDQogIHdyb3RlOiANCiAgPEJMT0NLUVVPVEUg DQogIGNpdGU9bWlkOkQ1RUFCQzZGREFGREFBNDdCQzgwMzExNEM2OEFBQkYyMDI1NjIwOTJAREVN VUVYQzAxMi5uc24taW50cmEubmV0IA0KICB0eXBlPSJjaXRlIj4NCiAgICA8TUVUQSBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQmIzEzOyYjMTA7ICAgICAgICBtZWRpdW0pIiAN CiAgICBuYW1lPUdlbmVyYXRvcj4NCiAgICA8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9udC1mYW1p bHk6IENhbGlicmk7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVGFob21hOw0KfQ0K QHBhZ2UgV29yZFNlY3Rpb24xIHtzaXplOiA2MTIuMHB0IDc5Mi4wcHQ7IG1hcmdpbjogNzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0OyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0 OyBNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIg0KfQ0KTEkuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiDQp9DQpESVYuTXNv Tm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFN SUxZOiAiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0K U1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogcHVy cGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0eWxlLXByaW9yaXR5OiA5OQ0K fQ0KU1BBTi5Nc29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNP UkFUSU9OOiB1bmRlcmxpbmU7IG1zby1zdHlsZS1wcmlvcml0eTogOTkNCn0NClNQQU4uRW1haWxT dHlsZTE3IHsNCglDT0xPUjogIzFmNDk3ZDsgRk9OVC1GQU1JTFk6ICJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7IG1zby1zdHlsZS10eXBlOiBwZXJzb25hbC1yZXBseQ0KfQ0KLk1zb0NocERlZmF1bHQg ew0KCUZPTlQtU0laRTogMTBwdDsgbXNvLXN0eWxlLXR5cGU6IGV4cG9ydC1vbmx5DQp9DQpESVYu V29yZFNlY3Rpb24xIHsNCglwYWdlOiBXb3JkU2VjdGlvbjENCn0NCjwvU1RZTEU+DQo8IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KICAgIDxESVYgY2xhc3M9 V29yZFNlY3Rpb24xPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtRkFNSUxZOiAnQ2Fs aWJyaScsJ3NhbnMtc2VyaWYnIj48TzpQPjwvTzpQPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxTUEFOIGxhbmc9RlIgDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09M T1I6IHJnYigzMSw3MywxMjUpOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+ SGkgDQogICAgRmF0YWksIENocmlzdGlhbiwgUENFLWVycywgPE86UD48L086UD48L1NQQU4+PC9Q Pg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUZSIA0KICAgIHN0eWxlPSJGT05U LVNJWkU6IDExcHQ7IENPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJp Jywnc2Fucy1zZXJpZiciPjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6IHJnYigzMSw3 MywxMjUpOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+SSANCiAgICB0aGlu ayB0aGF0IGhhdmluZyBvbmUgZXh0cmEgVExWIGlzIHVzZWZ1bGwmbmJzcDsgd2hlbiB5b3Ugd2Fu dCB0byBhZGQgDQogICAgb2JqZWN0LXNwZWNpZmljIHZlbmRvciBjb25zdHJhaW50cyBhbmQgbm90 IGdlbmVyYWwgb25lLCB0aGUgaW5mb3JtYXRpb24gDQogICAgY2FycmllZCB3aWxsIHJlbWFpbiB0 aGUgc2FtZSBidXQgaW4gYW5vdGhlciBwbGFjZSBhbmQgbW9yZSANCiAgICBhY2Nlc3NpYmxlLjxP OlA+PC9POlA+PC9TUEFOPjwvUD48L0RJVj48L0JMT0NLUVVPVEU+PEJSPkluIHRoaXMgc2Vuc2Us IGl0IGlzIA0KICB1bmZvcnR1bmF0ZSB0aGF0IG5vdCBhbGwgb2JqZWN0cyBhcmUgcG90ZW50aWFs bHkgVExWIGNvbnRhaW5lcnMsIChlLmcuIHdlIGhhZCANCiAgdG8gZGVmaW5lIEdFTkVSQUxJWkVE X0JBTkRXSURUSCBkdWUgdG8gdGhpcykgc28gb25seSBvYmplY3RzIHRoYXQgYXJlIGFjdHVhbGx5 IA0KICBkZWZpbmVkIGJ5IFJGQzU0NDAgYXMgImNvbnRhaW5lcnMiIGNvdWxkIGhhdmUgInZlbmRv ciBleHRlbnNpb25zIiBhcyBUTFZzLiANCiAgVGhlcmUgaXMgbm8gd2F5IHRvIGFkZCBhIFZFTkRP UiBUTFYgdG8gdGhlIGJhbmR3aWR0aCBvYmplY3QsIGZvciANCiAgZXhhbXBsZTxCUj48QlI+PEJS Pg0KICA8QkxPQ0tRVU9URSANCiAgY2l0ZT1taWQ6RDVFQUJDNkZEQUZEQUE0N0JDODAzMTE0QzY4 QUFCRjIwMjU2MjA5MkBERU1VRVhDMDEyLm5zbi1pbnRyYS5uZXQgDQogIHR5cGU9ImNpdGUiPg0K ICAgIDxESVYgY2xhc3M9V29yZFNlY3Rpb24xPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BB TiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZP TlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj48TzpQPjwvTzpQPjwvU1BBTj48L1A+ DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEx cHQ7IENPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1z ZXJpZiciPkhhdmluZyANCiAgICBhIGdlbmVyaWMgdmVuZG9yIHNwZWNpZmljIG9iamVjdCBzZWVt cyBhIGNhdGNoLWFsbCBzb2x1dGlvbiB0aGF0IGlzIGxpa2VseSANCiAgICB0byAmbmJzcDtpbmNs dWRlIGFueSB2ZW5kb3IgcHJpdmF0ZSBpbmZvcm1hdGlvbiBhbmQgbWlnaHQgJm5ic3A7bGVhdmUg dG9vIA0KICAgIG11Y2ggcm9vbSBmb3IgcHJpdmF0ZSANCiAgaW5mb3JtYXRpb24uPC9TUEFOPjwv UD48L0RJVj48L0JMT0NLUVVPVEU+QWdyZWVkLjxCUj48QlI+PEJSPg0KICA8QkxPQ0tRVU9URSAN CiAgY2l0ZT1taWQ6RDVFQUJDNkZEQUZEQUE0N0JDODAzMTE0QzY4QUFCRjIwMjU2MjA5MkBERU1V RVhDMDEyLm5zbi1pbnRyYS5uZXQgDQogIHR5cGU9ImNpdGUiPg0KICAgIDxESVYgY2xhc3M9V29y ZFNlY3Rpb24xPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMXB0OyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnIj48TzpQPjwvTzpQPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiByZ2IoMzEs NzMsMTI1KTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPkFub3RoZXIgDQog ICAgcG9zc2libGUgYW5nbGUgdG8gY2FycnkgdmVuZG9yLXNwZWNpZmljIGNvbnN0cmFpbnQgaXMg bm90IHRvIGhhdmUgYSBnZW5lcmljIA0KICAgIG9iamVjdCBidXQgcmF0aGVyIGEgc2V0IG9mIHZl cnkgc3BlY2lmaWNhbGx5IHNjb3BlZCBUTFZzIG9yIA0KICAgIHN1Yi1vYmplY3RzLjxPOlA+PC9P OlA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9 IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6IHJnYigzMSw3MywxMjUpOyBGT05ULUZBTUlMWTogJ0Nh bGlicmknLCdzYW5zLXNlcmlmJyI+PE86UD48L086UD48L1NQQU4+PC9QPjwvRElWPjwvQkxPQ0tR VU9URT5UbyANCiAgc29tZSBleHRlbnQsIHllcywgYnV0IHRoZW4gd2Ugc2hpZnQgdGhlIHByb2Js ZW0gZWxzZXdoZXJlLiBGaXJzdCwgSSBhbSBub3QgDQogIHN1cmUgaWYgdGhlIHN0YW5kYXJkIHdh eSB0byBwcm9jZWVkIHdoZW4gYSBwcm9wcmlldGFyeSAodW5rbm93bikgVExWIGlzIGZvdW5kIA0K ICBpbiBhbiBvYmplY3QgKFJGQyA1NDQwICQ3LjEsJm5ic3A7ICJVbnJlY29nbml6ZWQgVExWcyBN VVNUIGJlIGlnbm9yZWQiKSB3b3VsZCANCiAgYmUgdGhlIGJlc3QgdGhpbmcgdG8gZG8uIDxCUj5X aXRob3V0IHRoYXQgdmVuZG9yLXNwZWNpZmljIGluZm9ybWF0aW9uIEkgYW0gbm90IA0KICBzdXJl IGlmIHRoZSByZXN1bHRpbmcgcGF0aCBpcyBpZ25vcmluZyBzb21lIE1VU1QtVVNFIFRMVi4gSG93 ZXZlciwgYXQgbGVhc3QsIEkgDQogIGtub3cgd2hhdCBvYmplY3QgaXMgImV4dGVuZGVkIHdpdGgg dmVuZG9yIGluZm9ybWF0aW9uIiBieSB2aXJ0dWUgb2YgYmVpbmcgYSANCiAgVExWIG9mIHRoYXQg b2JqZWN0LjxCUj48QlI+PEJSPjxCUj4NCiAgPEJMT0NLUVVPVEUgDQogIGNpdGU9bWlkOkQ1RUFC QzZGREFGREFBNDdCQzgwMzExNEM2OEFBQkYyMDI1NjIwOTJAREVNVUVYQzAxMi5uc24taW50cmEu bmV0IA0KICB0eXBlPSJjaXRlIj4NCiAgICA8RElWIGNsYXNzPVdvcmRTZWN0aW9uMT4NCiAgICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09M T1I6IHJnYigzMSw3MywxMjUpOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+ VGhpcyANCiAgICBjYW4gYmUgYXBwbGllZCB0byB0aGUgUENFUCBhcyBmb2xsb3cgOjxPOlA+PC9P OlA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9 IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6IHJnYigzMSw3MywxMjUpOyBGT05ULUZBTUlMWTogJ0Nh bGlicmknLCdzYW5zLXNlcmlmJyI+LSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICBPYmplY3RpdmUgZnVuY3Rpb24gOiBwcml2YXRlIE9G IGNvZGUgaXMgYWxyZWFkeSBkZWZpbmVkLCBhbiANCiAgICBwcml2YXRlX29mX3BhcmFtZXRlcl90 bHYgKG9ubHkgdmFsaWQgaW5zaWRlIHRoZSBPRiBvYmplY3QpIHdvdWxkIGNhcnJ5IA0KICAgIHBv c3NpYmxlIG9wZXJhdG9yLXNwZWNpZmljIHBhcmFtZXRlcnM8TzpQPjwvTzpQPjwvU1BBTj48L1A+ DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEx cHQ7IENPTE9SOiByZ2IoMzEsNzMsMTI1KTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1z ZXJpZiciPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgDQogICAgTWV0cmljIDogYSBwcml2YXRlIG1ldHJpYyB0eXBlIGNhbiBiZSBkZWZpbmVk LCB3aXRoIHZlbmRvcnMgc3BlY2lmaWMgYm9keSANCiAgICBhbmQgbWV0cmljIHZhbHVlLjwvU1BB Tj48L1A+PC9ESVY+PC9CTE9DS1FVT1RFPkJlaW5nIG5pdHBpY2tpbmcgaGVyZSAuLSkgLCBidXQg DQogIGNvbnRyYXJ5IHRvIE9GLCBtZXRyaWMgdHlwZXMgYXJlIGFzc2lnbmVkIGJ5IElFVEYgcmV2 aWV3IHByb2Nlc3MuIE5vdGhpbmcgDQogIHByZWNsdWRlcyBkZWZpbmluZyBhIHByaXZhdGUgcmFu Z2UgYnV0IGFmYWlrIGl0IGlzIG5vdCB0aGUgY2FzZSBub3cuPEJSPg0KICA8QkxPQ0tRVU9URSAN CiAgY2l0ZT1taWQ6RDVFQUJDNkZEQUZEQUE0N0JDODAzMTE0QzY4QUFCRjIwMjU2MjA5MkBERU1V RVhDMDEyLm5zbi1pbnRyYS5uZXQgDQogIHR5cGU9ImNpdGUiPg0KICAgIDxESVYgY2xhc3M9V29y ZFNlY3Rpb24xPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMXB0OyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtRkFNSUxZOiAnQ2FsaWJy aScsJ3NhbnMtc2VyaWYnIj48TzpQPjwvTzpQPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiByZ2IoMzEs NzMsMTI1KTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPi0mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgRm9yIEdN UExTIGVuZHBvaW50IGNvbnN0cmFpbnQgYSBUTFYgZm9yIHZlbmRvci1wcml2YXRlIGxhYmVsIGNv bnN0cmFpbnQgDQogICAgKHZhbGlkIGZvciBlbmRwb2ludHMgYW5kIGxhYmVsX3NldCBvbmx5IGZv ciBpbnN0YW5jZSkgY2FuIGJlIA0KICAgIGRlZmluZWQuPE86UD48L086UD48L1NQQU4+PC9QPg0K ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0 OyBDT0xPUjogcmdiKDMxLDczLDEyNSk7IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2Vy aWYnIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IA0KICAgIEZvciBXU09OLXNwZWNpZmljcyB0aGlzIGlzIGZvciBleGFtcGxlIGNvdmVyZWQg aW4gDQogICAgZHJhZnQtbGVlLXBjZS13c29uLXJ3YS1leHQtMDEsIHdoaWNoIHJldXNlIHRoZSBw cml2YXRlIHJhbmdlcyBlbmNvZGluZyBmcm9tIA0KICAgIGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1z aWduYWxpbmctMDE8TzpQPjwvTzpQPjwvU1BBTj48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiByZ2IoMzEsNzMsMTI1 KTsgRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZiciPjxPOlA+PC9POlA+PC9TUEFO PjwvUD48L0RJVj48L0JMT0NLUVVPVEU+SSANCiAgd291bGQgYmUgbGVzcyBhZ2FpbnN0IHRoZSBw cm9saWZlcmF0aW9uIG9mIHZlbmRvciBUTFZzIGlmIHRoZXJlIGlzIGEgY2xlYXIgDQogICJjb25z ZW5zdXMiJm5ic3A7IHRoYXQgdGhvc2UgVExWcyBhcmUgb25seSBtZWFuaW5nZnVsIGluIHRoZSBj b250ZXh0IG9mIA0KICAicHJpdmF0ZSIgcmFuZ2VzIGFzIEN5cmlsIGV4YW1wbGVzLiBJbiBvdGhl ciB3b3JkcywgaWYgdGhlIE9GIG9iamVjdCB3aXRoIGEgDQogIGNvZGUgaW4gdGhlIHJhbmdlIDMy NzY4LSBoYXMgdmVuZG9yIFRMVnMgSSBhbSBmaW5lLiBJZiBJIGNhbid0IGFwcGx5IHRoYXQgT0Yg DQogIGNvZGUgSSBkb24ndCBjYXJlIGFib3V0IHRoZSBUTFZzLCBhbmQgdGhlIHByb2Nlc3Npbmcg cnVsZXMgZm9yIE9GIG9iamVjdHMgYXJlIA0KICBzdGFuZGFyZCBhbmQgY2xlYXIuIDxCUj48QlI+ PEJSPg0KICA8QkxPQ0tRVU9URSANCiAgY2l0ZT1taWQ6RDVFQUJDNkZEQUZEQUE0N0JDODAzMTE0 QzY4QUFCRjIwMjU2MjA5MkBERU1VRVhDMDEyLm5zbi1pbnRyYS5uZXQgDQogIHR5cGU9ImNpdGUi Pg0KICAgIDxESVYgY2xhc3M9V29yZFNlY3Rpb24xPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMXB0OyBDT0xPUjogcmdiKDMxLDczLDEyNSk7 IEZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnIj5Gb3IgDQogICAgc3VyZSBpdJJz IHBvc3NpYmxlIHRvIHB1dCBhbGwgdGhvc2UgaW4gb25lIG9iamVjdCwgYnV0IEkgYW0gbm90IHN1 cmUgaXSScyANCiAgICB0aGUgYmVzdCBzdHJhdGVneSBpbiBvcmRlciB0byBhdm9pZCBhbGwgcHJp dmF0ZSANCiAgICBleHRlbnNpb25zLjxPOlA+PC9POlA+PC9TUEFOPjwvUD4NCiAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTFwdDsgQ09MT1I6IHJn YigzMSw3MywxMjUpOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+PE86UD48 L086UD48L1NQQU4+PC9QPjwvRElWPjwvQkxPQ0tRVU9URT5Ib25lc3RseSwgDQogIHRoaW5raW5n IHRoYXQgZGlzY3Vzc2luZyB3aGV0aGVyIHByaXZhdGUgZXh0ZW5zaW9ucyBlaXRoZXIgaW4gb2Jq ZWN0cyBvciBpbiANCiAgVExWcyB3b3VsZCBsZWFkIHVzIHRvIGEgYmVzdCBzdHJhdGVneSBpbiBv cmRlciB0byBhdm9pZCBwcml2YXRlIGV4dGVuc2lvbnMgDQogIHNlZW1zIHdlaXJkIDotKSA8QlI+ PEJSPlRoYXQgc2FpZCwgImxlc3Mgb2YgdHdvIGV2aWxzIj8mbmJzcDsgdGhlIFRMVnMgc2VlbSAN CiAgbW9yZSBncmFudWxhciwgcHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIG9mIHdoYXQgb2JqZWN0 IHRoZXkgcXVhbGlmeSwgdGhlIA0KICBwcm9jZXNzaW5nIHJ1bGVzIGFyZSBjbGVhciBsZWFkaW5n IHRvICJpZ25vcmUgdGhlIFRMViIsIChpdCBpcyBpbXBvcnRhbnQgdG8gDQogIG5vdGUgdGhhdCBJ IHVuZGVyc3RhbmQgdGhhdCBhbiBvYmplY3QgdGhhdCBhIFBDRSBjYW4gInByb2Nlc3MiIHdpdGgg UC1iaXQgc2V0IA0KICBidXQgd2l0aCB1bmtub3duIFRMVnMgZG9lcyBub3QgaW1wbHkgdGhlIHJl cXVlc3QgYmVpbmcgcmVqZWN0ZWQpIGJ1dCBub3QgYWxsIA0KICBvYmplY3Qgc3VwcG9ydCBUTFZz LjxCUj48QlI+PEJSPkJlc3QgcmVnYXJkczxCUj5SYW1vbiANCiAgPFA+DQogIDxIUj4NCg0KICA8 UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ UGNlIG1haWxpbmcgDQogIGxpc3Q8QlI+UGNlQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGNlPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_55kiF2t6UNhk5QRer4XNeQ)-- From ramon.casellas@cttc.es Tue May 24 22:16:29 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71004E0699 for ; Tue, 24 May 2011 22:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyzNzp3rUqjZ for ; Tue, 24 May 2011 22:16:28 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 85D25E065B for ; Tue, 24 May 2011 22:16:28 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4P5Fx6a032054; Wed, 25 May 2011 07:16:05 +0200 Received: from [192.168.0.101] (62.83.138.129.dyn.user.ono.com [62.83.138.129]) by castor (Postfix) with ESMTP id 0FE4C2FC257; Wed, 25 May 2011 07:16:01 +0200 (CEST) Message-ID: <4DDC907B.8080906@cttc.es> Date: Wed, 25 May 2011 07:15:39 +0200 From: Ramon Casellas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fatai Zhang , pce@ietf.org References: <4DCA81F9.2080807@cttc.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030104020804080102020401" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Wed, 25 May 2011 07:16:02 +0200 (CEST) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 05:16:29 -0000 This is a multi-part message in MIME format. --------------030104020804080102020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit El 25/05/2011 4:22, Fatai Zhang escribió: > Hi Ramon, > If I understand you correctly, do you meant that you prefer "only > the VENDOR-CONSTRAINT object" to "one extra TLV"? > Hello Fatai, all, I'm afraid not (sorry for not having expressed myself clearly). In the case of vendor constraints, I think, without a strong opinion, that I would rather have vendor-specific TLVs that apply to a given object, rather than a top-level object. The reasons for this are: * It seems more granular and clearly identifies which object is constrained. Seems less opaque :) * The default behavior as current RFC is to ignore the TLV if not known/supported. This may require a flags field within the TLV to specify that the constrain was indeed processed. A good question is whether a single TLV "vendor_tlv" would do, or there is a reason to have more grained tlvs There are some drawbacks of course: * There are objects that were defined without TLVs. With a strict interpretation of rfc 5440, it would not be possible to constrain such objects. * The constraint (semantics) involved in the TLV has to somehow relate to the object it is attached to. If there is no such object, the use of TLVs seems less flexible and an object would be needed. In short, there seem to be use cases for both. Preferably, use vendor tlvs. Thank you and best regards R. --------------030104020804080102020401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit El 25/05/2011 4:22, Fatai Zhang escribió:
Hi Ramon,
 
If I understand you correctly, do you meant that you prefer "only the VENDOR-CONSTRAINT object" to "one extra TLV"?
 
Hello Fatai, all,

I'm afraid not (sorry for not having expressed myself  clearly). In the case of vendor constraints, I think, without a strong opinion, that I would rather have vendor-specific TLVs that apply to a given object, rather than a top-level object. The reasons for this are:

* It seems more granular and clearly identifies which object is constrained. Seems less opaque :)

* The default behavior as current RFC is to ignore the TLV if not known/supported. This may require a flags field within the TLV to specify that the constrain was indeed processed.

A good question is whether a single TLV "vendor_tlv" would do, or there is a reason to have more grained tlvs

There are some drawbacks of course:
* There are objects that were defined without TLVs. With a strict interpretation of rfc 5440, it would not be possible to constrain such objects.

* The constraint (semantics) involved in the TLV has to somehow relate to the object it is attached to. If there is no such object, the use of TLVs seems less flexible and an object would be needed.

In short, there seem to be use cases for both. Preferably, use vendor tlvs.

Thank you and best regards
R.
--------------030104020804080102020401-- From zhangfatai@huawei.com Tue May 24 22:55:01 2011 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EAD13000A for ; Tue, 24 May 2011 22:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-PCXuetRTdb for ; Tue, 24 May 2011 22:55:01 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C1806E07CF for ; Tue, 24 May 2011 22:55:00 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ007VLLPJZZ@szxga04-in.huawei.com> for pce@ietf.org; Wed, 25 May 2011 13:53:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ0097JLPJJ5@szxga04-in.huawei.com> for pce@ietf.org; Wed, 25 May 2011 13:53:43 +0800 (CST) Received: from z41162a ([10.70.76.157]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLQ00596LPJBX@szxml06-in.huawei.com> for pce@ietf.org; Wed, 25 May 2011 13:53:43 +0800 (CST) Date: Wed, 25 May 2011 13:53:43 +0800 From: Fatai Zhang To: Ramon Casellas , pce@ietf.org Message-id: <777041F43C184D929167F08F5B01D1BD@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_suAKuKbXMTK0xMmOz6TDzA)" X-Priority: 3 X-MSMail-priority: Normal References: <4DCA81F9.2080807@cttc.es> <4DDC907B.8080906@cttc.es> Subject: Re: [Pce] VENDOR-CONSTRAINT X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 05:55:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_suAKuKbXMTK0xMmOz6TDzA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGkgUmFtb24sDQoNCk9LLCB0aGFua3MgYSBsb3QuDQoNCkFueSBtb3JlIG9waW5pb25zIGZyb20g dGhlIFdHPw0KDQoNCg0KDQoNClRoYW5rcw0KIA0KRmF0YWkNCiANCkh1YXdlaSBUZWNobm9sb2dp ZXMgQ28uLCBMVEQuDQpIdWF3ZWkgQmFzZSwgQmFudGlhbiwgTG9uZ2dhbmcsDQpTaGVuemhlbiA1 MTgxMjkgUC5SLkNoaW5hDQpUZWw6ICs4Ni03NTUtMjg5NzI5MTINCkZheDogKzg2LTc1NS0yODk3 MjkzNQ0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IFJhbW9uIENh c2VsbGFzIA0KICBUbzogRmF0YWkgWmhhbmcgOyBwY2VAaWV0Zi5vcmcgDQogIFNlbnQ6IFdlZG5l c2RheSwgTWF5IDI1LCAyMDExIDE6MTUgUE0NCiAgU3ViamVjdDogUmU6IFtQY2VdIFZFTkRPUi1D T05TVFJBSU5UDQoNCg0KICBFbCAyNS8wNS8yMDExIDQ6MjIsIEZhdGFpIFpoYW5nIGVzY3JpYmnz OiANCiAgICBIaSBSYW1vbiwNCg0KICAgIElmIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5LCBk byB5b3UgbWVhbnQgdGhhdCB5b3UgcHJlZmVyICJvbmx5IHRoZSBWRU5ET1ItQ09OU1RSQUlOVCBv YmplY3QiIHRvICJvbmUgZXh0cmEgVExWIj8NCg0KDQogIEhlbGxvIEZhdGFpLCBhbGwsDQoNCiAg SSdtIGFmcmFpZCBub3QgKHNvcnJ5IGZvciBub3QgaGF2aW5nIGV4cHJlc3NlZCBteXNlbGYgIGNs ZWFybHkpLiBJbiB0aGUgY2FzZSBvZiB2ZW5kb3IgY29uc3RyYWludHMsIEkgdGhpbmssIHdpdGhv dXQgYSBzdHJvbmcgb3BpbmlvbiwgdGhhdCBJIHdvdWxkIHJhdGhlciBoYXZlIHZlbmRvci1zcGVj aWZpYyBUTFZzIHRoYXQgYXBwbHkgdG8gYSBnaXZlbiBvYmplY3QsIHJhdGhlciB0aGFuIGEgdG9w LWxldmVsIG9iamVjdC4gVGhlIHJlYXNvbnMgZm9yIHRoaXMgYXJlOg0KDQogICogSXQgc2VlbXMg bW9yZSBncmFudWxhciBhbmQgY2xlYXJseSBpZGVudGlmaWVzIHdoaWNoIG9iamVjdCBpcyBjb25z dHJhaW5lZC4gU2VlbXMgbGVzcyBvcGFxdWUgOikNCg0KICAqIFRoZSBkZWZhdWx0IGJlaGF2aW9y IGFzIGN1cnJlbnQgUkZDIGlzIHRvIGlnbm9yZSB0aGUgVExWIGlmIG5vdCBrbm93bi9zdXBwb3J0 ZWQuIFRoaXMgbWF5IHJlcXVpcmUgYSBmbGFncyBmaWVsZCB3aXRoaW4gdGhlIFRMViB0byBzcGVj aWZ5IHRoYXQgdGhlIGNvbnN0cmFpbiB3YXMgaW5kZWVkIHByb2Nlc3NlZC4NCg0KICBBIGdvb2Qg cXVlc3Rpb24gaXMgd2hldGhlciBhIHNpbmdsZSBUTFYgInZlbmRvcl90bHYiIHdvdWxkIGRvLCBv ciB0aGVyZSBpcyBhIHJlYXNvbiB0byBoYXZlIG1vcmUgZ3JhaW5lZCB0bHZzIA0KDQogIFRoZXJl IGFyZSBzb21lIGRyYXdiYWNrcyBvZiBjb3Vyc2U6DQogICogVGhlcmUgYXJlIG9iamVjdHMgdGhh dCB3ZXJlIGRlZmluZWQgd2l0aG91dCBUTFZzLiBXaXRoIGEgc3RyaWN0IGludGVycHJldGF0aW9u IG9mIHJmYyA1NDQwLCBpdCB3b3VsZCBub3QgYmUgcG9zc2libGUgdG8gY29uc3RyYWluIHN1Y2gg b2JqZWN0cy4NCg0KICAqIFRoZSBjb25zdHJhaW50IChzZW1hbnRpY3MpIGludm9sdmVkIGluIHRo ZSBUTFYgaGFzIHRvIHNvbWVob3cgcmVsYXRlIHRvIHRoZSBvYmplY3QgaXQgaXMgYXR0YWNoZWQg dG8uIElmIHRoZXJlIGlzIG5vIHN1Y2ggb2JqZWN0LCB0aGUgdXNlIG9mIFRMVnMgc2VlbXMgbGVz cyBmbGV4aWJsZSBhbmQgYW4gb2JqZWN0IHdvdWxkIGJlIG5lZWRlZC4NCg0KICBJbiBzaG9ydCwg dGhlcmUgc2VlbSB0byBiZSB1c2UgY2FzZXMgZm9yIGJvdGguIFByZWZlcmFibHksIHVzZSB2ZW5k b3IgdGx2cy4gDQoNCiAgVGhhbmsgeW91IGFuZCBiZXN0IHJlZ2FyZHMNCiAgUi4gDQo= --Boundary_(ID_suAKuKbXMTK0xMmOz6TDzA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEg Y29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC42MDgyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48 L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxE SVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAwODA+SGkgUmFtb24sPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDA4MD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMDgwPk9LLCB0aGFua3MgYSBs b3QuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNhbGlicmkgY29sb3I9IzAwMDA4MD48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMDgw PkFueSBtb3JlIG9waW5pb25zIGZyb20gdGhlIA0KV0c/PC9GT05UPjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAwODA+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1DYWxpYnJpIGNv bG9yPSMwMDAwODA+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48QlI+VGhhbmtzPEJSPiZuYnNw OzxCUj5GYXRhaTxCUj4mbmJzcDs8QlI+SHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIA0KTFRELjxC Uj5IdWF3ZWkgQmFzZSwgQmFudGlhbiwgTG9uZ2dhbmcsPEJSPlNoZW56aGVuIDUxODEyOSBQLlIu Q2hpbmE8QlI+VGVsOiANCis4Ni03NTUtMjg5NzI5MTI8QlI+RmF4OiArODYtNzU1LTI4OTcyOTM1 PEJSPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURE SU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwODAgMnB4 IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIz NDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElW IHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3Ozsg Zm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9cmFtb24uY2FzZWxs YXNAY3R0Yy5lcyBocmVmPSJtYWlsdG86cmFtb24uY2FzZWxsYXNAY3R0Yy5lcyI+UmFtb24gDQog IENhc2VsbGFzPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMy MDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9emhhbmdmYXRhaUBodWF3ZWkuY29tIA0KICBocmVm PSJtYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tIj5GYXRhaSBaaGFuZzwvQT4gOyA8QSB0aXRs ZT1wY2VAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpwY2VAaWV0Zi5vcmciPnBjZUBpZXRmLm9y ZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48 Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBNYXkgMjUsIDIwMTEgMToxNSBQTTwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBb UGNlXSBWRU5ET1ItQ09OU1RSQUlOVDwvRElWPg0KICA8RElWPjxCUj48L0RJVj5FbCAyNS8wNS8y MDExIDQ6MjIsIEZhdGFpIFpoYW5nIGVzY3JpYmnzOiANCiAgPEJMT0NLUVVPVEUgY2l0ZT1taWQ6 QTIwQUIwRUI3M0U1NDA2RDk5OUYxQjVCOTAzMUVERjdAY2hpbmEuaHVhd2VpLmNvbSANCiAgdHlw ZT0iY2l0ZSI+DQogICAgPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC42MDgyIiBuYW1l PUdFTkVSQVRPUj4NCiAgICA8RElWPjxGT05UIGZhY2U9Q2FsaWJyaSBjb2xvcj0jMDAwMDgwPkhp IFJhbW9uLDwvRk9OVD48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PEZP TlQgZmFjZT1DYWxpYnJpIGNvbG9yPSMwMDAwODA+SWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0 bHksIGRvIHlvdSANCiAgICBtZWFudCB0aGF0IHlvdSBwcmVmZXIgIm9ubHkgdGhlJm5ic3A7VkVO RE9SLUNPTlNUUkFJTlQgb2JqZWN0IiB0byAib25lIGV4dHJhIA0KICAgIFRMViI/PC9GT05UPjwv RElWPg0KICAgIDxESVY+PEJSPiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT5IZWxsbyBGYXRhaSwg YWxsLDxCUj48QlI+SSdtIGFmcmFpZCBub3QgDQogIChzb3JyeSBmb3Igbm90IGhhdmluZyBleHBy ZXNzZWQgbXlzZWxmJm5ic3A7IGNsZWFybHkpLiBJbiB0aGUgY2FzZSBvZiB2ZW5kb3IgDQogIGNv bnN0cmFpbnRzLCBJIHRoaW5rLCB3aXRob3V0IGEgc3Ryb25nIG9waW5pb24sIHRoYXQgSSB3b3Vs ZCByYXRoZXIgaGF2ZSANCiAgdmVuZG9yLXNwZWNpZmljIFRMVnMgdGhhdCBhcHBseSB0byBhIGdp dmVuIG9iamVjdCwgcmF0aGVyIHRoYW4gYSB0b3AtbGV2ZWwgDQogIG9iamVjdC4gVGhlIHJlYXNv bnMgZm9yIHRoaXMgYXJlOjxCUj48QlI+KiBJdCBzZWVtcyBtb3JlIGdyYW51bGFyIGFuZCBjbGVh cmx5IA0KICBpZGVudGlmaWVzIHdoaWNoIG9iamVjdCBpcyBjb25zdHJhaW5lZC4gU2VlbXMgbGVz cyBvcGFxdWUgOik8QlI+PEJSPiogVGhlIA0KICBkZWZhdWx0IGJlaGF2aW9yIGFzIGN1cnJlbnQg UkZDIGlzIHRvIGlnbm9yZSB0aGUgVExWIGlmIG5vdCBrbm93bi9zdXBwb3J0ZWQuIA0KICBUaGlz IG1heSByZXF1aXJlIGEgZmxhZ3MgZmllbGQgd2l0aGluIHRoZSBUTFYgdG8gc3BlY2lmeSB0aGF0 IHRoZSBjb25zdHJhaW4gDQogIHdhcyBpbmRlZWQgcHJvY2Vzc2VkLjxCUj48QlI+QSBnb29kIHF1 ZXN0aW9uIGlzIHdoZXRoZXIgYSBzaW5nbGUgVExWIA0KICAidmVuZG9yX3RsdiIgd291bGQgZG8s IG9yIHRoZXJlIGlzIGEgcmVhc29uIHRvIGhhdmUgbW9yZSBncmFpbmVkIHRsdnMgDQogIDxCUj48 QlI+VGhlcmUgYXJlIHNvbWUgZHJhd2JhY2tzIG9mIGNvdXJzZTo8QlI+KiBUaGVyZSBhcmUgb2Jq ZWN0cyB0aGF0IHdlcmUgDQogIGRlZmluZWQgd2l0aG91dCBUTFZzLiBXaXRoIGEgc3RyaWN0IGlu dGVycHJldGF0aW9uIG9mIHJmYyA1NDQwLCBpdCB3b3VsZCBub3QgDQogIGJlIHBvc3NpYmxlIHRv IGNvbnN0cmFpbiBzdWNoIG9iamVjdHMuPEJSPjxCUj4qIFRoZSBjb25zdHJhaW50IChzZW1hbnRp Y3MpIA0KICBpbnZvbHZlZCBpbiB0aGUgVExWIGhhcyB0byBzb21laG93IHJlbGF0ZSB0byB0aGUg b2JqZWN0IGl0IGlzIGF0dGFjaGVkIHRvLiBJZiANCiAgdGhlcmUgaXMgbm8gc3VjaCBvYmplY3Qs IHRoZSB1c2Ugb2YgVExWcyBzZWVtcyBsZXNzIGZsZXhpYmxlIGFuZCBhbiBvYmplY3QgDQogIHdv dWxkIGJlIG5lZWRlZC48QlI+PEJSPkluIHNob3J0LCB0aGVyZSBzZWVtIHRvIGJlIHVzZSBjYXNl cyBmb3IgYm90aC4gDQogIFByZWZlcmFibHksIHVzZSB2ZW5kb3IgdGx2cy4gPEJSPjxCUj5UaGFu ayB5b3UgYW5kIGJlc3QgcmVnYXJkczxCUj5SLiANCjxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwv SFRNTD4NCg== --Boundary_(ID_suAKuKbXMTK0xMmOz6TDzA)--