From nobody Sun Mar 1 07:39:35 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ABC1B2F4D; Sun, 1 Mar 2015 07:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TvUpx8EsYzV; Sun, 1 Mar 2015 07:39:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8D31B2F45; Sun, 1 Mar 2015 07:39:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150301153931.1309.3088.idtracker@ietfa.amsl.com> Date: Sun, 01 Mar 2015 07:39:31 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-p2mp-loose-path-reopt-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 15:39:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to Resource Reservation Protocol For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs Authors : Tarek Saad Rakesh Gandhi Zafar Ali Robert H. Venator Yuji Kamite Filename : draft-ietf-teas-p2mp-loose-path-reopt-01.txt Pages : 16 Date : 2015-03-01 Abstract: For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP), it is preferable in some cases to re-evaluate and re-optimize the entire P2MP-TE LSP by re-signaling all its Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism for an ingress Label Switched Router (LSR) to trigger a new path re- evaluation request and a mechanism for a mid-point LSR to notify an availability of a preferred path, operate on an individual or a sub- group of S2L sub-LSP(s) basis only. This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the entire LSP tree containing one or more S2L sub-LSPs whose paths are loose (or abstract) hop expanded, and for a mid-point LSR to notify to the ingress node that a preferable tree exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to signal one or more S2L sub-LSPs in an RSVP message. This document defines markers to indicate beginning and end of an S2L sub-LSP descriptor list when the RSVP message needs to be fragmented due to large number of S2L sub-LSPs in the message when performing sub-group based re- optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-p2mp-loose-path-reopt-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 1 07:51:52 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBAC1B3E74 for ; Sun, 1 Mar 2015 07:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byKqmzX-nGoZ for ; Sun, 1 Mar 2015 07:51:49 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6141B1B3E69 for ; Sun, 1 Mar 2015 07:51:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2675; q=dns/txt; s=iport; t=1425225109; x=1426434709; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SvwMZc+SLP9i/QmvKWn5nVyxpqkX6WyDDS0JDnShEXQ=; b=T0J6BjSb4GKqL7YSmQ3O/wnarFkqFkjrCyzXa6h+KgxAWmFxfB0mu0HU OQ3fMKPQM//dFTxqCyJZiL+SfOMN97s2dZSJoA4BveZEV47JsJUyhmX/Q HAPDPfTAsugDLtRRAZa4CgyJvWIhUrA1tcthFBsGUXIVPABk7fvPsP2Dc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiBQA1NfNU/4UNJK1agwJSVQnBGIVuAoESTQEBAQEBAXyEEAIEOj0CEgEINkIlAgQOBQmIJggF1FEBAQEBAQEBAwEBAQEBAQEBARmLEoQ7MweEKwWPeINghWeBGjmCZ4tigz4jggIcgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,671,1418083200"; d="scan'208";a="127933945" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 01 Mar 2015 15:51:48 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t21FplE4017542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Mar 2015 15:51:47 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Sun, 1 Mar 2015 09:51:47 -0600 From: "Rakesh Gandhi (rgandhi)" To: "teas@ietf.org" Thread-Topic: New Version Notification for draft-ietf-teas-p2mp-loose-path-reopt-01.txt Thread-Index: AQHQVDXs8POTB1qnQE2MjTO4SavL6J0H15GA Date: Sun, 1 Mar 2015 15:51:46 +0000 Message-ID: In-Reply-To: <20150301153931.1309.33560.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.246.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <1AE4283F84EFFE4AA2D1A7FD36F1E421@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Zafar Ali \(zali\)" , Yuji Kamite , "Tarek Saad \(tsaad\)" , "Robert H. Venator" Subject: Re: [Teas] New Version Notification for draft-ietf-teas-p2mp-loose-path-reopt-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2015 15:51:51 -0000 Hi WG, This version contains editorial changes/cleanup and no procedure/functionality has been changed. Welcome your review comments and suggestions. Thanks, Rakesh =20 On 2015-03-01 10:39 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-teas-p2mp-loose-path-reopt-01.txt >has been successfully submitted by Rakesh Gandhi and posted to the >IETF repository. > >Name: draft-ietf-teas-p2mp-loose-path-reopt >Revision: 01 >Title: Extensions to Resource Reservation Protocol For Re-optimization >of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs >Document date: 2015-03-01 >Group: teas >Pages: 16 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-teas-p2mp-loose-path-reopt- >01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-p2mp-loose-path-reopt-0= 1 > >Abstract: > For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label > Switched Path (LSP), it is preferable in some cases to re-evaluate > and re-optimize the entire P2MP-TE LSP by re-signaling all its > Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism > for an ingress Label Switched Router (LSR) to trigger a new path re- > evaluation request and a mechanism for a mid-point LSR to notify an > availability of a preferred path, operate on an individual or a sub- > group of S2L sub-LSP(s) basis only. > > This document defines RSVP-TE signaling extensions to allow an > ingress node of a P2MP-TE LSP to request the re-evaluation of the > entire LSP tree containing one or more S2L sub-LSPs whose paths are > loose (or abstract) hop expanded, and for a mid-point LSR to notify > to the ingress node that a preferable tree exists for the entire > P2MP-TE LSP. For re-optimizing a group of S2L sub-LSP(s) in a tree, > an S2L sub-LSP descriptor list can be used to signal one or more S2L > sub-LSPs in an RSVP message. This document defines markers to > indicate beginning and end of an S2L sub-LSP descriptor list when the > RSVP message needs to be fragmented due to large number of S2L > sub-LSPs in the message when performing sub-group based re- > optimization. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Sun Mar 1 20:16:24 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3411B1A000E; Sun, 1 Mar 2015 20:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdOzK2ekxd8G; Sun, 1 Mar 2015 20:16:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB53D1A0052; Sun, 1 Mar 2015 20:16:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150302041621.11480.92524.idtracker@ietfa.amsl.com> Date: Sun, 01 Mar 2015 20:16:21 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-attribute-ro-03.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 04:16:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : LSP Attribute in ERO Authors : Cyril Margaria Giovanni Martinelli Steve Balls Ben Wright Filename : draft-ietf-teas-lsp-attribute-ro-03.txt Pages : 13 Date : 2015-03-01 Abstract: RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of an Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) objects to allow it to specify or record generic attributes which apply to a given hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 2 08:49:52 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECF91A0143; Mon, 2 Mar 2015 08:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjF5NApdbhKT; Mon, 2 Mar 2015 08:49:49 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4A51A1A22; Mon, 2 Mar 2015 08:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2362; q=dns/txt; s=iport; t=1425314989; x=1426524589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+Qb0hKR268jckjOn/fw+5ntQu88khxdjavK7L0Hl1/g=; b=cqm3lahF79RtAW1/tfsLP06U2g/ROoUgPUcsuiimPvQgo9btYUpoqCy5 +WHuvQXsntoFzV21uVknmtKMvnSbOY9wnLHv/Y0GlUB7EjCH1hdlK6UAk kqcqylM1EdrLOQMK2UkoaDhcrxRD2PbxsTXJor9zAmil/Eg9HhKa+TJTB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5BgDSk/RU/xbLJq1ahDKDBrhBiRqCTgIcgVUBAQEBAQF8hA8BAQEDASMRRQULAgEIDgwCBiACAgIwFRACBAENDYgfCLx8mSgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJcYQ9FhsHgmgvgRQBBI94imGDIItigz4jg26BcQQ+fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,676,1418083200"; d="scan'208";a="366223043" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 02 Mar 2015 16:49:47 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t22Gnjj2026153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Mar 2015 16:49:46 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.147]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 2 Mar 2015 10:49:45 -0600 From: "Matt Hartley (mhartley)" To: Lou Berger , TEAS WG Thread-Topic: IETF 92 TEAS agenda requests Thread-Index: AQHQThFhpzXUe2vv/Ey7ZkBfm/Awyp0JdYug Date: Mon, 2 Mar 2015 16:49:44 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29B8FD5B@xmb-rcd-x03.cisco.com> References: <54E8E462.2070200@labn.net> In-Reply-To: <54E8E462.2070200@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" Subject: Re: [Teas] IETF 92 TEAS agenda requests X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:49:51 -0000 QSByZW1pbmRlciBvbiB0aGlzLi4uDQoNCkNoZWVycw0KDQpNYXR0DQoNCj4gRGVhciBURUFTLA0K PiANCj4gVGhlIElFVEY5MiBkcmFmdCBhZ2VuZGEgaXMgb3V0LiAgV2UncmUgdGVudGF0aXZlbHkg c2NoZWR1bGVkIGZvciBUaHVyc2RheQ0KPiBNb3JuaW5nIFNlc3Npb24gSSAtLSBub3RlIHRoaXMg bWF5IGNoYW5nZS4NCj4gDQo+IFBsZWFzZSBzZW5kIHlvdXIgYWdlbmRhIHJlcXVlc3RzIHRvIHRo ZSBhZGRyZXNzZXMgY2MnZWQgYWJvdmUgYnkgZW5kIG9mDQo+IGRheSBNYXJjaCA4dGguIEluY2x1 ZGUgZHJhZnQgbmFtZSwgYW5kIHdobyB3aWxsIGJlIHByZXNlbnRpbmcuIEEgZHJhZnQNCj4gYWdl bmRhIHdpbGwgYmUgdXBsb2FkZWQgb24gdGhlIDl0aC4NCj4gDQo+IFdHIERyYWZ0IGF1dGhvcnMg YXJlIGV4cGVjdGVkIHRvIHByZXNlbnQgaWYgdGhlcmUgYXJlIG9wZW4gaXNzdWVzIHRvDQo+IGRp c2N1c3MsIG9yIHRvIHNlbmQgc3RhdHVzIHRvIHRoZSBsaXN0ICAqMSB3ZWVrKiBwcmlvciB0byB0 aGUgV0cgbWVldGluZw0KPiBpZiBub3QgcHJlc2VudGluZy4gU3RhdHVzIGluY2x1ZGVzIHJldmll dyBvZjogYW55IHJlY2VudCBjaGFuZ2VzLCBhbnkgb3Blbg0KPiBkaXNjdXNzaW9ucyBvciBpc3N1 ZXMsIGFuZCBwbGFubmVkIG5leHQgc3RlcHMuDQo+IA0KPiBTbGlkZXMgd2lsbCBiZSBkdWUgb24g U3VuZGF5IE1hcmNoIDIyLCAyMDE1LiAoU2VuZCBzbGlkZXMgdG8gdGhlIGFkZHJlc3Nlcw0KPiBj YydlZCBhYm92ZSwgYnV0IG5vdCB0aGUgV0cuKQ0KPiANCj4gU29tZSBpbXBvcnRhbnQgZGF0ZToN Cj4gDQo+IDIwMTUtMDItMjUgKFdlZG5lc2RheSk6IEN1dC1vZmYgZGF0ZSBmb3IgcmVxdWVzdHMg dG8gcmVzY2hlZHVsZSBXb3JraW5nDQo+IEdyb3VwIGFuZCBCT0YgbWVldGluZ3MgVVRDIDIzOjU5 Lg0KPiAyMDE1LTAyLTI3IChGcmlkYXkpOiBGaW5hbCBhZ2VuZGEgdG8gYmUgcHVibGlzaGVkLg0K PiAyMDE1LTAzLTA5IChNb25kYXkpOiBJbnRlcm5ldCBEcmFmdCBzdWJtaXNzaW9uIGN1dC1vZmYg KGZvciBhbGwgZHJhZnRzLA0KPiBpbmNsdWRpbmcgLTAwKSBieSBVVEMgMjM6NTksIHVwbG9hZCB1 c2luZyBJRVRGIElEIFN1Ym1pc3Npb24gVG9vbC4NCj4gMjAxNS0wMy0wOSAoTW9uZGF5KTogRHJh ZnQgV29ya2luZyBHcm91cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjM6NTksIHVwbG9hZA0KPiB1c2lu ZyBJRVRGIE1lZXRpbmcgTWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCj4gMjAxNS0wMy0xMyAo RnJpZGF5KTogRWFybHkgQmlyZCByZWdpc3RyYXRpb24gYW5kIHBheW1lbnQgY3V0LW9mZiBhdCBV VEMNCj4gMjM6NTkuDQo+IDIwMTUtMDMtMTYgKE1vbmRheSk6IFJldmlzZWQgV29ya2luZyBHcm91 cCBhZ2VuZGFzIGR1ZSBieSBVVEMgMjM6NTksDQo+IHVwbG9hZCB1c2luZyBJRVRGIE1lZXRpbmcg TWF0ZXJpYWxzIE1hbmFnZW1lbnQgVG9vbC4NCj4gMjAxNS0wMy0xNiAoTW9uZGF5KTogUmVnaXN0 cmF0aW9uIGNhbmNlbGxhdGlvbiBjdXQtb2ZmIGF0IFVUQyAyMzo1OS4NCj4gMjAxNS0wMy0yMCAo RnJpZGF5KTogRmluYWwgUHJlLVJlZ2lzdHJhdGlvbiBhbmQgUHJlLVBheW1lbnQgY3V0LW9mZiBh dA0KPiAxNzowMCBsb2NhbCBtZWV0aW5nIHRpbWUuDQo+IDIwMTUtMDMtMjIgLSAyMDE1LTAzLTI3 OiBJRVRGIDkyIGluIERhbGxhcywgVFgsIFVTQQ0KPiANCj4gVGhhbmtzLA0KPiBMb3UsIERlYm9y YWggYW5kIE1hdHQNCg0K From nobody Mon Mar 2 08:54:52 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72641A1B73; Mon, 2 Mar 2015 08:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pOBI1px9muX; Mon, 2 Mar 2015 08:54:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DFF1A1ADC; Mon, 2 Mar 2015 08:54:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPU53823; Mon, 02 Mar 2015 16:54:45 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Mar 2015 16:54:44 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 08:54:39 -0800 From: Leeyoung To: "Matt Hartley (mhartley)" , Lou Berger , TEAS WG Thread-Topic: IETF 92 TEAS agenda requests Thread-Index: AQHQVQjwHBBzNmm0HU6J90TGuEqQMp0JZ+/A Date: Mon, 2 Mar 2015 16:54:38 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C93649@dfweml706-chm> References: <54E8E462.2070200@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29B8FD5B@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29B8FD5B@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "adrian@olddog.co.uk" , "teas-chairs@ietf.org" , Daniele Ceccarelli Subject: Re: [Teas] IETF 92 TEAS agenda requests X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:54:50 -0000 Hi Matt, We (Danielle and I) have spoken to Lou and Deborah on ACTN slots. We need a= 15-minute slot to talk about ACTN architecture and interface models. If we= can have another 15 min slot for discussion, that will be great. We are in= the process of updating the draft, but here's the current version: https://datatracker.ietf.org/doc/draft-ceccarelli-actn-framework/ Thanks, Young and Daniele -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Matt Hartley (mhartl= ey) Sent: Monday, March 02, 2015 10:50 AM To: Lou Berger; TEAS WG Cc: Matt Hartley (mhartley); teas-chairs@ietf.org Subject: Re: [Teas] IETF 92 TEAS agenda requests A reminder on this... Cheers Matt > Dear TEAS, >=20 > The IETF92 draft agenda is out. We're tentatively scheduled for=20 > Thursday Morning Session I -- note this may change. >=20 > Please send your agenda requests to the addresses cc'ed above by end=20 > of day March 8th. Include draft name, and who will be presenting. A=20 > draft agenda will be uploaded on the 9th. >=20 > WG Draft authors are expected to present if there are open issues to=20 > discuss, or to send status to the list *1 week* prior to the WG=20 > meeting if not presenting. Status includes review of: any recent=20 > changes, any open discussions or issues, and planned next steps. >=20 > Slides will be due on Sunday March 22, 2015. (Send slides to the=20 > addresses cc'ed above, but not the WG.) >=20 > Some important date: >=20 > 2015-02-25 (Wednesday): Cut-off date for requests to reschedule=20 > Working Group and BOF meetings UTC 23:59. > 2015-02-27 (Friday): Final agenda to be published. > 2015-03-09 (Monday): Internet Draft submission cut-off (for all=20 > drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool= . > 2015-03-09 (Monday): Draft Working Group agendas due by UTC 23:59,=20 > upload using IETF Meeting Materials Management Tool. > 2015-03-13 (Friday): Early Bird registration and payment cut-off at=20 > UTC 23:59. > 2015-03-16 (Monday): Revised Working Group agendas due by UTC 23:59,=20 > upload using IETF Meeting Materials Management Tool. > 2015-03-16 (Monday): Registration cancellation cut-off at UTC 23:59. > 2015-03-20 (Friday): Final Pre-Registration and Pre-Payment cut-off at=20 > 17:00 local meeting time. > 2015-03-22 - 2015-03-27: IETF 92 in Dallas, TX, USA >=20 > Thanks, > Lou, Deborah and Matt _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Mar 2 09:20:10 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66351A1BF3 for ; Mon, 2 Mar 2015 09:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOMuJxXSeZP9 for ; Mon, 2 Mar 2015 09:20:07 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id D0A251A1BBD for ; Mon, 2 Mar 2015 09:20:07 -0800 (PST) Received: (qmail 29236 invoked by uid 0); 2 Mar 2015 17:20:05 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 2 Mar 2015 17:20:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id yhJl1p00D2SSUrH01hJo3y; Mon, 02 Mar 2015 10:18:48 -0700 X-Authority-Analysis: v=2.1 cv=bJKFfpOZ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=di5ffHmRpT7gQr8tc2MA:9 a=pILNOxqGKmIA:10 a=xw7y_clKBisA:10 a=_WIUzzsHgV4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=whKLdW+sxI74ZozJU+rC8oJPNJgnfvt96mvNzt+vN9s=; b=YOxWfIrfsPiGU/yEKPS9Q+JfyEYPMIguDh9v6gQEeUUk1jCl8Q/XmbE8du2H+1an4BNUsmkR63UBvAJf5+1ulpNnN/FRmoVT01tCvdFHuJVlOtaW624OZbQwZu9sucZu; Received: from box313.bluehost.com ([69.89.31.113]:45412 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YSTzR-0001Ux-Tj for teas@ietf.org; Mon, 02 Mar 2015 10:18:45 -0700 Message-ID: <54F49B6F.1010806@labn.net> Date: Mon, 02 Mar 2015 12:18:39 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: TEAS WG References: <54E8E462.2070200@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29B8FD5B@xmb-rcd-x03.cisco.com> <7AEB3D6833318045B4AE71C2C87E8E1729C93649@dfweml706-chm> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C93649@dfweml706-chm> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] IETF 92 TEAS agenda requests X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 17:20:09 -0000 I guess I should have been explicit -- there is no need to send agenda requests to the whole WG, just the original cc line, i.e.: teas-chairs@ietf.org , Matt Hartley Thank you, Lou On 3/2/2015 11:54 AM, Leeyoung wrote: > > Please send your agenda requests to the addresses cc'ed above by end > > of day March 8th. Include draft name, and who will be presenting. A > > draft agenda will be uploaded on the 9th. > > From nobody Tue Mar 3 10:05:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0270D1A870A; Tue, 3 Mar 2015 09:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI2vxZwEGhHn; Tue, 3 Mar 2015 09:58:16 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30:5054:ff:fe5e:1643]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A445A1A01FC; Tue, 3 Mar 2015 09:58:15 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1YSr5A-0000so-6C; Tue, 03 Mar 2015 17:58:12 +0000 Message-ID: <54F5F635.2050304@folly.org.uk> Date: Tue, 03 Mar 2015 17:58:13 +0000 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> In-Reply-To: <201502161358.t1GDwFvO095836@givry.fdupont.fr> Content-Type: multipart/alternative; boundary="------------030308060308050204000801" Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2015 10:05:34 -0800 Cc: gen-art@ietf.org, Lou Berger , "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , teas@ietf.org Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 17:58:19 -0000 This is a multi-part message in MIME format. --------------030308060308050204000801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi. In the process of doing the gen-art review of draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments about ordering of subobjects in the loopback draft. I thought that the text in the first paragraph of s2.3: > As described in [RFC3209 ] and [RFC3473 ] the ERO is managed as a list > where each hop information starts with a subobject identifying an > abstract node or link. The ERO Hop Attributes subobject MAY be > appended after any of the existing subobjects defined in [RFC3209 ], > [RFC3473 ], [RFC3477 ], [RFC4873 ], [RFC4874 ], [RFC5520 ] and [RFC5553 ]. > Several ERO Hop Attributes subobject MAY be present, for each hop. was not very clear: The use of 'appended' was slightly confusing. I felt it needed something a bit closer to the "Presence Rules" that are given for RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going on. I am not totally clear what would happen in the case of (say) an IPv4 address subobject followed by two Label subobjects. The wording seems to indicate that Hop attributes can be inserted anywhere in the sequence of three subobjects - but would they specifically apply to one or other Label if they were inserted after a Label or would they always apply generically to the hop terminated at the IPv4 address entity? My suggestion for rewording, based on the assumption that the hop attributes apply to the hop rather than any of the labels, would be: As described in [RFC3209] the ERO is managed as a list of subobjects each identifying a specific entity, an abstract node or a link. Identifying subobjects of various types are defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO list by allowing one or two Label subobjects to be interposed in the list after a subobject identifying an entity by its IP address or interface identifier. One or more ERO Hop attributes subobjects applicable to a particular hop MAY be inserted after any of the existing identifying subobjects defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are present for a hop, the ERO Hop attributes subobject(s) MUST be inserted after the Label subobjects. The last two sentences would need to be altered if Hop attributes were applicable to Labels rather than just to the hop as a whole. Regards, Elwyn --------------030308060308050204000801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi.

In the process of doing the gen-art review of draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at  draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments about ordering of subobjects in the loopback draft.

I thought that the text in the first paragraph of s2.3:
   As described in [RFC3209] and [RFC3473] the ERO is managed as a list
   where each hop information starts with a subobject identifying an
   abstract node or link.  The ERO Hop Attributes subobject MAY be
   appended after any of the existing subobjects defined in [RFC3209],
   [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553].
   Several ERO Hop Attributes subobject MAY be present, for each hop.
was not very clear: The use of 'appended' was slightly confusing.  I felt it needed something a bit closer to the "Presence Rules" that are given for RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going on. 

I am not totally clear what would happen in the case of (say) an IPv4 address subobject followed by two Label subobjects.  The wording seems to indicate that Hop attributes can be inserted anywhere in the sequence of three subobjects - but would they specifically apply to one or other Label if they were inserted after a Label or would they always apply generically to the hop terminated at the IPv4 address entity?

My suggestion for rewording, based on the assumption that the hop attributes apply to the hop rather than any of the labels, would be:

   As described in [RFC3209] the ERO is managed as a list of subobjects
   each identifying a specific entity, an abstract node or a link.   Identifying
   subobjects of various types are defined in [RFC3209], [RFC3477], [RFC4873],
   [RFC4874], [RFC5520] and [RFC5553].  [RFC3473] modified the ERO list by
   allowing one or two Label subobjects to be interposed in the list after a
   subobject identifying an entity by its IP address or interface identifier.   One
   or more ERO Hop attributes subobjects applicable to a particular hop MAY
   be inserted after any of the existing identifying subobjects defined in
   [RFC3209],  [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. 
   If any Label subobjects are present for a hop, the ERO Hop attributes
   subobject(s) MUST be inserted after the Label subobjects.

The last two sentences would need to be altered if Hop attributes were applicable to Labels rather than just to the hop as a whole. 

Regards,
Elwyn


--------------030308060308050204000801-- From nobody Tue Mar 3 10:18:57 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BE61A87C3; Tue, 3 Mar 2015 10:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOM22lyeg4m2; Tue, 3 Mar 2015 10:18:53 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30:5054:ff:fe5e:1643]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35841A8824; Tue, 3 Mar 2015 10:18:48 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1YSrOy-0001og-So; Tue, 03 Mar 2015 18:18:40 +0000 Message-ID: <54F5FB02.4090907@folly.org.uk> Date: Tue, 03 Mar 2015 18:18:42 +0000 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: General area reviewing team , "draft-ietf-teas-rsvp-te-li-lb.all" , teas@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Teas] Gen-art telechat review of draft-ietf-teas-rsvp-te-li-lb-04.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 18:18:55 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-teas-rsvp-te-li-lb-04.txt Reviewer: Elwyn Davies Review Date: 2015/03/03 IETF LC End Date: 2015/02/18 IESG Telechat date: 20150305 Summary: Almost ready for PS. I noticed at a late stage in the last call reviewing process that the requirement that the hop before a loopback node should be a strict hop was unnecessary. The draft editor, Dong Jie, has agreed that this is the case and is checking that the removal of this constraint is acceptable to the other authors. There is one other outstanding fix agreed for a nit. Otherwise all my last call comments have been cleared. Thanks. Major issues: None Minor issues: s3.2, para 2, et seq: The requirement that the hop before the loopback entity MUST be a strict hop is unnecessary. The essential constraint (which is fully specified in the -04 draft) is that the entity at which loopback is to occur has to be uniquely identified (i.e., it can't be an 'abstract node' signifying (potentially) a group of nodes, such as an AS). I have discussed this with Dong Jie, as editor, and he has agreed that the constraint is not needed. A new version of the draft removing the constraint is in hand, pending agreement with the other authors and checking with the WG. Nits/editorial comments: s3.2, para 3: OLD : Currently, the type value MUST be verified to be less than 32, and for type values 1 and 2, the prefix length MUST be 32 and 128 respectively. NEW: Currently, the type value MUST be verified to be less than 32 (i.e., able to identify a specific entity where a loopback can occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 (IPv6 address), the prefix length MUST be 32 and 128 respectively. From nobody Tue Mar 3 12:08:45 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84601A890A; Tue, 3 Mar 2015 12:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvLsQ67sn_T2; Tue, 3 Mar 2015 12:08:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E161A8902; Tue, 3 Mar 2015 12:08:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150303200841.20429.36199.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 12:08:41 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 20:08:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : RSVP-TE Extensions for Associated Bidirectional LSPs Authors : Fei Zhang Ruiquan Jing Rakesh Gandhi Filename : draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt Pages : 20 Date : 2015-03-03 Abstract: This document describes Resource reSerVation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single sided provisioning case. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 3 17:02:53 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743641A88E7 for ; Tue, 3 Mar 2015 17:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mzvtjI4UF8e for ; Tue, 3 Mar 2015 17:02:47 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7FA1A89AB for ; Tue, 3 Mar 2015 17:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2333; q=dns/txt; s=iport; t=1425430967; x=1426640567; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ojBjv21PiHfXOJL8vutyTO8OI/psG32ZbQqI4bELygI=; b=b8DpdZ4r4B1R36/E1uaKsVjXPzq2p1+mP+9bxDGMvUqtcCxN0SZRE9bi H6eVkBgQK3ZwiAop/ULEVYL5IW/QT3SBQWq3Zr/xTxTVjKoLvEbISGtW2 rAksf848551WfEp2d0bVdEe8ShKqjLH7Og2/SUNfHU2Qd5tb2m8nvz6gf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQAnWfZU/5hdJa1agwJSVQnBPAyFbgKBJ00BAQEBAQF8hBABAQQBAQE3NAsSAQgSJDcLFw4CBA4FCYgmCAXWVAEBAQEBAQEDAQEBAQEBAQEBGYsShDszB4QrBY95g2CFaYEaOYJpi2aDPiODbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,684,1418083200"; d="scan'208";a="401006122" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 04 Mar 2015 01:02:46 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2412kVL020584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 01:02:46 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 19:02:46 -0600 From: "Rakesh Gandhi (rgandhi)" To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt Thread-Index: AQHQVhbtOHMtcVTA6kO1+VdxcM3s6A== Date: Wed, 4 Mar 2015 01:02:45 +0000 Message-ID: In-Reply-To: <20150303200841.20429.36199.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.246.137] Content-Type: text/plain; charset="us-ascii" Content-ID: <93CCDB1D06F1FC4A94140B3CCCDD903A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Lou Berger Subject: Re: [Teas] I-D Action: draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 01:02:49 -0000 Hi WG, This revision concludes markups for the review comments received during AD review/LC. Welcome your reviews/suggestions. Thank you, Rakesh On 2015-03-03 3:08 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Traffic Engineering Architecture and >Signaling Working Group of the IETF. > > Title : RSVP-TE Extensions for Associated Bidirectional >LSPs > Authors : Fei Zhang > Ruiquan Jing > Rakesh Gandhi > Filename : >draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt > Pages : 20 > Date : 2015-03-03 > >Abstract: > This document describes Resource reSerVation Protocol (RSVP) > extensions to bind two point-to-point unidirectional Label Switched > Paths (LSPs) into an associated bidirectional LSP. The association > is achieved by defining new Association Types for use in ASSOCIATION > and in Extended ASSOCIATION Objects. One of these types enables > independent provisioning of the associated bidirectional LSPs on both > sides, while the other enables single sided provisioning. The > REVERSE_LSP Object is also defined to enable a single endpoint to > trigger creation of the reverse LSP and to specify parameters of the > reverse LSP in the single sided provisioning case. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-associ >ated-lsp/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-l >sp-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-mpls-tp-rsvpte-ext-asso= ci >ated-lsp-07 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Tue Mar 3 22:04:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058B91A039B; Tue, 3 Mar 2015 22:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnSAhTDGaJKD; Tue, 3 Mar 2015 22:04:39 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024431A038E; Tue, 3 Mar 2015 22:04:39 -0800 (PST) Received: by wesw62 with SMTP id w62so44147703wes.9; Tue, 03 Mar 2015 22:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=REiKMuYD3Y0YRoTbgcgfpxSI8PplcYCoGP9Na/58JF0=; b=PERrROU3YlSgtrhtm5IkBXuCliTS0tRqRomWNhwNkbKndaquCSjGs1bXthSc4+T38o OpfWpWLEGppts1AN9iVz7JAbCmXPSmyxF2ZOFLbGRg7QyiL2RphLZ1tXYzl8qgH7Dvxp +m4x6hLToa2tcpYGxURmrxt4tyOqi80cwGLC4e4oNg72Qo6aEb836lj68ExumbQ2iD7/ AJJ1GlTO6hhGse1Iiv7dbpJ8wCeHuN3mZ4OTXJuHur/nsB6PqNDxHgarcD3aAiLD2jct n9QJ8jDOjPXq0cQ6K/9RwTbSXtmriA9QWRQQUfMhJmnZOK+1Xec6zKkAp6WIxMc5757Y 7srw== MIME-Version: 1.0 X-Received: by 10.180.149.206 with SMTP id uc14mr52305847wib.57.1425449076050; Tue, 03 Mar 2015 22:04:36 -0800 (PST) Received: by 10.27.51.145 with HTTP; Tue, 3 Mar 2015 22:04:36 -0800 (PST) In-Reply-To: <54F5F635.2050304@folly.org.uk> References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> <54F5F635.2050304@folly.org.uk> Date: Wed, 4 Mar 2015 01:04:36 -0500 Message-ID: From: Cyril Margaria To: Elwyn Davies Content-Type: multipart/alternative; boundary=001a11c38008d2d3d20510703984 Archived-At: Cc: gen-art@ietf.org, Lou Berger , draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , teas@ietf.org Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 06:04:42 -0000 --001a11c38008d2d3d20510703984 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thanks for your review, Please not that a new revision addressing IANA , APS-DIR and Gen-ART comments on revision -02 is available. https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 please see inline. On 3 March 2015 at 12:58, Elwyn Davies wrote: > Hi. > > In the process of doing the gen-art review of > draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at > draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments abou= t > ordering of subobjects in the loopback draft. > > I thought that the text in the first paragraph of s2.3: > > As described in [RFC3209 ] and [R= FC3473 ] the ERO is managed as a list > where each hop information starts with a subobject identifying an > abstract node or link. The ERO Hop Attributes subobject MAY be > appended after any of the existing subobjects defined in [RFC3209 ], > [RFC3473 ], [RFC3477 ], [RFC4873 ]= , [RFC4874 ], [RFC5520 ] and [RFC5553 ]= . > Several ERO Hop Attributes subobject MAY be present, for each hop. > > was not very clear: The use of 'appended' was slightly confusing. I fel= t > it needed something a bit closer to the "Presence Rules" that are given f= or > RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going > on. > > I am not totally clear what would happen in the case of (say) an IPv4 > address subobject followed by two Label subobjects. The wording seems to > indicate that Hop attributes can be inserted anywhere in the sequence of > three subobjects - but would they specifically apply to one or other Labe= l > if they were inserted after a Label or would they always apply genericall= y > to the hop terminated at the IPv4 address entity? > > draft-ietf-teas-lsp-attribute-ro tries to leave that open to the documents defining the TLVs. We are not excluding an Attribute that applies to a Label or Interface. If the subobject would be inserted after a Label Subobject, the Attribute TLVs would apply to the Labels. This is based on the following review comment:" I think *this* I-D needs to make it clear what the expectations are: 1. The sub-object is allowed at any point in the ERO 2. The document that specifies a TLV for the sub-object must make it clear where in an ERO a sub-object containing that TLV is allowed and not allowed." Do you think this is reasonable or we should exclude TLVs scoped to labels? In the latter case, I would add you suggested text. Best Regards. Cyril PS: It seems there are errors with the tools.ietf.org aliases > My suggestion for rewording, based on the assumption that the hop > attributes apply to the hop rather than any of the labels, would be: > > As described in [RFC3209] the ERO is managed as a list of subobjects > each identifying a specific entity, an abstract node or a link. > Identifying > subobjects of various types are defined in [RFC3209], [RFC3477], > [RFC4873], > [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO list b= y > allowing one or two Label subobjects to be interposed in the list afte= r > a > subobject identifying an entity by its IP address or interface > identifier. One > or more ERO Hop attributes subobjects applicable to a particular hop > MAY > be inserted after any of the existing identifying subobjects defined i= n > [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. > If any Label subobjects are present for a hop, the ERO Hop attributes > subobject(s) MUST be inserted after the Label subobjects. > > The last two sentences would need to be altered if Hop attributes were > applicable to Labels rather than just to the hop as a whole. > > Regards, > Elwyn > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --001a11c38008d2d3d20510703984 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for your review,
Ple= ase not that a new revision addressing IANA , APS-DIR and Gen-ART comments= =C2=A0 on revision -02 is available.
https://tools.ie= tf.org/html/draft-ietf-teas-lsp-attribute-ro-03

=C2=A0please see= inline.




On 3 March 2015 at 12:58, Elwyn Davies = <elwynd@folly.o= rg.uk> wrote:
=20 =20 =20
Hi.

In the process of doing the gen-art review of draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at=C2=A0 draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments about ordering of subobjects in the loopback draft.

I thought that the text in the first paragraph of s2.3:
   As described in [RFC3209] and [RFC3473] the ERO is managed as a list
   where each hop information starts with a subobject identifying an
   abstract node or link.  The ERO Hop Attributes subobject MAY be
   appended after any of the existing subobjects defined in [RFC3209],
   [R=
FC3473], [RFC3477], [RFC4873], [RFC4874=
], [RFC5520] and [RFC555=
3].
   Several ERO Hop Attributes subobject MAY be present, for each hop.
was not very clear: The use of 'appended' was slightly confusin= g.=C2=A0 I felt it needed something a bit closer to the "Presence Rules"= that are given for RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going on.=C2=A0

I am not totally clear what would happen in the case of (say) an IPv4 address subobject followed by two Label subobjects.=C2=A0 The wording seems to indicate that Hop attributes can be inserted anywhere in the sequence of three subobjects - but would they specifically apply to one or other Label if they were inserted after a Label or would they always apply generically to the hop terminated at the IPv4 address entity?


draft-ietf-teas-lsp-attribute-ro tries = to leave that open to the documents defining the TLVs. We are not excluding= an Attribute that applies to a Label or Interface. If the subobject would = be inserted after a Label Subobject, the Attribute TLVs would apply to the = Labels.

This is based on the following review comment:&qu= ot;
I think *this* I-D needs to make it clear what the expectations are:

1. The sub-object is allowed at any point in the ERO
2. The document that specifies a TLV for the sub-object must make it
=C2=A0 =C2=A0clear where in an ERO a sub-object containing that TLV is allo= wed and
=C2=A0 =C2=A0not allowed."

Do you think this is reas= onable or we should exclude TLVs scoped to labels?
In the lat= ter case, I would add you suggested text.

Best Regards.
Cyril

PS: It seems there are errors with the= tools.ietf.org ali= ases
=C2=A0
My suggestion for rewording, based on the assumption that the hop attributes apply to the hop rather than any of the labels, would be:
=C2=A0=C2=A0 As described in [RFC3209] the ERO is managed as a list of subobjects
=C2=A0=C2=A0 each identifying a specific entity, an abstract node or a = link.=C2=A0=C2=A0 Identifying
=C2=A0=C2=A0 subobjects of various types are defined in [RFC3209], [RFC= 3477], [RFC4873],
=C2=A0=C2=A0 [RFC4874], [RFC5520] and [RFC5553].=C2=A0 [RFC3473] modifi= ed the ERO list by
=C2=A0=C2=A0 allowing one or two Label subobjects to be interposed in t= he list after a
=C2=A0=C2=A0 subobject identifying an entity by its IP address or inter= face identifier. =C2=A0 One
=C2=A0=C2=A0 or more ERO Hop attributes subobjects applicable to a part= icular hop MAY
=C2=A0=C2=A0 be inserted after any of the existing identifying subobjec= ts defined in
=C2=A0=C2=A0 [RFC3209],=C2=A0 [RFC3477], [RFC4873], [RFC4874], [RFC5520= ] and [RFC5553].=C2=A0
=C2=A0=C2=A0 If any Label subobjects are present for a hop, the ERO Hop attributes
=C2=A0=C2=A0 subobject(s) MUST be inserted after the Label subobjects.<= br>
The last two sentences would need to be altered if Hop attributes were applicable to Labels rather than just to the hop as a whole.=C2=A0=

Regards,
Elwyn



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--001a11c38008d2d3d20510703984-- From nobody Tue Mar 3 23:52:49 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98B21A0AF1; Tue, 3 Mar 2015 23:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2spuLOD4qWc; Tue, 3 Mar 2015 23:52:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A12481A06E9; Tue, 3 Mar 2015 23:52:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304075245.3723.47384.idtracker@ietfa.amsl.com> Date: Tue, 03 Mar 2015 23:52:45 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 07:52:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : GMPLS RSVP-TE Extensions for Lock Instruct and Loopback Authors : Jie Dong Mach(Guoyi) Chen Zhenqiang Li Daniele Ceccarelli Filename : draft-ietf-teas-rsvp-te-li-lb-05.txt Pages : 9 Date : 2015-03-03 Abstract: This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) for the control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-li-lb-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 4 00:26:27 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD61A066C; Wed, 4 Mar 2015 00:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc3CmgAKkMUp; Wed, 4 Mar 2015 00:26:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B071A0154; Wed, 4 Mar 2015 00:26:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTG31575; Wed, 04 Mar 2015 08:26:23 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Mar 2015 08:26:22 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 4 Mar 2015 16:26:16 +0800 From: "Dongjie (Jimmy)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-05.txt Thread-Index: AQHQVlA7o1lXJp8lEEiJQaGeQBg1250L9AYA Date: Wed, 4 Mar 2015 08:26:15 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273384CE21@nkgeml512-mbx.china.huawei.com> References: <20150304075245.3723.47384.idtracker@ietfa.amsl.com> In-Reply-To: <20150304075245.3723.47384.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 08:26:27 -0000 Dear all,=20 This new revision solves the Gen-ART review comments received on revision -= 04. The post-LC changes are:=20 1. The specifications about the identification of the loopback target are r= evised to make it clear that the target entity of loopback must be explicit= ly identified (i.e. cannot be a group of entities).=20 2. In IANA considerations, a subsection is added to change the allocation r= ule for ERO subobject type values 5-31, so that these type values will be a= llocated to explicitly identify specific resource. 3. In Security considerations, the description of privacy considerations is= added. 4. The typos and nits are solved.=20 Best regards, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, March 04, 2015 3:53 PM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-li-lb-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Traffic Engineering Architecture and Si= gnaling > Working Group of the IETF. >=20 > Title : GMPLS RSVP-TE Extensions for Lock Instruct and > Loopback > Authors : Jie Dong > Mach(Guoyi) Chen > Zhenqiang Li > Daniele Ceccarelli > Filename : draft-ietf-teas-rsvp-te-li-lb-05.txt > Pages : 9 > Date : 2015-03-03 >=20 > Abstract: > This document specifies extensions to Resource Reservation Protocol- > Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and > Loopback (LB) mechanisms for Label Switched Paths (LSPs). These > mechanisms are applicable to technologies which use Generalized > Multi-Protocol Label Switching (GMPLS) for the control plane. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-rsvp-te-li-lb-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-te-li-lb-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Mar 4 09:35:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBBE1A8834 for ; Wed, 4 Mar 2015 08:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2e4WHvV9Aei for ; Wed, 4 Mar 2015 08:18:47 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF751A049C for ; Wed, 4 Mar 2015 08:18:47 -0800 (PST) Received: by obcwo20 with SMTP id wo20so7841751obc.5 for ; Wed, 04 Mar 2015 08:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=w9NJQgMy2ezxXHFkV/BwzysB2KiZUeIdeChbEGqH/qw=; b=Yg/1ssyZyUjzcMJfkrwEP8gIdrWvPGASn+b6+1je8pEVLnb96dqCXnBv7tjbCUhlij zIR6vGGVtYdCOb8RSgiTJiZERVRDBRIXExbqF/wEYZ+lc/gSuIihof3HaFAX33oMJ8QK dy4dmIWU85dP3i+81sIM/jUd4pOsqtPG3rDXmkvg6akV5POWIzshJX+MMVTm+zM22ELt x+xETrOpV2EpJ3+afEZlLE6VI1pLw+NuWwloabGoZWLyf7oS8Uh++k0evZcxvsXU9Pa8 725eODBs4Kz+VzOMjtUt0Ldgm1BNMe+RHkkK67CTO0UxJE9EBDXE7fLC7eR3mSW6FOiY SWXQ== MIME-Version: 1.0 X-Received: by 10.202.185.198 with SMTP id j189mr3446636oif.72.1425485881572; Wed, 04 Mar 2015 08:18:01 -0800 (PST) Received: by 10.60.97.135 with HTTP; Wed, 4 Mar 2015 08:18:01 -0800 (PST) Date: Wed, 4 Mar 2015 11:18:01 -0500 Message-ID: From: Alia Atlas To: Vishnu Pavan Beeram , teas@ietf.org Content-Type: multipart/alternative; boundary=001a113ce80e9a8243051078cbc2 Archived-At: X-Mailman-Approved-At: Wed, 04 Mar 2015 09:35:35 -0800 Subject: [Teas] TEAS chairs X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 16:18:48 -0000 --001a113ce80e9a8243051078cbc2 Content-Type: text/plain; charset=UTF-8 Hi TEAS, >From Weds evening of IETF-92, Deborah will be serving as Routing AD so it isn't appropriate for her to continue to chair a WG in the Routing Area. Thus, Deborah is stepping down as co-chair of SPRING. I really appreciate the hard work that Deborah has done as TEAS co-chair. I have consulted with Alvaro, Deborah, Adrian, and Lou Berger, and have decided to appoint Pavan Beeram to serve in this role. Pavan will be busy ramping up. I expect the handover to be finished in Dallas. Pavan can be reached at . Thanks, Alia --001a113ce80e9a8243051078cbc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi TEAS,
<= br>
From Weds evening of I= ETF-92, Deborah will be serving as Routing AD so it isn't appropriate f= or her to continue to chair a WG in the Routing Area.=C2=A0 Thus, Deborah i= s stepping down as co-chair of SPRING.=C2=A0 I really appreciate the hard w= ork that Deborah has done as TEAS co-chair.

I h= ave consulted with Alvaro, Deborah, Adrian, and Lou Berger, and have decide= d to appoint Pavan Beeram to serve in this role.=C2=A0 Pavan will be busy r= amping up.=C2=A0 I expect the handover to be finished in Dallas.

Pavan can be reached at <vbeeram@juniper.net>.

Thanks,
Alia<= /div>
--001a113ce80e9a8243051078cbc2-- From nobody Wed Mar 4 09:48:55 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CAC1A913E for ; Wed, 4 Mar 2015 09:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I9POs7Z4y-Q for ; Wed, 4 Mar 2015 09:48:53 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D161A854D for ; Wed, 4 Mar 2015 09:48:52 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 48547f45.2b6816022940.1276002.00-2485.3561808.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 04 Mar 2015 17:48:52 +0000 (UTC) X-MXL-Hash: 54f745842f14e2f5-bbd85cd76520e4bedba975c9fc62c4fbbbcfb4ad Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id b7547f45.0.1275931.00-2195.3561600.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 04 Mar 2015 17:48:46 +0000 (UTC) X-MXL-Hash: 54f7457e5e4d6e30-c7d051555f46cd5453131070710d72d9d19f8081 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t24Hmh4u009118; Wed, 4 Mar 2015 12:48:43 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t24HmZln008985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Mar 2015 12:48:39 -0500 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 4 Mar 2015 17:48:24 GMT Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.162]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0224.002; Wed, 4 Mar 2015 12:48:23 -0500 From: "BRUNGARD, DEBORAH A" To: Alia Atlas , Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] TEAS chairs Thread-Index: AQHQVqGlZvNckhCAEEiR2Vk35v2IZJ0MmSpQ Date: Wed, 4 Mar 2015 17:48:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.235] Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C83B520679MISOUT7MSGUSRDE_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=F73ggNdN c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=A3DeceiK-qMA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=OUXY8nFuAA] X-AnalysisOut: [AA:8 a=IvMJK08jKX8d8Z4gJMIA:9 a=QEXdDO2ut3YA:10 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=-XpX9tM1iAYn2FMf7wIA:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=F5UxzM0pMNvdxSIu:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: Subject: Re: [Teas] TEAS chairs X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:48:54 -0000 --_000_F64C10EAA68C8044B33656FA214632C83B520679MISOUT7MSGUSRDE_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFsaWEtDQpXZWxjb21lIFBhdmFuIQ0KDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0bGFzDQpTZW50OiBXZWRuZXNk YXksIE1hcmNoIDA0LCAyMDE1IDExOjE4IEFNDQpUbzogVmlzaG51IFBhdmFuIEJlZXJhbTsgdGVh c0BpZXRmLm9yZw0KU3ViamVjdDogW1RlYXNdIFRFQVMgY2hhaXJzDQoNCkhpIFRFQVMsDQoNCkZy b20gV2VkcyBldmVuaW5nIG9mIElFVEYtOTIsIERlYm9yYWggd2lsbCBiZSBzZXJ2aW5nIGFzIFJv dXRpbmcgQUQgc28gaXQgaXNuJ3QgYXBwcm9wcmlhdGUgZm9yIGhlciB0byBjb250aW51ZSB0byBj aGFpciBhIFdHIGluIHRoZSBSb3V0aW5nIEFyZWEuICBUaHVzLCBEZWJvcmFoIGlzIHN0ZXBwaW5n IGRvd24gYXMgY28tY2hhaXIgb2YgU1BSSU5HLiAgSSByZWFsbHkgYXBwcmVjaWF0ZSB0aGUgaGFy ZCB3b3JrIHRoYXQgRGVib3JhaCBoYXMgZG9uZSBhcyBURUFTIGNvLWNoYWlyLg0KDQpJIGhhdmUg Y29uc3VsdGVkIHdpdGggQWx2YXJvLCBEZWJvcmFoLCBBZHJpYW4sIGFuZCBMb3UgQmVyZ2VyLCBh bmQgaGF2ZSBkZWNpZGVkIHRvIGFwcG9pbnQgUGF2YW4gQmVlcmFtIHRvIHNlcnZlIGluIHRoaXMg cm9sZS4gIFBhdmFuIHdpbGwgYmUgYnVzeSByYW1waW5nIHVwLiAgSSBleHBlY3QgdGhlIGhhbmRv dmVyIHRvIGJlIGZpbmlzaGVkIGluIERhbGxhcy4NCg0KUGF2YW4gY2FuIGJlIHJlYWNoZWQgYXQg PHZiZWVyYW1AanVuaXBlci5uZXQ8bWFpbHRvOnZiZWVyYW1AanVuaXBlci5uZXQ+Pi4NCg0KVGhh bmtzLA0KQWxpYQ0K --_000_F64C10EAA68C8044B33656FA214632C83B520679MISOUT7MSGUSRDE_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIEFsaWEtPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlbGNvbWUgUGF2YW4hPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+QWxpYSBBdGxhczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA0 LCAyMDE1IDExOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBWaXNobnUgUGF2YW4gQmVlcmFtOyB0ZWFz QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUZWFzXSBURUFTIGNoYWlyczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFRFQVMsPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkZyb20gV2VkcyBl dmVuaW5nIG9mIElFVEYtOTIsIERlYm9yYWggd2lsbCBiZSBzZXJ2aW5nIGFzIFJvdXRpbmcgQUQg c28gaXQgaXNuJ3QgYXBwcm9wcmlhdGUgZm9yIGhlciB0byBjb250aW51ZSB0byBjaGFpciBhIFdH IGluIHRoZSBSb3V0aW5nIEFyZWEuJm5ic3A7IFRodXMsIERlYm9yYWggaXMgc3RlcHBpbmcgZG93 biBhcyBjby1jaGFpciBvZiBTUFJJTkcuJm5ic3A7IEkgcmVhbGx5DQogYXBwcmVjaWF0ZSB0aGUg aGFyZCB3b3JrIHRoYXQgRGVib3JhaCBoYXMgZG9uZSBhcyBURUFTIGNvLWNoYWlyLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPkkgaGF2ZSBjb25zdWx0ZWQgd2l0aCBBbHZhcm8sIERlYm9yYWgsIEFkcmlhbiwgYW5k IExvdSBCZXJnZXIsIGFuZCBoYXZlIGRlY2lkZWQgdG8gYXBwb2ludCBQYXZhbiBCZWVyYW0gdG8g c2VydmUgaW4gdGhpcyByb2xlLiZuYnNwOyBQYXZhbiB3aWxsIGJlIGJ1c3kgcmFtcGluZyB1cC4m bmJzcDsgSSBleHBlY3QgdGhlIGhhbmRvdmVyIHRvIGJlIGZpbmlzaGVkIGluIERhbGxhcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0Ij5QYXZhbiBjYW4gYmUgcmVhY2hlZCBhdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZi ZWVyYW1AanVuaXBlci5uZXQiPnZiZWVyYW1AanVuaXBlci5uZXQ8L2E+Jmd0Oy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+QWxpYTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_F64C10EAA68C8044B33656FA214632C83B520679MISOUT7MSGUSRDE_-- From nobody Wed Mar 4 09:50:27 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615B91A9165 for ; Wed, 4 Mar 2015 09:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSBOyRWq5anE for ; Wed, 4 Mar 2015 09:50:25 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4F21A916C for ; Wed, 4 Mar 2015 09:50:22 -0800 (PST) X-AuditID: c6180641-f796f6d000004ccc-22-54f6e4fdafbc Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 07.25.19660.DF4E6F45; Wed, 4 Mar 2015 11:57:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 12:50:20 -0500 From: Gregory Mirsky To: Alia Atlas , Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] TEAS chairs Thread-Index: AQHQVqGjOirku4hDJUuz2MKK2mWmWZ0MmfZQ Date: Wed, 4 Mar 2015 17:50:20 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B918817@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B918817eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPuO7fJ99CDFY/sLT49PASs0Xrjx0s FgvWzGR2YPbYOesuu8eSJT+ZPK43XWUPYI7isklJzcksSy3St0vgyjh8PbTgm13FhraHrA2M U2y7GDk5JARMJNonbmCFsMUkLtxbz9bFyMUhJHCEUeLv4TVMEM4yRomtE38xglSxCRhJvNjY ww5iiwgUSBw62MgEYgsLyEscuNLMChFXkPh1DqbGSKL70FSwXhYBFYmZt26xgdi8Ar4S+7Y9 BLOFBAIkeg6vBpvDKRAocbnhPZjNCHTR91NrwGxmAXGJW0/mM0FcKiCxZM95ZghbVOLl439Q HyhJTFp6DsjmAKrPl5i6Ig9ilaDEyZlPWCYwisxCMmkWQtUsJFUQYU2J9bv0IaoVJaZ0P2SH sDUkWufMZUcWX8DIvoqRo7Q4tSw33chwEyMwlo5JsDnuYFzwyfIQowAHoxIP7waWbyFCrIll xZW5hxilOViUxHnLrhwMERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCYxbTVubBio0Z7cXol t/EsSa9tCtttrTM8D91nNP8cdfV8aXpek3R04JdbXhdYwrbU8j+Lnnz/y8SUR9Iz1s6+x6y5 LvVzap19QLzABUXnuEiZPX8vJX1g/LFcJiRzh9v8a3tm1kWtcF9otMRMuOm770fOn6djJnTO XeHd28muq6MVJ1qWrKnEUpyRaKjFXFScCADunco2hgIAAA== Archived-At: Subject: Re: [Teas] TEAS chairs X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 17:50:27 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B918817eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2VyZSBjb25ncmF0dWxhdGlvbnMgdG8gRGVib3JhaCBhbmQgUGF2YW4uDQoNCiAgICAgICAg ICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoN CkZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBB bGlhIEF0bGFzDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDA0LCAyMDE1IDg6MTggQU0NClRvOiBW aXNobnUgUGF2YW4gQmVlcmFtOyB0ZWFzQGlldGYub3JnDQpTdWJqZWN0OiBbVGVhc10gVEVBUyBj aGFpcnMNCg0KSGkgVEVBUywNCg0KRnJvbSBXZWRzIGV2ZW5pbmcgb2YgSUVURi05MiwgRGVib3Jh aCB3aWxsIGJlIHNlcnZpbmcgYXMgUm91dGluZyBBRCBzbyBpdCBpc24ndCBhcHByb3ByaWF0ZSBm b3IgaGVyIHRvIGNvbnRpbnVlIHRvIGNoYWlyIGEgV0cgaW4gdGhlIFJvdXRpbmcgQXJlYS4gIFRo dXMsIERlYm9yYWggaXMgc3RlcHBpbmcgZG93biBhcyBjby1jaGFpciBvZiBTUFJJTkcuICBJIHJl YWxseSBhcHByZWNpYXRlIHRoZSBoYXJkIHdvcmsgdGhhdCBEZWJvcmFoIGhhcyBkb25lIGFzIFRF QVMgY28tY2hhaXIuDQoNCkkgaGF2ZSBjb25zdWx0ZWQgd2l0aCBBbHZhcm8sIERlYm9yYWgsIEFk cmlhbiwgYW5kIExvdSBCZXJnZXIsIGFuZCBoYXZlIGRlY2lkZWQgdG8gYXBwb2ludCBQYXZhbiBC ZWVyYW0gdG8gc2VydmUgaW4gdGhpcyByb2xlLiAgUGF2YW4gd2lsbCBiZSBidXN5IHJhbXBpbmcg dXAuICBJIGV4cGVjdCB0aGUgaGFuZG92ZXIgdG8gYmUgZmluaXNoZWQgaW4gRGFsbGFzLg0KDQpQ YXZhbiBjYW4gYmUgcmVhY2hlZCBhdCA8dmJlZXJhbUBqdW5pcGVyLm5ldDxtYWlsdG86dmJlZXJh bUBqdW5pcGVyLm5ldD4+Lg0KDQpUaGFua3MsDQpBbGlhDQo= --_000_7347100B5761DC41A166AC17F22DF1121B918817eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNpbmNlcmUgY29uZ3JhdHVsYXRpb25z IHRvIERlYm9yYWggYW5kIFBhdmFuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBU ZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5B bGlhIEF0bGFzPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMDQsIDIwMTUgODox OCBBTTxicj4NCjxiPlRvOjwvYj4gVmlzaG51IFBhdmFuIEJlZXJhbTsgdGVhc0BpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gVEVBUyBjaGFpcnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBURUFTLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5Gcm9tIFdlZHMgZXZlbmluZyBvZiBJ RVRGLTkyLCBEZWJvcmFoIHdpbGwgYmUgc2VydmluZyBhcyBSb3V0aW5nIEFEIHNvIGl0IGlzbid0 IGFwcHJvcHJpYXRlIGZvciBoZXIgdG8gY29udGludWUgdG8gY2hhaXIgYSBXRyBpbiB0aGUgUm91 dGluZyBBcmVhLiZuYnNwOyBUaHVzLCBEZWJvcmFoIGlzIHN0ZXBwaW5nIGRvd24gYXMgY28tY2hh aXIgb2YgU1BSSU5HLiZuYnNwOyBJIHJlYWxseQ0KIGFwcHJlY2lhdGUgdGhlIGhhcmQgd29yayB0 aGF0IERlYm9yYWggaGFzIGRvbmUgYXMgVEVBUyBjby1jaGFpci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5JIGhh dmUgY29uc3VsdGVkIHdpdGggQWx2YXJvLCBEZWJvcmFoLCBBZHJpYW4sIGFuZCBMb3UgQmVyZ2Vy LCBhbmQgaGF2ZSBkZWNpZGVkIHRvIGFwcG9pbnQgUGF2YW4gQmVlcmFtIHRvIHNlcnZlIGluIHRo aXMgcm9sZS4mbmJzcDsgUGF2YW4gd2lsbCBiZSBidXN5IHJhbXBpbmcgdXAuJm5ic3A7IEkgZXhw ZWN0IHRoZSBoYW5kb3ZlciB0byBiZSBmaW5pc2hlZCBpbiBEYWxsYXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ UGF2YW4gY2FuIGJlIHJlYWNoZWQgYXQgJmx0OzxhIGhyZWY9Im1haWx0bzp2YmVlcmFtQGp1bmlw ZXIubmV0Ij52YmVlcmFtQGp1bmlwZXIubmV0PC9hPiZndDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkFsaWE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B918817eusaamb103erics_-- From nobody Wed Mar 4 10:29:46 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7082E1AC401; Wed, 4 Mar 2015 10:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30tUhJWT1I7L; Wed, 4 Mar 2015 10:29:41 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30:5054:ff:fe5e:1643]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0F41A1BB1; Wed, 4 Mar 2015 10:29:41 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1YTE36-0006C3-4w; Wed, 04 Mar 2015 18:29:36 +0000 Message-ID: <54F74F12.3020205@folly.org.uk> Date: Wed, 04 Mar 2015 18:29:38 +0000 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Cyril Margaria References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> <54F5F635.2050304@folly.org.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gen-art@ietf.org, Lou Berger , draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , teas@ietf.org Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:29:44 -0000 On 04/03/2015 06:04, Cyril Margaria wrote: > Hi, > > Thanks for your review, > Please not that a new revision addressing IANA , APS-DIR and Gen-ART > comments on revision -02 is available. > https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 > > please see inline. Hi, Cyril. Yes: my comments and the new version crossed. However -03 doesn't significantly alter para 1 of s2.3. Firstly, I am far from expert in this area, so I have not much clue as to whether it would ever be useful or meaningful to associate an attribute with a Label rather than with the entity identified by the other subobject types. However, it has just occurred to me that with the loopback case, one needs to decide that if there are two labels, does loopback apply to both of them or just one? Arrrgggh! Perhaps something like the following, replacing the first two paras of s2.3, would cover all the bases and push the decision down to the document that defines the TLV(s)/flags used in the Hop attribute subobjects: OLD: As described in [RFC3209] and [RFC3473] the ERO is managed as a list where each hop information starts with a subobject identifying an abstract node or link. The ERO Hop Attributes subobject MAY be appended after any of the existing subobjects defined in [RFC3209], [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. Several ERO Hop Attributes subobject MAY be present, for each hop. Document defining specific Hop attribute TLV has to describe after which kind of subobject they are valid and if TLV modification rules applies. For instance, subobject presence rules can be defined by describing rules similar to [RFC4990] Section 6.1. NEW: As described in [RFC3209] the ERO is managed as a list of subobjects each identifying a specific entity, an abstract node or a link that defines a waypoint in the ERO route. Identifying subobjects of various types are defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO list by allowing one or two Label subobjects to be interposed in the list after a subobject identifying an entity by its IP address or interface identifier. One or more ERO Hop attributes subobjects applicable to a particular hop MAY be inserted directly after any of the existing identifying subobjects defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are present for a hop, the ERO Hop attributes subobject(s) MAY also be inserted after the Label subobjects. The attributes specified in a ERO Hop attributes subobject apply to the hop that ends at the route waypoint identified by the immediately preceding identifying subobject in the ERO subobject list. A document defining a specific Hop attribute TLV has to describe - after which kinds of subobject they are valid , - if ordering of the Hop attributes subobject and other subobjects associated with the same hop (e.g., Label subobjects) is significant, - if ordering is significant, how the attribute is interpreted in association with the preceding subobjects, and - any TLV modification rules that might apply. For instance, subobject presence rules can be defined by describing rules similar to [RFC4990] Section 6.1. This might require a few words added to s2.2 to specify that the ordering decision for individual flags is up to the definition of the flag. In turn that possibly means that the loopback draft needs to think about whether the loopback applies to both labels or only the one the loopback flag is after as mentioned above. Regards, Elwyn PS There is discussion about the .all aliases going to WG lists as well as relevant individuals. The long standing position was that they didn't but change has recently been mooted. /E > > > > > On 3 March 2015 at 12:58, Elwyn Davies wrote: > >> Hi. >> >> In the process of doing the gen-art review of >> draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at >> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments about >> ordering of subobjects in the loopback draft. >> >> I thought that the text in the first paragraph of s2.3: >> >> As described in [RFC3209 ] and [RFC3473 ] the ERO is managed as a list >> where each hop information starts with a subobject identifying an >> abstract node or link. The ERO Hop Attributes subobject MAY be >> appended after any of the existing subobjects defined in [RFC3209 ], >> [RFC3473 ], [RFC3477 ], [RFC4873 ], [RFC4874 ], [RFC5520 ] and [RFC5553 ]. >> Several ERO Hop Attributes subobject MAY be present, for each hop. >> >> was not very clear: The use of 'appended' was slightly confusing. I felt >> it needed something a bit closer to the "Presence Rules" that are given for >> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going >> on. >> >> I am not totally clear what would happen in the case of (say) an IPv4 >> address subobject followed by two Label subobjects. The wording seems to >> indicate that Hop attributes can be inserted anywhere in the sequence of >> three subobjects - but would they specifically apply to one or other Label >> if they were inserted after a Label or would they always apply generically >> to the hop terminated at the IPv4 address entity? >> >> > draft-ietf-teas-lsp-attribute-ro tries to leave that open to the documents > defining the TLVs. We are not excluding an Attribute that applies to a > Label or Interface. If the subobject would be inserted after a Label > Subobject, the Attribute TLVs would apply to the Labels. > > This is based on the following review comment:" > I think *this* I-D needs to make it clear what the expectations are: > > 1. The sub-object is allowed at any point in the ERO > 2. The document that specifies a TLV for the sub-object must make it > clear where in an ERO a sub-object containing that TLV is allowed and > not allowed." > > Do you think this is reasonable or we should exclude TLVs scoped to labels? > In the latter case, I would add you suggested text. > > Best Regards. > Cyril > > PS: It seems there are errors with the tools.ietf.org aliases > > >> My suggestion for rewording, based on the assumption that the hop >> attributes apply to the hop rather than any of the labels, would be: >> >> As described in [RFC3209] the ERO is managed as a list of subobjects >> each identifying a specific entity, an abstract node or a link. >> Identifying >> subobjects of various types are defined in [RFC3209], [RFC3477], >> [RFC4873], >> [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO list by >> allowing one or two Label subobjects to be interposed in the list after >> a >> subobject identifying an entity by its IP address or interface >> identifier. One >> or more ERO Hop attributes subobjects applicable to a particular hop >> MAY >> be inserted after any of the existing identifying subobjects defined in >> [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. >> If any Label subobjects are present for a hop, the ERO Hop attributes >> subobject(s) MUST be inserted after the Label subobjects. >> >> The last two sentences would need to be altered if Hop attributes were >> applicable to Labels rather than just to the hop as a whole. >> >> Regards, >> Elwyn >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> From nobody Wed Mar 4 10:46:37 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD261AC406; Wed, 4 Mar 2015 10:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttnJKD_yAypa; Wed, 4 Mar 2015 10:46:33 -0800 (PST) Received: from auth.a.painless.aa.net.uk (a.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EDB1A872A; Wed, 4 Mar 2015 10:46:33 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by a.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1YTEJO-0005J8-AI; Wed, 04 Mar 2015 18:46:30 +0000 Message-ID: <54F75304.706@folly.org.uk> Date: Wed, 04 Mar 2015 18:46:28 +0000 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: General area reviewing team , "draft-ietf-teas-rsvp-te-li-lb.all" , teas@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Teas] [Gen-art] Gen-art telechat review of draft-ietf-teas-rsvp-te-li-lb-04.txt (updated) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 18:46:36 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-teas-rsvp-te-li-lb-04.txt Reviewer: Elwyn Davies Review Date: 2015/03/03 IETF LC End Date: 2015/02/18 IESG Telechat date: 20150305 Summary: Almost ready for PS. I noticed at a late stage in the last call reviewing process that the requirement that the hop before a loopback node should be a strict hop was unnecessary. The draft editor, Dong Jie, has agreed that this is the case and is checking that the removal of this constraint is acceptable to the other authors. There is one other outstanding fix agreed for a nit. Otherwise all my last call comments have been cleared. Thanks. An additional minor issue about labels has come to light. See below. Major issues: None Minor issues: s3.2, para 2, et seq: The requirement that the hop before the loopback entity MUST be a strict hop is unnecessary. The essential constraint (which is fully specified in the -04 draft) is that the entity at which loopback is to occur has to be uniquely identified (i.e., it can't be an 'abstract node' signifying (potentially) a group of nodes, such as an AS). I have discussed this with Dong Jie, as editor, and he has agreed that the constraint is not needed. A new version of the draft removing the constraint is in hand, pending agreement with the other authors and checking with the WG. s3.2: If dealing with a bidirectional LSP as per RFC 3473, and the ERO waypoint (say, an IPv4 address) is qualified with two Label subobjects, does loopback put BOTH paths into loopback? Alternatively, the loopback flag could be defined so that it applies to only one of the Labels if the ERO Hop attribute subobject is placed after the Label or to both if it is placed immediately after the identifying subobject (in this case the IPv4 address subobject). Nits/editorial comments: s3.2, para 3: OLD : Currently, the type value MUST be verified to be less than 32, and for type values 1 and 2, the prefix length MUST be 32 and 128 respectively. NEW: Currently, the type value MUST be verified to be less than 32 (i.e., able to identify a specific entity where a loopback can occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 (IPv6 address), the prefix length MUST be 32 and 128 respectively. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Mar 4 11:09:10 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F091ACE2D for ; Wed, 4 Mar 2015 11:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvI4MQtinOaO for ; Wed, 4 Mar 2015 11:09:07 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13D1ACE2A for ; Wed, 4 Mar 2015 11:09:07 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Alia Atlas'" , "'Vishnu Pavan Beeram'" , References: In-Reply-To: Date: Wed, 4 Mar 2015 14:08:58 -0500 Message-ID: <063801d056ae$ab8b0f60$02a12e20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0639_01D05684.C2B5CAB0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQFd+sZkUNXf+NmMyeGU4Vw2TCvmDJ3xZ6gw X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Teas] TEAS chairs X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:09:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0639_01D05684.C2B5CAB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Congratulations to Pavan. Deborah =E2=80=93 we=E2=80=99re glad = you=E2=80=99ve joined the Routing ADs.=20 =20 Sue=20 =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Wednesday, March 04, 2015 11:18 AM To: Vishnu Pavan Beeram; teas@ietf.org Subject: [Teas] TEAS chairs =20 Hi TEAS, =20 >From Weds evening of IETF-92, Deborah will be serving as Routing AD so = it isn't appropriate for her to continue to chair a WG in the Routing = Area. Thus, Deborah is stepping down as co-chair of SPRING. I really = appreciate the hard work that Deborah has done as TEAS co-chair. =20 I have consulted with Alvaro, Deborah, Adrian, and Lou Berger, and have = decided to appoint Pavan Beeram to serve in this role. Pavan will be = busy ramping up. I expect the handover to be finished in Dallas. =20 Pavan can be reached at . =20 Thanks, Alia ------=_NextPart_000_0639_01D05684.C2B5CAB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Congratulations to Pavan.=C2=A0 Deborah =E2=80=93 we=E2=80=99re glad = you=E2=80=99ve joined the Routing ADs.

 

Sue

 

From:= = Teas [mailto:teas-bounces@ietf.org] On Behalf Of Alia = Atlas
Sent: Wednesday, March 04, 2015 11:18 AM
To: = Vishnu Pavan Beeram; teas@ietf.org
Subject: [Teas] TEAS = chairs

 

Hi = TEAS,

 

From Weds evening of = IETF-92, Deborah will be serving as Routing AD so it isn't appropriate = for her to continue to chair a WG in the Routing Area.  Thus, = Deborah is stepping down as co-chair of SPRING.  I really = appreciate the hard work that Deborah has done as TEAS = co-chair.

 

I have consulted with = Alvaro, Deborah, Adrian, and Lou Berger, and have decided to appoint = Pavan Beeram to serve in this role.  Pavan will be busy ramping = up.  I expect the handover to be finished in = Dallas.

 

Pavan can be reached = at <vbeeram@juniper.net>.

 

Thanks,

Alia

------=_NextPart_000_0639_01D05684.C2B5CAB0-- From nobody Wed Mar 4 11:32:21 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAF71A87EF for ; Wed, 4 Mar 2015 11:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCB143nO3iMV for ; Wed, 4 Mar 2015 11:32:19 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011E71A87D2 for ; Wed, 4 Mar 2015 11:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4174; q=dns/txt; s=iport; t=1425497539; x=1426707139; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4MlXxpK79IrdttS8VyLAbKBZOJRkYx/Tx0/De/lfaIs=; b=Q0w9EeqOlzJE8r9qVYsvX4bZ31OIJh23okaJmrziN2SYMxyjE1McKzvB h+/543Yv7BynaCLNepXmIimH0TwXV5uefRACgXzhY4WJCLU1y0gNlpnUs I+UahKiyvxJRp1GbNeP44Bx1QFwN42QF+VmFwFkyb4lY9XbNxHHOPBG7j I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BmBgBJXfdU/51dJa1agj9DgSwEuyGLagKBLk0BAQEBAQF8hA8BAQEEgQkCAQgECgMDAQIoByERFAkIAgQBEogbAxHSRQ2FHgEBAQEBAQEDAQEBAQEBAQEaixKCRIIZGIQrBZADiAWBSI1bhg8jg25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,689,1418083200"; d="scan'208,217";a="128947579" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 04 Mar 2015 19:32:18 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t24JWI34026958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Mar 2015 19:32:18 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 4 Mar 2015 13:32:17 -0600 From: "Tarek Saad (tsaad)" To: Alia Atlas , Vishnu Pavan Beeram , "teas@ietf.org" Thread-Topic: [Teas] TEAS chairs Thread-Index: AQHQVqGkG4FpNjy/RE2LUflsOdMNpZ0Mx1wA Date: Wed, 4 Mar 2015 19:32:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.86.254.247] Content-Type: multipart/alternative; boundary="_000_D11CC79017AF74tsaadciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] TEAS chairs X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 19:32:20 -0000 --_000_D11CC79017AF74tsaadciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Congratulation Pavan and Deborah. Regards, Tarek From: Alia Atlas > Date: Wednesday, March 4, 2015 at 11:18 AM To: Vishnu Pavan Beeram >, = "teas@ietf.org" > Subject: [Teas] TEAS chairs Hi TEAS, >From Weds evening of IETF-92, Deborah will be serving as Routing AD so it i= sn't appropriate for her to continue to chair a WG in the Routing Area. Th= us, Deborah is stepping down as co-chair of SPRING. I really appreciate th= e hard work that Deborah has done as TEAS co-chair. I have consulted with Alvaro, Deborah, Adrian, and Lou Berger, and have dec= ided to appoint Pavan Beeram to serve in this role. Pavan will be busy ram= ping up. I expect the handover to be finished in Dallas. Pavan can be reached at >. Thanks, Alia --_000_D11CC79017AF74tsaadciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1D8CA2639C8FE14CBE4DB877F46FB871@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Congratulation Pavan and Deborah.

Regards,
Tarek

From: Alia Atlas <akatlas@gmail.com>
Date: Wednesday, March 4, 2015 at 1= 1:18 AM
To: Vishnu Pavan Beeram <vbeeram@juniper.net>, "teas@ietf.org" <teas@ietf.org>
Subject: [Teas] TEAS chairs

Hi TEAS,

From Weds evening of IETF-92, D= eborah will be serving as Routing AD so it isn't appropriate for her to con= tinue to chair a WG in the Routing Area.  Thus, Deborah is stepping do= wn as co-chair of SPRING.  I really appreciate the hard work that Deborah has done as TEAS co-chair.

I have consulted with Alvaro, D= eborah, Adrian, and Lou Berger, and have decided to appoint Pavan Beeram to= serve in this role.  Pavan will be busy ramping up.  I expect th= e handover to be finished in Dallas.

Pavan can be r= eached at <vbeeram@juniper.net>.

Thanks,
Alia
 --_000_D11CC79017AF74tsaadciscocom_-- From nobody Wed Mar 4 13:57:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1311A898F for ; Wed, 4 Mar 2015 13:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSSUVxpJccbQ for ; Wed, 4 Mar 2015 13:57:18 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 72D831A8978 for ; Wed, 4 Mar 2015 13:57:18 -0800 (PST) Received: (qmail 2005 invoked by uid 0); 4 Mar 2015 21:57:17 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 4 Mar 2015 21:57:17 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id zgvB1p00L2SSUrH01gwE6L; Wed, 04 Mar 2015 21:56:17 -0700 X-Authority-Analysis: v=2.1 cv=GubRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=a4nQRbIO7Hawz3UkNsIA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ms18Hw7YeFMksgXBJWj+6KWMr7iqTcnoB1/4qHcU9sY=; b=cFpE9ihMnRZcl1dpj/OHYYY8xcZTGJEfVFRsRl6exIeQnWkRGGTsejt+TlfzLjyRGMkxHV4Ddrt88afHHHyKxvZ8HAsqHVbMJB12C3qx/OVb5TRhwqa9fmj9tc1hBeEx; Received: from box313.bluehost.com ([69.89.31.113]:33275 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTDW4-0008Or-4m; Wed, 04 Mar 2015 10:55:28 -0700 Message-ID: <54F7470A.7090905@labn.net> Date: Wed, 04 Mar 2015 12:55:22 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: teas@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Vishnu Pavan Beeram , "BRUNGARD, DEBORAH A \(ATTLABS\)" , Alia Atlas Subject: Re: [Teas] TEAS chairs X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:57:19 -0000 WG, I want to personally and publicly thank Deborah for all of her hard work over the years she chaired CCAMP (and now TEAS). While I/we will miss her in her old role, she isn't going far in her new role -- so I hope and expect that we all will continue to benefit from her active contribution to and guidance of the WG. Of course, I also want to welcome Pavan.=20 As Alia stated, we'll be working transition over the next few weeks to ensure handover is complete in Dallas. Lou On 3/4/2015 11:18 AM, Alia Atlas wrote: > Hi TEAS, > > From Weds evening of IETF-92, Deborah will be serving as Routing AD so > it isn't appropriate for her to continue to chair a WG in the Routing > Area.=C2 Thus, Deborah is stepping down as co-chair of SPRING.=C2 I > really appreciate the hard work that Deborah has done as TEAS co-chair.= > > I have consulted with Alvaro, Deborah, Adrian, and Lou Berger, and > have decided to appoint Pavan Beeram to serve in this role.=C2 Pavan > will be busy ramping up.=C2 I expect the handover to be finished in Da= llas. > > Pavan can be reached at >. > > Thanks, > Alia > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Mar 4 19:28:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C89D1A8ACA; Wed, 4 Mar 2015 19:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZCLGwYvbYX5; Wed, 4 Mar 2015 19:28:35 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69BD1A1BEC; Wed, 4 Mar 2015 19:28:34 -0800 (PST) Received: by widex7 with SMTP id ex7so35257523wid.0; Wed, 04 Mar 2015 19:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yEdzlBpAjP6JyFpgXutPtux/jJHAw1omqP6y2lrNvq4=; b=lrDafPpsRBzr6df2l/ox5LKHPTQRcsrB/LcjRAWnPVztgDIE/6HYJtGYzWqbQOdnOv JflQk5JC9/THL7Lly68H8T874xEVe0+W8av8G1pD8YZnYIeMDkokLBU3OfwF1yy7RT8E 9xq1hFyaU9ZJMH0iQNoipx8eB4IV7rU6a5Wtkh+zyL30u8vwBplM3B0OmyTr458UE1f5 2SF4+LX0YJ8cSSLdZIWJP29Ujq5idDeeG4tReClPYnuJECl27Zjbj9wJDSG3R36PIlw+ pO5JcFCDn//qbgpLAYUKADaZo1mAyHOhrCDloB+7+45WQ/hQuuRtx1ghwK/w059suVxI 2g+A== MIME-Version: 1.0 X-Received: by 10.180.102.73 with SMTP id fm9mr18937233wib.12.1425526113713; Wed, 04 Mar 2015 19:28:33 -0800 (PST) Received: by 10.27.51.145 with HTTP; Wed, 4 Mar 2015 19:28:33 -0800 (PST) In-Reply-To: <54F74F12.3020205@folly.org.uk> References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> <54F5F635.2050304@folly.org.uk> <54F74F12.3020205@folly.org.uk> Date: Wed, 4 Mar 2015 22:28:33 -0500 Message-ID: From: Cyril Margaria To: Elwyn Davies Content-Type: multipart/alternative; boundary=f46d0444e8eda0467105108229eb Archived-At: Cc: gen-art@ietf.org, Lou Berger , draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , teas@ietf.org Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 03:28:39 -0000 --f46d0444e8eda0467105108229eb Content-Type: text/plain; charset=UTF-8 Hi, Thanks for the quick feedback, Would the following text modification address your comments . the wording is a bit different, I tried to simplify the description of the TLV scope. As described in [RFC3209] the ERO is managed as a list of subobjects each identifying a specific entity, an abstract node or a link that defines a waypoint in the network path. Identifying subobjects of various types are defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO list by allowing one or two Label subobjects to be interposed in the list after a subobject identifying a link. One or more ERO Hop Attributes subobjects applicable to a particular hop MAY be inserted directly after any of the existing identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are present for a hop, the ERO Hop Attributes subobject(s) MAY also be inserted after the Label subobjects. The attributes specified in a ERO Hop Attributes subobject apply to the immediately preceding subobject(s) in the ERO subobject list. A document defining a specific Hop Attribute TLV has to describe: o after which kinds of ERO subobject they are valid , o if ordering of the Hop Attributes subobject and other ERO subobjects associated with the same hop (e.g., Label subobjects) is significant, o if ordering is significant, how the attribute is interpreted in association with the preceding ERO subobjects, and o any TLV modification rules that might apply. For instance, subobject presence rules can be defined by describing rules similar to [RFC4990] Section 6.1. That would allow a TLV to apply to one (or more) preceding subobject, the type of subobject being left to the TLV. Regarding section 2.2, the following text is proposed: The presence and ordering rule of the Attribute Flags TLV in an ERO Hop Attributes Subobject is defined by each Flag. A document defining a Flag to be used in a Attribute Flags TLV carried in the ERO Hop Attributes Subobject has to describe: o after which kinds of ERO subobject the Flag is valid o if ordering of the Flag and other ERO subobjects associated with the same hop (e.g., Label subobjects) is significant, o if ordering is significant, how the Flag is interpreted in association with the preceding subobjects, o any Flag modification rules that might apply. If its Ok, I can post a new revision shortly. Best Regards Cyril On 4 March 2015 at 13:29, Elwyn Davies wrote: > > > On 04/03/2015 06:04, Cyril Margaria wrote: > >> Hi, >> >> Thanks for your review, >> Please not that a new revision addressing IANA , APS-DIR and Gen-ART >> comments on revision -02 is available. >> https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 >> >> please see inline. >> > Hi, Cyril. > > Yes: my comments and the new version crossed. > > However -03 doesn't significantly alter para 1 of s2.3. > > Firstly, I am far from expert in this area, so I have not much clue as to > whether it would ever be useful or meaningful to associate an attribute > with a Label rather than with the entity identified by the other subobject > types. However, it has just occurred to me that with the loopback case, > one needs to decide that if there are two labels, does loopback apply to > both of them or just one? Arrrgggh! > > Perhaps something like the following, replacing the first two paras of > s2.3, would cover all the bases and push the decision down to the document > that defines the TLV(s)/flags used in the Hop attribute subobjects: > > OLD: > As described in [RFC3209] and [RFC3473] the ERO is managed as a list > where each hop information starts with a subobject identifying an > abstract node or link. The ERO Hop Attributes subobject MAY be > appended after any of the existing subobjects defined in [RFC3209], > [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. > Several ERO Hop Attributes subobject MAY be present, for each hop. > > Document defining specific Hop attribute TLV has to describe after > which kind of subobject they are valid and if TLV modification rules > applies. For instance, subobject presence rules can be defined by > describing rules similar to [RFC4990] Section 6.1. > > NEW: > As described in [RFC3209] the ERO is managed as a list of subobjects > each identifying a specific entity, an abstract node or a link that > defines > a waypoint in the ERO route. Identifying subobjects of various types > are > defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and > [RFC5553]. > > [RFC3473] modified the ERO list by allowing one or two Label subobjects > to be interposed in the list after a subobject identifying an entity by > its > IP address or interface identifier. One or more ERO Hop attributes > subobjects applicable to a particular hop MAY be inserted directly after > any of the existing identifying subobjects defined in [RFC3209], > [RFC3477], > [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects > are present for a hop, the ERO Hop attributes subobject(s) MAY also be > inserted after the Label subobjects. > > The attributes specified in a ERO Hop attributes subobject apply to the > hop > that ends at the route waypoint identified by the immediately preceding > identifying subobject in the ERO subobject list. > > A document defining a specific Hop attribute TLV has to describe > - after which kinds of subobject they are valid , > - if ordering of the Hop attributes subobject and other subobjects > associated with the same hop (e.g., Label subobjects) is > significant, > - if ordering is significant, how the attribute is interpreted in > association with the preceding subobjects, and > - any TLV modification rules that might apply. > For instance, subobject presence rules can be defined by describing > rules > similar to [RFC4990] Section 6.1. > > This might require a few words added to s2.2 to specify that the ordering > decision for individual flags is up to the definition of the flag. In turn > that possibly means that the loopback draft needs to think about whether > the loopback applies to both labels or only the one the loopback flag is > after as mentioned above. > > Regards, > Elwyn > > PS > There is discussion about the .all aliases going to WG lists as well as > relevant individuals. The long standing position was that they didn't but > change has recently been mooted. > > /E > > >> >> >> >> On 3 March 2015 at 12:58, Elwyn Davies wrote: >> >> Hi. >>> >>> In the process of doing the gen-art review of >>> draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at >>> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments >>> about >>> ordering of subobjects in the loopback draft. >>> >>> I thought that the text in the first paragraph of s2.3: >>> >>> As described in [RFC3209 ] and >>> [RFC3473 ] the ERO is managed as a >>> list >>> where each hop information starts with a subobject identifying an >>> abstract node or link. The ERO Hop Attributes subobject MAY be >>> appended after any of the existing subobjects defined in [RFC3209 < >>> https://tools.ietf.org/html/rfc3209>], >>> [RFC3473 ], [RFC3477 < >>> https://tools.ietf.org/html/rfc3477>], [RFC4873 < >>> https://tools.ietf.org/html/rfc4873>], [RFC4874 < >>> https://tools.ietf.org/html/rfc4874>], [RFC5520 < >>> https://tools.ietf.org/html/rfc5520>] and [RFC5553 < >>> https://tools.ietf.org/html/rfc5553>]. >>> >>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>> >>> was not very clear: The use of 'appended' was slightly confusing. I >>> felt >>> it needed something a bit closer to the "Presence Rules" that are given >>> for >>> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going >>> on. >>> >>> I am not totally clear what would happen in the case of (say) an IPv4 >>> address subobject followed by two Label subobjects. The wording seems to >>> indicate that Hop attributes can be inserted anywhere in the sequence of >>> three subobjects - but would they specifically apply to one or other >>> Label >>> if they were inserted after a Label or would they always apply >>> generically >>> to the hop terminated at the IPv4 address entity? >>> >>> >>> draft-ietf-teas-lsp-attribute-ro tries to leave that open to the >> documents >> defining the TLVs. We are not excluding an Attribute that applies to a >> Label or Interface. If the subobject would be inserted after a Label >> Subobject, the Attribute TLVs would apply to the Labels. >> >> This is based on the following review comment:" >> I think *this* I-D needs to make it clear what the expectations are: >> >> 1. The sub-object is allowed at any point in the ERO >> 2. The document that specifies a TLV for the sub-object must make it >> clear where in an ERO a sub-object containing that TLV is allowed and >> not allowed." >> >> Do you think this is reasonable or we should exclude TLVs scoped to >> labels? >> In the latter case, I would add you suggested text. >> >> Best Regards. >> Cyril >> >> PS: It seems there are errors with the tools.ietf.org aliases >> >> >> My suggestion for rewording, based on the assumption that the hop >>> attributes apply to the hop rather than any of the labels, would be: >>> >>> As described in [RFC3209] the ERO is managed as a list of subobjects >>> each identifying a specific entity, an abstract node or a link. >>> Identifying >>> subobjects of various types are defined in [RFC3209], [RFC3477], >>> [RFC4873], >>> [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO list >>> by >>> allowing one or two Label subobjects to be interposed in the list >>> after >>> a >>> subobject identifying an entity by its IP address or interface >>> identifier. One >>> or more ERO Hop attributes subobjects applicable to a particular hop >>> MAY >>> be inserted after any of the existing identifying subobjects defined >>> in >>> [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. >>> If any Label subobjects are present for a hop, the ERO Hop attributes >>> subobject(s) MUST be inserted after the Label subobjects. >>> >>> The last two sentences would need to be altered if Hop attributes were >>> applicable to Labels rather than just to the hop as a whole. >>> >>> Regards, >>> Elwyn >>> >>> >>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org >>> https://www.ietf.org/mailman/listinfo/teas >>> >>> >>> > --f46d0444e8eda0467105108229eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the quick feedback,=
Would the following text modification address your comments= .
the wording is a bit different, I tried to simplify the descrip= tion of the TLV scope. 

   As described in [RFC3209] =
the ERO is managed as a list of subobjects
   each identifying a specific entity, an abstract node or a link that
   defines a waypoint in the network path.  Identifying subobjects of
   various types are defined in [RFC3209], [RFC3477], [RFC4873],
   [RFC4874], [RFC5520] and [RFC5553].

   [RFC3473] modified the ERO list by allowing one or two Label
   subobjects to be interposed in the list after a subobject identifying
   a link.  One or more ERO Hop Attributes subobjects applicable to a
   particular hop MAY be inserted directly after any of the existing
   identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873],
   [RFC4874], [RFC5520] and [RFC5553].  If any Label subobjects are
   present for a hop, the ERO Hop Attributes subobject(s) MAY also be
   inserted after the Label subobjects.

   The attributes specified in a ERO Hop Attributes subobject apply to
   the immediately preceding subobject(s) in the ERO subobject list.

   A document defining a specific Hop Attribute TLV has to describe:

   o  after which kinds of ERO subobject they are valid ,

   o  if ordering of the Hop Attributes subobject and other ERO
      subobjects associated with the same hop (e.g., Label subobjects)
      is significant,

   o  if ordering is significant, how the attribute is interpreted in
      association with the preceding ERO subobjects, and

   o  any TLV modification rules that might apply.

   For instance, subobject presence rules can be defined by describing
   rules similar to [RFC4990] Section 6.1.

Th= at would allow a TLV to apply to one (or more) preceding subobject, the typ= e of subobject being left to the TLV.

Regarding section 2= .2, the following text is proposed:

   The presence and orderin=
g rule of the Attribute Flags TLV in an ERO
   Hop Attributes Subobject is defined by each Flag.  A document
   defining a Flag to be used in a Attribute Flags TLV carried in the
   ERO Hop Attributes Subobject has to describe:

   o  after which kinds of ERO subobject the Flag is valid

   o  if ordering of the Flag and other ERO subobjects associated with
      the same hop (e.g., Label subobjects) is significant,

   o  if ordering is significant, how the Flag is interpreted in
      association with the preceding subobjects,

   o  any Flag modification rules that might apply.
If its Ok, I can post a new revision shortly.

Best = Regards
Cyril



On 4 March 20= 15 at 13:29, Elwyn Davies <elwynd@folly.org.uk> wrote:
=


On 04/03/2015 06:04, Cyril Margaria wrote:
Hi,

Thanks for your review,
Please not that a new revision addressing IANA , APS-DIR and Gen-ART
comments=C2=A0 on revision -02 is available.
https://tools.ietf.org/html/draft-ietf-teas-lsp-a= ttribute-ro-03

=C2=A0 please see inline.
 Hi, Cyril.

Yes:=C2=A0 my comments and the new version crossed.

However -03 doesn't significantly alter para 1 of s2.3.

Firstly, I am far from expert in this area, so I have not much clue as to w= hether it would ever be useful or meaningful to associate an attribute with= a Label rather than with the entity identified by the other subobject type= s.=C2=A0 However, it has just occurred to me that with the loopback case, o= ne needs to=C2=A0 decide that if there are two labels, does loopback apply = to both of them or just one?=C2=A0 Arrrgggh!

Perhaps something like the following, replacing the first two paras of s2.3= , would cover all the bases and push the decision down to the document that= defines the TLV(s)/flags used in the Hop attribute subobjects:

OLD:
=C2=A0 =C2=A0As described in [RFC3209] and [RFC3473] the ERO is managed as = a list
=C2=A0 =C2=A0where each hop information starts with a subobject identifying= an
=C2=A0 =C2=A0abstract node or link.=C2=A0 The ERO Hop Attributes subobject = MAY be
=C2=A0 =C2=A0appended after any of the existing subobjects defined in [RFC3= 209],
=C2=A0 =C2=A0[RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC= 5553].
=C2=A0 =C2=A0Several ERO Hop Attributes subobject MAY be present, for each = hop.

 =C2=A0 =C2=A0Document defining specific Hop attribute TLV has to describe a= fter
=C2=A0 =C2=A0which kind of subobject they are valid and if TLV modification= rules
=C2=A0 =C2=A0applies.=C2=A0 For instance, subobject presence rules can be d= efined by
=C2=A0 =C2=A0describing rules similar to [RFC4990] Section 6.1.

NEW:
=C2=A0 =C2=A0As described in [RFC3209] the ERO is managed as a list of subo= bjects
 =C2=A0 =C2=A0each identifying a specific entity, an abstract node or a link= that defines
=C2=A0 =C2=A0a waypoint in the ERO route.=C2=A0 Identifying subobjects of v= arious types are
=C2=A0 =C2=A0defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC552= 0] and
=C2=A0 =C2=A0[RFC5553].

=C2=A0 =C2=A0[RFC3473] modified the ERO list by allowing one or two Label s= ubobjects
=C2=A0 =C2=A0to be interposed in the list after a subobject identifying an = entity by its
=C2=A0 =C2=A0IP address or interface identifier.=C2=A0 =C2=A0One or more ER= O Hop attributes
 =C2=A0 =C2=A0subobjects applicable to a particular hop MAY be inserted dire= ctly after
=C2=A0 =C2=A0any of the existing identifying subobjects defined in [RFC3209= ], [RFC3477],
=C2=A0 =C2=A0[RFC4873], [RFC4874], [RFC5520] and [RFC5553].=C2=A0 If any La= bel subobjects
 =C2=A0 =C2=A0are present for a hop, the ERO Hop attributes subobject(s) MAY= also be
=C2=A0 =C2=A0inserted after the Label subobjects.

 =C2=A0 =C2=A0The attributes specified in a ERO Hop attributes subobject app= ly to the hop
=C2=A0 =C2=A0that ends at the route waypoint identified by the immediately = preceding
=C2=A0 =C2=A0identifying subobject in the ERO subobject list.

=C2=A0 =C2=A0A document defining a specific Hop attribute TLV has to descri= be
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 after which kinds of subobject they are valid = ,
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 if ordering of the Hop attributes subobject an= d other subobjects
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated with the same hop (e.g., Label= subobjects) is significant,
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 if ordering is significant, how the attribute = is interpreted in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0association with the preceding subobjects= , and
=C2=A0 =C2=A0 =C2=A0 -=C2=A0 any TLV modification rules that might apply. =C2=A0 =C2=A0For instance, subobject presence rules can be defined by descr= ibing rules
=C2=A0 =C2=A0similar to [RFC4990] Section 6.1.

This might require a few words added to s2.2 to specify that the ordering d= ecision for individual flags is up to the definition of the flag.=C2=A0 In = turn that possibly means that the loopback draft needs to think about wheth= er the loopback applies to both labels or only the one the loopback flag is= after as mentioned above.

Regards,
Elwyn

PS
There is discussion about the .all aliases going to WG lists as well as rel= evant individuals.=C2=A0 The long standing position was that they didn'= t but change has recently been mooted.

/E





On 3 March 2015 at 12:58, Elwyn Davies <elwynd@folly.org.uk> wrote:

=C2=A0 Hi.

In the process of doing the gen-art review of
draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at
draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments= about
ordering of subobjects in the loopback draft.

I thought that the text in the first paragraph of s2.3:

 =C2=A0 =C2=A0 As described in [RFC3209 <https://tools.ietf.org/html/rfc320= 9>] and [RFC3473 <https://tools.ietf.org/html/rfc3473>] the = ERO is managed as a list
=C2=A0 =C2=A0 where each hop information starts with a subobject identifyin= g an
=C2=A0 =C2=A0 abstract node or link.=C2=A0 The ERO Hop Attributes subobject= MAY be
 =C2=A0 =C2=A0 appended after any of the existing subobjects defined in [RFC= 3209 <= https://tools.ietf.org/html/rfc3209>],
=C2=A0 =C2=A0 [RFC3473 <https://tools.ietf.org/html/rfc3473>], [RFC= 3477 <= https://tools.ietf.org/html/rfc3477>], [RFC4873 <https://tools.ie= tf.org/html/rfc4873>], [RFC4874 <https://tools.ietf.org/html/rfc4874>], [RFC5520 <https://tools.ietf.org/html/rfc5520>] = and [RFC5553 <https://tools.ietf.org/html/rfc5553>].

=C2=A0 =C2=A0 Several ERO Hop Attributes subobject MAY be present, for each= hop.

=C2=A0 was not very clear: The use of 'appended' was slightly confu= sing.=C2=A0 I felt
it needed something a bit closer to the "Presence Rules" that are= given for
RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going
on.

I am not totally clear what would happen in the case of (say) an IPv4
address subobject followed by two Label subobjects.=C2=A0 The wording seems= to
indicate that Hop attributes can be inserted anywhere in the sequence of three subobjects - but would they specifically apply to one or other Label<= br> if they were inserted after a Label or would they always apply generically<= br> to the hop terminated at the IPv4 address entity?


draft-ietf-teas-lsp-attribute-ro tries to leave that open to the doc= uments
defining the TLVs. We are not excluding an Attribute that applies to a
Label or Interface. If the subobject would be inserted after a Label
Subobject, the Attribute TLVs would apply to the Labels.

This is based on the following review comment:"
I think *this* I-D needs to make it clear what the expectations are:

1. The sub-object is allowed at any point in the ERO
2. The document that specifies a TLV for the sub-object must make it
=C2=A0 =C2=A0 clear where in an ERO a sub-object containing that TLV is all= owed and
=C2=A0 =C2=A0 not allowed."

Do you think this is reasonable or we should exclude TLVs scoped to labels?=
In the latter case, I would add you suggested text.

Best Regards.
Cyril

PS: It seems there are errors with the tools.ietf.org aliases


My suggestion for rewording, based on the assumption that the hop
attributes apply to the hop rather than any of the labels, would be:

=C2=A0 =C2=A0 As described in [RFC3209] the ERO is managed as a list of sub= objects
=C2=A0 =C2=A0 each identifying a specific entity, an abstract node or a lin= k.
Identifying
=C2=A0 =C2=A0 subobjects of various types are defined in [RFC3209], [RFC347= 7],
[RFC4873],
=C2=A0 =C2=A0 [RFC4874], [RFC5520] and [RFC5553].=C2=A0 [RFC3473] modified = the ERO list by
=C2=A0 =C2=A0 allowing one or two Label subobjects to be interposed in the = list after
a
=C2=A0 =C2=A0 subobject identifying an entity by its IP address or interfac= e
identifier.=C2=A0 =C2=A0One
=C2=A0 =C2=A0 or more ERO Hop attributes subobjects applicable to a particu= lar hop
MAY
=C2=A0 =C2=A0 be inserted after any of the existing identifying subobjects = defined in
=C2=A0 =C2=A0 [RFC3209],=C2=A0 [RFC3477], [RFC4873], [RFC4874], [RFC5520] a= nd [RFC5553].
=C2=A0 =C2=A0 If any Label subobjects are present for a hop, the ERO Hop at= tributes
=C2=A0 =C2=A0 subobject(s) MUST be inserted after the Label subobjects.

The last two sentences would need to be altered if Hop attributes were
applicable to Labels rather than just to the hop as a whole.

Regards,
Elwyn



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas




--f46d0444e8eda0467105108229eb-- From nobody Wed Mar 4 19:59:40 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13691A8AFC for ; Wed, 4 Mar 2015 19:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJbkPjgiWLm1 for ; Wed, 4 Mar 2015 19:59:37 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D6C1A8BC3 for ; Wed, 4 Mar 2015 19:59:37 -0800 (PST) Received: by qcrw7 with SMTP id w7so41044160qcr.4 for ; Wed, 04 Mar 2015 19:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A2TrGzS1AM20DVgd9nYncfeIT3L2+kzCRkdKCtE7Tk8=; b=ToizfTvZX52TY1KEHs4lQuUWcAxBYNFpVid/3wkWVFOWNboDhnbywBaRbJrmOUOkrh eDVSUfXIhPPUebfpHbc1sC+8eCl4q+fiQh12RF+ClnlRINrPkPH3ArJXZjX1ibM7clOB ZWXdMH7O9Phbirl9KS0RPO8X/iZYZxruQ4zI5lgj+v4CeIEXXdWJXT1d0dzOFukowIhp HFkKgIpfy2alpwCV8vjK2ei/V7uF6W7NOkvStGmmX6W+co4SGPfa22BVonX1cfYSlhF8 RuiLt9dHz8jBYjzHQa2Vtx2VxPzDmsBgj+pfpC+9A/5QOJTd7P3cVdAglmXN8mAMPEzV 3Ayg== MIME-Version: 1.0 X-Received: by 10.55.23.130 with SMTP id 2mr14131048qkx.78.1425527976852; Wed, 04 Mar 2015 19:59:36 -0800 (PST) Received: by 10.140.85.227 with HTTP; Wed, 4 Mar 2015 19:59:36 -0800 (PST) In-Reply-To: <54F7470A.7090905@labn.net> References: <54F7470A.7090905@labn.net> Date: Wed, 4 Mar 2015 22:59:36 -0500 Message-ID: From: Vishnu Pavan Beeram To: Lou Berger Content-Type: multipart/alternative; boundary=001a1147b1daad83f605108298e6 Archived-At: Cc: Alia Atlas , "BRUNGARD, DEBORAH A \(ATTLABS\)" , "teas@ietf.org" , Vishnu Pavan Beeram Subject: Re: [Teas] TEAS chairs X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 03:59:39 -0000 --001a1147b1daad83f605108298e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Everyone! I would like to thank the ADs for entrusting me with this responsibility - I'm deeply humbled and I hope to give it my best. Looking forward to Dallas, -Pavan On Wed, Mar 4, 2015 at 12:55 PM, Lou Berger wrote: > WG, > > I want to personally and publicly thank Deborah for all of her hard work > over the years she chaired CCAMP (and now TEAS). While I/we will miss > her in her old role, she isn't going far in her new role -- so I hope > and expect that we all will continue to benefit from her active > contribution to and guidance of the WG. > > Of course, I also want to welcome Pavan. > > As Alia stated, we'll be working transition over the next few weeks to > ensure handover is complete in Dallas. > > Lou > > On 3/4/2015 11:18 AM, Alia Atlas wrote: > > Hi TEAS, > > > > From Weds evening of IETF-92, Deborah will be serving as Routing AD so > > it isn't appropriate for her to continue to chair a WG in the Routing > > Area.=C3=82 Thus, Deborah is stepping down as co-chair of SPRING.=C3= =82 I > > really appreciate the hard work that Deborah has done as TEAS co-chair. > > > > I have consulted with Alvaro, Deborah, Adrian, and Lou Berger, and > > have decided to appoint Pavan Beeram to serve in this role.=C3=82 Pava= n > > will be busy ramping up.=C3=82 I expect the handover to be finished in > Dallas. > > > > Pavan can be reached at > >. > > > > Thanks, > > Alia > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a1147b1daad83f605108298e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Everyone!

I would like= to thank the ADs for entrusting me with this responsibility - I'm deep= ly humbled and I hope to give it my best.

Looking forward to D= allas,
-Pavan

On Wed, Mar 4, 2015 at 12:55 PM, Lou Berger <lberger@labn.= net> wrote:
WG,

I want to personally and publicly thank Deborah for all of her hard work over the years she chaired CCAMP (and now TEAS).=C2=A0 While I/we will miss=
her in her old role, she isn't going far in her new role -- so I hope and expect that we all will continue to benefit from her active
contribution to and guidance of the WG.

Of course, I also want to welcome Pavan.

As Alia stated, we'll be working transition over the next few weeks to<= br> ensure handover is complete in Dallas.

Lou

On 3/4/2015 11:18 AM, Alia Atlas wrote:
> Hi TEAS,
>
> From Weds evening of IETF-92, Deborah will be serving as Routing AD so=
> it isn't appropriate for her to continue to chair a WG in the Rout= ing
> Area.=C3=82=C2=A0 Thus, Deborah is stepping down as co-chair of= SPRING.=C3=82=C2=A0 I
> really appreciate the hard work that Deborah has done= as TEAS co-chair.
>
> I have consulted with Alvaro, Deborah, Adrian, and Lou Berger, and
> have decided to appoint Pavan Beeram to serve in this role.=C3= =82=C2=A0 Pavan
> will be busy ramping up.=C3=82=C2=A0 I expect the handover to be finis= hed in Dallas.
>
> Pavan can be reached at <vbe= eram@juniper.net
> <mailto:vbeeram@junip= er.net>>.
>
> Thanks,
> Alia
>
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

--001a1147b1daad83f605108298e6-- From nobody Wed Mar 4 22:07:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C04E1B29BE; Wed, 4 Mar 2015 22:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpdCce7spuO3; Wed, 4 Mar 2015 22:07:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D641B29B7; Wed, 4 Mar 2015 22:07:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPX23145; Thu, 05 Mar 2015 06:07:30 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Mar 2015 06:07:29 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 5 Mar 2015 14:07:19 +0800 From: "Dongjie (Jimmy)" To: Elwyn Davies , General area reviewing team , "draft-ietf-teas-rsvp-te-li-lb.all" , "teas@ietf.org" Thread-Topic: [Teas] [Gen-art] Gen-art telechat review of draft-ietf-teas-rsvp-te-li-lb-04.txt (updated) Thread-Index: AQHQVquTQhBEpAOXVkyY2Z5EogrzvJ0NPxDw Date: Thu, 5 Mar 2015 06:07:18 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273384D5AE@nkgeml512-mbx.china.huawei.com> References: <54F75304.706@folly.org.uk> In-Reply-To: <54F75304.706@folly.org.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] [Gen-art] Gen-art telechat review of draft-ietf-teas-rsvp-te-li-lb-04.txt (updated) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 06:07:34 -0000 Hi Elwyn,=20 Thanks for your comments, a new revision -05 was submitted yesterday to sol= ve your comments.=20 Regarding the bidirectional LSPs, my understanding is that as specified in = this draft, where loopback should be enabled is determined by the ERO subob= ject prior to the Hop Attribute subobject. So if it is an IP address, the l= oopback would be enabled on both directions of the bidirectional LSP. If it= is a label identifying one direction, then loopback would be enabled for t= hat direction.=20 Many thanks, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Elwyn Davies > Sent: Thursday, March 05, 2015 2:46 AM > To: General area reviewing team; draft-ietf-teas-rsvp-te-li-lb.all; teas@= ietf.org > Subject: [Teas] [Gen-art] Gen-art telechat review of > draft-ietf-teas-rsvp-te-li-lb-04.txt (updated) >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen-= ART, > please see the FAQ at < > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >=20 > Please wait for direction from your document shepherd or AD before postin= g a > new version of the draft. >=20 > Document: draft-ietf-teas-rsvp-te-li-lb-04.txt > Reviewer: Elwyn Davies > Review Date: 2015/03/03 > IETF LC End Date: 2015/02/18 > IESG Telechat date: 20150305 >=20 > Summary: Almost ready for PS. I noticed at a late stage in the last call > reviewing process that the requirement that the hop before a loopback nod= e > should be a strict hop was unnecessary. The draft editor, Dong Jie, has = agreed > that this is the case and is checking that the removal of this constraint= is > acceptable to the other authors. There is one other outstanding fix agre= ed for > a nit. Otherwise all my last call comments have been cleared. Thanks. >=20 > An additional minor issue about labels has come to light. See below. >=20 > Major issues: > None >=20 > Minor issues: > s3.2, para 2, et seq: > The requirement that the hop before the loopback entity MUST be a strict = hop is > unnecessary. The essential constraint (which is fully specified in the -= 04 draft) > is that the entity at which loopback is to occur has to be uniquely ident= ified (i.e., > it can't be an 'abstract node' > signifying (potentially) a group of nodes, such as an AS). I have discus= sed this > with Dong Jie, as editor, and he has agreed that the constraint is not ne= eded. > A new version of the draft removing the constraint is in hand, pending > agreement with the other authors and checking with the WG. >=20 > s3.2: > If dealing with a bidirectional LSP as per RFC 3473, and the ERO waypoint= (say, > an IPv4 address) is qualified with two Label subobjects, does loopback pu= t BOTH > paths into loopback? Alternatively, the loopback flag could be defined s= o that > it applies to only one of the Labels if the ERO Hop attribute subobject i= s placed > after the Label or to both if it is placed immediately after the identify= ing > subobject (in this case the IPv4 address subobject). >=20 > Nits/editorial comments: >=20 > s3.2, para 3: > OLD : >=20 > Currently, the type value MUST be verified to be > less than 32, and for type values 1 and 2, the prefix length MUST be > 32 and 128 respectively. >=20 > NEW: > Currently, the type value MUST be verified to be > less than 32 (i.e., able to identify a specific entity where a loopba= ck can > occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 > (IPv6 > address), the prefix length MUST be 32 and 128 respectively. >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Mar 5 04:25:12 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8241B2C31; Thu, 5 Mar 2015 03:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLSGtPYS56IY; Thu, 5 Mar 2015 03:53:46 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id A99AC1A89B0; Thu, 5 Mar 2015 03:53:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 05E002CEB5; Thu, 5 Mar 2015 13:53:45 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUrZbEavBeaw; Thu, 5 Mar 2015 13:53:44 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 975372CEB0; Thu, 5 Mar 2015 13:53:44 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_282A4D07-7BD2-46FD-B25C-1199FAE2E91B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273384D5AE@nkgeml512-mbx.china.huawei.com> Date: Thu, 5 Mar 2015 13:53:44 +0200 Message-Id: <4F22D2F4-97DB-452B-94D8-725B1AFF7CAC@piuha.net> References: <54F75304.706@folly.org.uk> <76CD132C3ADEF848BD84D028D243C9273384D5AE@nkgeml512-mbx.china.huawei.com> To: "Dongjie (Jimmy)" X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Thu, 05 Mar 2015 04:25:11 -0800 Cc: General area reviewing team , Elwyn Davies , "draft-ietf-teas-rsvp-te-li-lb.all" , "teas@ietf.org" Subject: Re: [Teas] [Gen-art] Gen-art telechat review of draft-ietf-teas-rsvp-te-li-lb-04.txt (updated) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:53:47 -0000 --Apple-Mail=_282A4D07-7BD2-46FD-B25C-1199FAE2E91B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Jie, Elwyn - Thanks for your review and work addressing the review comments. Jari --Apple-Mail=_282A4D07-7BD2-46FD-B25C-1199FAE2E91B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU+EPIAAoJEM80gCTQU46qERIP/1Diy3Y2Ok2c6mbPFOceB35d dHLj1mKQoLrH+aXF29hZzIEytuX46WuCCh+iMeNEhF8sq72XpNHeYlpN4ObYk71K kTWk9D8vX63+fER75blvN9/CsvTzByt821baW4Jv0AiDE/3Eangr9tJeb9PGiDUv dPejQxASyW40I4tlf1uRwq4k39mIdEzwcM2ZBCDv7Xb0EQVxbdJ0UYQpFx+sxmRZ ZZPYYtQuYuDcT8jW8RGqxlb7/dWOXyg0IE41jGCrI+1J5IAXGFmMUo3omKI4cIKL hqP2MQptiGD1F43nfmvELjVmTvXKecacdR8B+mqNpIQMOp84VizwApd7+5yJVpz7 29wm/g87M9nERp9nvWfmbGsLjPtAkAQbMAkRYZjwBLEzzaAUh1Mi5Nr7g+YaNC5g /E++CK8REsZd9fBLwroFkhG4+KC9FysJiQm+zZJ7ybj3YRjK/dtD7pqQQAyla27F axu+gRiJZn6NQQjQNmz7Z76NK75VaHbIa4Nc5Pe9aC7ejmvrDxa8AK8pocn2F8g/ D6RXjwPtYL7tI8KvK+cy+3wiJcvZuNT13glbloGp6QXEaPl3KE+GWLZBnZ8SwNqw OIKND79gqx12Q1QEEp6c9RhUlssIGEECyBP7DrMUekp1Q6oIv5bVLxRmQ65kXh6V NHBXdSU5JoRZgZCoGpgC =rZqy -----END PGP SIGNATURE----- --Apple-Mail=_282A4D07-7BD2-46FD-B25C-1199FAE2E91B-- From nobody Thu Mar 5 04:49:34 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C12D1B2C6B; Thu, 5 Mar 2015 04:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMo4dKNJgjyj; Thu, 5 Mar 2015 04:49:28 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30:5054:ff:fe5e:1643]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2819D1A871A; Thu, 5 Mar 2015 04:49:28 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1YTVDO-00044t-8i; Thu, 05 Mar 2015 12:49:22 +0000 Message-ID: <54F850D5.1040803@folly.org.uk> Date: Thu, 05 Mar 2015 12:49:25 +0000 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Dongjie (Jimmy)" , General area reviewing team , "draft-ietf-teas-rsvp-te-li-lb.all" , "teas@ietf.org" References: <54F75304.706@folly.org.uk> <76CD132C3ADEF848BD84D028D243C9273384D5AE@nkgeml512-mbx.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273384D5AE@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Teas] [Gen-art] Gen-art telechat review of draft-ietf-teas-rsvp-te-li-lb-04.txt (updated) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 12:49:32 -0000 Hi, Jie. Thanks for the update and changes. Unfortunately we haven't quite finished... The removal of the strict constraint also means it is necessary to either change or remove this sentence in the previous paragraph - s3.2, para 2: > The ingress > node MUST ensure that the entity (node or interface), at which > loopback is intended to occur, is marked as a strict hop in the > Explicit Route Object (ERO) subobject. As regards the bidirectional LSP story, I think that what you wrote below ought to go in the draft. This is especially true if the changes I suggested for the attribute draft are accepted, because it affects how the ERO Hop attributes subobject is interpreted - and where it/they should be placed in the list. Sorry this has turned into such a saga!! Regards, Elwyn On 05/03/2015 06:07, Dongjie (Jimmy) wrote: > Hi Elwyn, > > Thanks for your comments, a new revision -05 was submitted yesterday to solve your comments. > > Regarding the bidirectional LSPs, my understanding is that as specified in this draft, where loopback should be enabled is determined by the ERO subobject prior to the Hop Attribute subobject. So if it is an IP address, the loopback would be enabled on both directions of the bidirectional LSP. If it is a label identifying one direction, then loopback would be enabled for that direction. > > Many thanks, > Jie > >> -----Original Message----- >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Elwyn Davies >> Sent: Thursday, March 05, 2015 2:46 AM >> To: General area reviewing team; draft-ietf-teas-rsvp-te-li-lb.all; teas@ietf.org >> Subject: [Teas] [Gen-art] Gen-art telechat review of >> draft-ietf-teas-rsvp-te-li-lb-04.txt (updated) >> >> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, >> please see the FAQ at < >> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please wait for direction from your document shepherd or AD before posting a >> new version of the draft. >> >> Document: draft-ietf-teas-rsvp-te-li-lb-04.txt >> Reviewer: Elwyn Davies >> Review Date: 2015/03/03 >> IETF LC End Date: 2015/02/18 >> IESG Telechat date: 20150305 >> >> Summary: Almost ready for PS. I noticed at a late stage in the last call >> reviewing process that the requirement that the hop before a loopback node >> should be a strict hop was unnecessary. The draft editor, Dong Jie, has agreed >> that this is the case and is checking that the removal of this constraint is >> acceptable to the other authors. There is one other outstanding fix agreed for >> a nit. Otherwise all my last call comments have been cleared. Thanks. >> >> An additional minor issue about labels has come to light. See below. >> >> Major issues: >> None >> >> Minor issues: >> s3.2, para 2, et seq: >> The requirement that the hop before the loopback entity MUST be a strict hop is >> unnecessary. The essential constraint (which is fully specified in the -04 draft) >> is that the entity at which loopback is to occur has to be uniquely identified (i.e., >> it can't be an 'abstract node' >> signifying (potentially) a group of nodes, such as an AS). I have discussed this >> with Dong Jie, as editor, and he has agreed that the constraint is not needed. >> A new version of the draft removing the constraint is in hand, pending >> agreement with the other authors and checking with the WG. >> >> s3.2: >> If dealing with a bidirectional LSP as per RFC 3473, and the ERO waypoint (say, >> an IPv4 address) is qualified with two Label subobjects, does loopback put BOTH >> paths into loopback? Alternatively, the loopback flag could be defined so that >> it applies to only one of the Labels if the ERO Hop attribute subobject is placed >> after the Label or to both if it is placed immediately after the identifying >> subobject (in this case the IPv4 address subobject). >> >> Nits/editorial comments: >> >> s3.2, para 3: >> OLD : >> >> Currently, the type value MUST be verified to be >> less than 32, and for type values 1 and 2, the prefix length MUST be >> 32 and 128 respectively. >> >> NEW: >> Currently, the type value MUST be verified to be >> less than 32 (i.e., able to identify a specific entity where a loopback can >> occur, see Section 4.3), and for type values 1 (IPv4 address) and 2 >> (IPv6 >> address), the prefix length MUST be 32 and 128 respectively. >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > From nobody Thu Mar 5 05:26:17 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6F31A8774; Thu, 5 Mar 2015 05:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7AuhBpeWibu; Thu, 5 Mar 2015 05:26:11 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30:5054:ff:fe5e:1643]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41E11A0120; Thu, 5 Mar 2015 05:26:10 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1YTVmw-0006AT-E5; Thu, 05 Mar 2015 13:26:06 +0000 Message-ID: <54F85971.6040600@folly.org.uk> Date: Thu, 05 Mar 2015 13:26:09 +0000 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Cyril Margaria References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> <54F5F635.2050304@folly.org.uk> <54F74F12.3020205@folly.org.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gen-art@ietf.org, Lou Berger , draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , teas@ietf.org Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 13:26:14 -0000 Hi, Cyril. Yes.. That looks good. Thanks! Dong Jie will hopefully take this on board for the loopback flag in draft-ietf-teas-rsvp-te-li-lb. We have been discussing this earlier today. Regards, Elwyn On 05/03/2015 03:28, Cyril Margaria wrote: > Hi, > > Thanks for the quick feedback, > Would the following text modification address your comments . > the wording is a bit different, I tried to simplify the description of the > TLV scope. > > As described in [RFC3209] the ERO is managed as a list of subobjects > each identifying a specific entity, an abstract node or a link that > defines a waypoint in the network path. Identifying subobjects of > various types are defined in [RFC3209], [RFC3477], [RFC4873], > [RFC4874], [RFC5520] and [RFC5553]. > > [RFC3473] modified the ERO list by allowing one or two Label > subobjects to be interposed in the list after a subobject identifying > a link. One or more ERO Hop Attributes subobjects applicable to a > particular hop MAY be inserted directly after any of the existing > identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873], > [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are > present for a hop, the ERO Hop Attributes subobject(s) MAY also be > inserted after the Label subobjects. > > The attributes specified in a ERO Hop Attributes subobject apply to > the immediately preceding subobject(s) in the ERO subobject list. > > A document defining a specific Hop Attribute TLV has to describe: > > o after which kinds of ERO subobject they are valid , > > o if ordering of the Hop Attributes subobject and other ERO > subobjects associated with the same hop (e.g., Label subobjects) > is significant, > > o if ordering is significant, how the attribute is interpreted in > association with the preceding ERO subobjects, and > > o any TLV modification rules that might apply. > > For instance, subobject presence rules can be defined by describing > rules similar to [RFC4990] Section 6.1. > > > That would allow a TLV to apply to one (or more) preceding subobject, the > type of subobject being left to the TLV. > > Regarding section 2.2, the following text is proposed: > > The presence and ordering rule of the Attribute Flags TLV in an ERO > Hop Attributes Subobject is defined by each Flag. A document > defining a Flag to be used in a Attribute Flags TLV carried in the > ERO Hop Attributes Subobject has to describe: > > o after which kinds of ERO subobject the Flag is valid > > o if ordering of the Flag and other ERO subobjects associated with > the same hop (e.g., Label subobjects) is significant, > > o if ordering is significant, how the Flag is interpreted in > association with the preceding subobjects, > > o any Flag modification rules that might apply. > > > If its Ok, I can post a new revision shortly. > > Best Regards > Cyril > > > > On 4 March 2015 at 13:29, Elwyn Davies wrote: > >> >> On 04/03/2015 06:04, Cyril Margaria wrote: >> >>> Hi, >>> >>> Thanks for your review, >>> Please not that a new revision addressing IANA , APS-DIR and Gen-ART >>> comments on revision -02 is available. >>> https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 >>> >>> please see inline. >>> >> Hi, Cyril. >> >> Yes: my comments and the new version crossed. >> >> However -03 doesn't significantly alter para 1 of s2.3. >> >> Firstly, I am far from expert in this area, so I have not much clue as to >> whether it would ever be useful or meaningful to associate an attribute >> with a Label rather than with the entity identified by the other subobject >> types. However, it has just occurred to me that with the loopback case, >> one needs to decide that if there are two labels, does loopback apply to >> both of them or just one? Arrrgggh! >> >> Perhaps something like the following, replacing the first two paras of >> s2.3, would cover all the bases and push the decision down to the document >> that defines the TLV(s)/flags used in the Hop attribute subobjects: >> >> OLD: >> As described in [RFC3209] and [RFC3473] the ERO is managed as a list >> where each hop information starts with a subobject identifying an >> abstract node or link. The ERO Hop Attributes subobject MAY be >> appended after any of the existing subobjects defined in [RFC3209], >> [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. >> Several ERO Hop Attributes subobject MAY be present, for each hop. >> >> Document defining specific Hop attribute TLV has to describe after >> which kind of subobject they are valid and if TLV modification rules >> applies. For instance, subobject presence rules can be defined by >> describing rules similar to [RFC4990] Section 6.1. >> >> NEW: >> As described in [RFC3209] the ERO is managed as a list of subobjects >> each identifying a specific entity, an abstract node or a link that >> defines >> a waypoint in the ERO route. Identifying subobjects of various types >> are >> defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and >> [RFC5553]. >> >> [RFC3473] modified the ERO list by allowing one or two Label subobjects >> to be interposed in the list after a subobject identifying an entity by >> its >> IP address or interface identifier. One or more ERO Hop attributes >> subobjects applicable to a particular hop MAY be inserted directly after >> any of the existing identifying subobjects defined in [RFC3209], >> [RFC3477], >> [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects >> are present for a hop, the ERO Hop attributes subobject(s) MAY also be >> inserted after the Label subobjects. >> >> The attributes specified in a ERO Hop attributes subobject apply to the >> hop >> that ends at the route waypoint identified by the immediately preceding >> identifying subobject in the ERO subobject list. >> >> A document defining a specific Hop attribute TLV has to describe >> - after which kinds of subobject they are valid , >> - if ordering of the Hop attributes subobject and other subobjects >> associated with the same hop (e.g., Label subobjects) is >> significant, >> - if ordering is significant, how the attribute is interpreted in >> association with the preceding subobjects, and >> - any TLV modification rules that might apply. >> For instance, subobject presence rules can be defined by describing >> rules >> similar to [RFC4990] Section 6.1. >> >> This might require a few words added to s2.2 to specify that the ordering >> decision for individual flags is up to the definition of the flag. In turn >> that possibly means that the loopback draft needs to think about whether >> the loopback applies to both labels or only the one the loopback flag is >> after as mentioned above. >> >> Regards, >> Elwyn >> >> PS >> There is discussion about the .all aliases going to WG lists as well as >> relevant individuals. The long standing position was that they didn't but >> change has recently been mooted. >> >> /E >> >> >>> >>> >>> On 3 March 2015 at 12:58, Elwyn Davies wrote: >>> >>> Hi. >>>> In the process of doing the gen-art review of >>>> draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at >>>> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments >>>> about >>>> ordering of subobjects in the loopback draft. >>>> >>>> I thought that the text in the first paragraph of s2.3: >>>> >>>> As described in [RFC3209 ] and >>>> [RFC3473 ] the ERO is managed as a >>>> list >>>> where each hop information starts with a subobject identifying an >>>> abstract node or link. The ERO Hop Attributes subobject MAY be >>>> appended after any of the existing subobjects defined in [RFC3209 < >>>> https://tools.ietf.org/html/rfc3209>], >>>> [RFC3473 ], [RFC3477 < >>>> https://tools.ietf.org/html/rfc3477>], [RFC4873 < >>>> https://tools.ietf.org/html/rfc4873>], [RFC4874 < >>>> https://tools.ietf.org/html/rfc4874>], [RFC5520 < >>>> https://tools.ietf.org/html/rfc5520>] and [RFC5553 < >>>> https://tools.ietf.org/html/rfc5553>]. >>>> >>>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>>> >>>> was not very clear: The use of 'appended' was slightly confusing. I >>>> felt >>>> it needed something a bit closer to the "Presence Rules" that are given >>>> for >>>> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going >>>> on. >>>> >>>> I am not totally clear what would happen in the case of (say) an IPv4 >>>> address subobject followed by two Label subobjects. The wording seems to >>>> indicate that Hop attributes can be inserted anywhere in the sequence of >>>> three subobjects - but would they specifically apply to one or other >>>> Label >>>> if they were inserted after a Label or would they always apply >>>> generically >>>> to the hop terminated at the IPv4 address entity? >>>> >>>> >>>> draft-ietf-teas-lsp-attribute-ro tries to leave that open to the >>> documents >>> defining the TLVs. We are not excluding an Attribute that applies to a >>> Label or Interface. If the subobject would be inserted after a Label >>> Subobject, the Attribute TLVs would apply to the Labels. >>> >>> This is based on the following review comment:" >>> I think *this* I-D needs to make it clear what the expectations are: >>> >>> 1. The sub-object is allowed at any point in the ERO >>> 2. The document that specifies a TLV for the sub-object must make it >>> clear where in an ERO a sub-object containing that TLV is allowed and >>> not allowed." >>> >>> Do you think this is reasonable or we should exclude TLVs scoped to >>> labels? >>> In the latter case, I would add you suggested text. >>> >>> Best Regards. >>> Cyril >>> >>> PS: It seems there are errors with the tools.ietf.org aliases >>> >>> >>> My suggestion for rewording, based on the assumption that the hop >>>> attributes apply to the hop rather than any of the labels, would be: >>>> >>>> As described in [RFC3209] the ERO is managed as a list of subobjects >>>> each identifying a specific entity, an abstract node or a link. >>>> Identifying >>>> subobjects of various types are defined in [RFC3209], [RFC3477], >>>> [RFC4873], >>>> [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO list >>>> by >>>> allowing one or two Label subobjects to be interposed in the list >>>> after >>>> a >>>> subobject identifying an entity by its IP address or interface >>>> identifier. One >>>> or more ERO Hop attributes subobjects applicable to a particular hop >>>> MAY >>>> be inserted after any of the existing identifying subobjects defined >>>> in >>>> [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. >>>> If any Label subobjects are present for a hop, the ERO Hop attributes >>>> subobject(s) MUST be inserted after the Label subobjects. >>>> >>>> The last two sentences would need to be altered if Hop attributes were >>>> applicable to Labels rather than just to the hop as a whole. >>>> >>>> Regards, >>>> Elwyn >>>> >>>> >>>> >>>> _______________________________________________ >>>> Teas mailing list >>>> Teas@ietf.org >>>> https://www.ietf.org/mailman/listinfo/teas >>>> >>>> >>>> From nobody Thu Mar 5 06:12:57 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5160D1A00CF; Thu, 5 Mar 2015 06:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yfGy3cCCPR0; Thu, 5 Mar 2015 06:12:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F31A00ED; Thu, 5 Mar 2015 06:08:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305140816.27105.42841.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 06:08:16 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-attribute-ro-04.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:12:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : LSP Attribute in ERO Authors : Cyril Margaria Giovanni Martinelli Steve Balls Ben Wright Filename : draft-ietf-teas-lsp-attribute-ro-04.txt Pages : 14 Date : 2015-03-05 Abstract: RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) objects to allow it to specify or record generic attributes which apply to a given hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 5 06:43:47 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C744A1A00B5; Thu, 5 Mar 2015 06:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32cDF2yhztEi; Thu, 5 Mar 2015 06:43:40 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7C3A1A00E8; Thu, 5 Mar 2015 06:40:21 -0800 (PST) Received: by wivr20 with SMTP id r20so7304377wiv.5; Thu, 05 Mar 2015 06:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rp/6JYuo8Z+spBGGTC3taEaiDzrKOasv+P2vHhUXnf8=; b=up5MCAVuyvGBoHc/AiTaVplS1iJYf6sOTSMnRTe2uXorjEtQW8IhokF8ZnocIkVL/N AvEYCgdNwT/6tDPYvu41TJEMhHCm4WUzmHUmhNhxMR3j+tZ/MmHu6Tpd0V9SQ/DDyVmf Q5WmdNnuWYN6wgLdjAjcthZB2LPlKAoY2gCir2zjEekOQ32FNM5gP1G2md01ha9tqcmO FN2NgX0VMOUTBOwn/Bd1Me4eVwzE8yO7vHFrClDMZKgQ5TJCAJL6B9qHpWj1hxUPw/zH rNC3WDkVCZZfq01xmGW3loIHlrRFIdZnRqhkYYJ45YxqLF62RAsx4XcC67KG5kzq5uih Pj/Q== MIME-Version: 1.0 X-Received: by 10.194.61.65 with SMTP id n1mr19444720wjr.53.1425566420678; Thu, 05 Mar 2015 06:40:20 -0800 (PST) Received: by 10.27.51.145 with HTTP; Thu, 5 Mar 2015 06:40:20 -0800 (PST) In-Reply-To: <54F85971.6040600@folly.org.uk> References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> <54F5F635.2050304@folly.org.uk> <54F74F12.3020205@folly.org.uk> <54F85971.6040600@folly.org.uk> Date: Thu, 5 Mar 2015 09:40:20 -0500 Message-ID: From: Cyril Margaria To: Elwyn Davies Content-Type: multipart/alternative; boundary=047d7b86d5741bbedf05108b8cb6 Archived-At: Cc: gen-art@ietf.org, Lou Berger , draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , teas@ietf.org Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:43:45 -0000 --047d7b86d5741bbedf05108b8cb6 Content-Type: text/plain; charset=UTF-8 Hi Elwyn, Thanks, a new revision addressing the comments have been posted Name: draft-ietf-teas-lsp-attribute-ro Revision: 04 Title: LSP Attribute in ERO Document date: 2015-03-04 Group: teas Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-teas-lsp-attribute-ro-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ Htmlized: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-04 Best Regards. On 5 March 2015 at 08:26, Elwyn Davies wrote: > Hi, Cyril. > > Yes.. That looks good. Thanks! > > Dong Jie will hopefully take this on board for the loopback flag in > draft-ietf-teas-rsvp-te-li-lb. We have been discussing this earlier today. > > Regards, > Elwyn > > > On 05/03/2015 03:28, Cyril Margaria wrote: > >> Hi, >> >> Thanks for the quick feedback, >> Would the following text modification address your comments . >> the wording is a bit different, I tried to simplify the description of the >> TLV scope. >> >> As described in [RFC3209] the ERO is managed as a list of subobjects >> each identifying a specific entity, an abstract node or a link that >> defines a waypoint in the network path. Identifying subobjects of >> various types are defined in [RFC3209], [RFC3477], [RFC4873], >> [RFC4874], [RFC5520] and [RFC5553]. >> >> [RFC3473] modified the ERO list by allowing one or two Label >> subobjects to be interposed in the list after a subobject identifying >> a link. One or more ERO Hop Attributes subobjects applicable to a >> particular hop MAY be inserted directly after any of the existing >> identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873], >> [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are >> present for a hop, the ERO Hop Attributes subobject(s) MAY also be >> inserted after the Label subobjects. >> >> The attributes specified in a ERO Hop Attributes subobject apply to >> the immediately preceding subobject(s) in the ERO subobject list. >> >> A document defining a specific Hop Attribute TLV has to describe: >> >> o after which kinds of ERO subobject they are valid , >> >> o if ordering of the Hop Attributes subobject and other ERO >> subobjects associated with the same hop (e.g., Label subobjects) >> is significant, >> >> o if ordering is significant, how the attribute is interpreted in >> association with the preceding ERO subobjects, and >> >> o any TLV modification rules that might apply. >> >> For instance, subobject presence rules can be defined by describing >> rules similar to [RFC4990] Section 6.1. >> >> >> That would allow a TLV to apply to one (or more) preceding subobject, the >> type of subobject being left to the TLV. >> >> Regarding section 2.2, the following text is proposed: >> >> The presence and ordering rule of the Attribute Flags TLV in an ERO >> Hop Attributes Subobject is defined by each Flag. A document >> defining a Flag to be used in a Attribute Flags TLV carried in the >> ERO Hop Attributes Subobject has to describe: >> >> o after which kinds of ERO subobject the Flag is valid >> >> o if ordering of the Flag and other ERO subobjects associated with >> the same hop (e.g., Label subobjects) is significant, >> >> o if ordering is significant, how the Flag is interpreted in >> association with the preceding subobjects, >> >> o any Flag modification rules that might apply. >> >> >> If its Ok, I can post a new revision shortly. >> >> Best Regards >> Cyril >> >> >> >> On 4 March 2015 at 13:29, Elwyn Davies wrote: >> >> >>> On 04/03/2015 06:04, Cyril Margaria wrote: >>> >>> Hi, >>>> >>>> Thanks for your review, >>>> Please not that a new revision addressing IANA , APS-DIR and Gen-ART >>>> comments on revision -02 is available. >>>> https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 >>>> >>>> please see inline. >>>> >>>> Hi, Cyril. >>> >>> Yes: my comments and the new version crossed. >>> >>> However -03 doesn't significantly alter para 1 of s2.3. >>> >>> Firstly, I am far from expert in this area, so I have not much clue as to >>> whether it would ever be useful or meaningful to associate an attribute >>> with a Label rather than with the entity identified by the other >>> subobject >>> types. However, it has just occurred to me that with the loopback case, >>> one needs to decide that if there are two labels, does loopback apply to >>> both of them or just one? Arrrgggh! >>> >>> Perhaps something like the following, replacing the first two paras of >>> s2.3, would cover all the bases and push the decision down to the >>> document >>> that defines the TLV(s)/flags used in the Hop attribute subobjects: >>> >>> OLD: >>> As described in [RFC3209] and [RFC3473] the ERO is managed as a list >>> where each hop information starts with a subobject identifying an >>> abstract node or link. The ERO Hop Attributes subobject MAY be >>> appended after any of the existing subobjects defined in [RFC3209], >>> [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. >>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>> >>> Document defining specific Hop attribute TLV has to describe after >>> which kind of subobject they are valid and if TLV modification rules >>> applies. For instance, subobject presence rules can be defined by >>> describing rules similar to [RFC4990] Section 6.1. >>> >>> NEW: >>> As described in [RFC3209] the ERO is managed as a list of subobjects >>> each identifying a specific entity, an abstract node or a link that >>> defines >>> a waypoint in the ERO route. Identifying subobjects of various types >>> are >>> defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and >>> [RFC5553]. >>> >>> [RFC3473] modified the ERO list by allowing one or two Label >>> subobjects >>> to be interposed in the list after a subobject identifying an entity >>> by >>> its >>> IP address or interface identifier. One or more ERO Hop attributes >>> subobjects applicable to a particular hop MAY be inserted directly >>> after >>> any of the existing identifying subobjects defined in [RFC3209], >>> [RFC3477], >>> [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label >>> subobjects >>> are present for a hop, the ERO Hop attributes subobject(s) MAY also >>> be >>> inserted after the Label subobjects. >>> >>> The attributes specified in a ERO Hop attributes subobject apply to >>> the >>> hop >>> that ends at the route waypoint identified by the immediately >>> preceding >>> identifying subobject in the ERO subobject list. >>> >>> A document defining a specific Hop attribute TLV has to describe >>> - after which kinds of subobject they are valid , >>> - if ordering of the Hop attributes subobject and other >>> subobjects >>> associated with the same hop (e.g., Label subobjects) is >>> significant, >>> - if ordering is significant, how the attribute is interpreted in >>> association with the preceding subobjects, and >>> - any TLV modification rules that might apply. >>> For instance, subobject presence rules can be defined by describing >>> rules >>> similar to [RFC4990] Section 6.1. >>> >>> This might require a few words added to s2.2 to specify that the ordering >>> decision for individual flags is up to the definition of the flag. In >>> turn >>> that possibly means that the loopback draft needs to think about whether >>> the loopback applies to both labels or only the one the loopback flag is >>> after as mentioned above. >>> >>> Regards, >>> Elwyn >>> >>> PS >>> There is discussion about the .all aliases going to WG lists as well as >>> relevant individuals. The long standing position was that they didn't >>> but >>> change has recently been mooted. >>> >>> /E >>> >>> >>> >>>> >>>> On 3 March 2015 at 12:58, Elwyn Davies wrote: >>>> >>>> Hi. >>>> >>>>> In the process of doing the gen-art review of >>>>> draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at >>>>> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments >>>>> about >>>>> ordering of subobjects in the loopback draft. >>>>> >>>>> I thought that the text in the first paragraph of s2.3: >>>>> >>>>> As described in [RFC3209 ] >>>>> and >>>>> [RFC3473 ] the ERO is managed as >>>>> a >>>>> list >>>>> where each hop information starts with a subobject identifying an >>>>> abstract node or link. The ERO Hop Attributes subobject MAY be >>>>> appended after any of the existing subobjects defined in [RFC3209 >>>>> < >>>>> https://tools.ietf.org/html/rfc3209>], >>>>> [RFC3473 ], [RFC3477 < >>>>> https://tools.ietf.org/html/rfc3477>], [RFC4873 < >>>>> https://tools.ietf.org/html/rfc4873>], [RFC4874 < >>>>> https://tools.ietf.org/html/rfc4874>], [RFC5520 < >>>>> https://tools.ietf.org/html/rfc5520>] and [RFC5553 < >>>>> https://tools.ietf.org/html/rfc5553>]. >>>>> >>>>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>>>> >>>>> was not very clear: The use of 'appended' was slightly confusing. I >>>>> felt >>>>> it needed something a bit closer to the "Presence Rules" that are given >>>>> for >>>>> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going >>>>> on. >>>>> >>>>> I am not totally clear what would happen in the case of (say) an IPv4 >>>>> address subobject followed by two Label subobjects. The wording seems >>>>> to >>>>> indicate that Hop attributes can be inserted anywhere in the sequence >>>>> of >>>>> three subobjects - but would they specifically apply to one or other >>>>> Label >>>>> if they were inserted after a Label or would they always apply >>>>> generically >>>>> to the hop terminated at the IPv4 address entity? >>>>> >>>>> >>>>> draft-ietf-teas-lsp-attribute-ro tries to leave that open to the >>>>> >>>> documents >>>> defining the TLVs. We are not excluding an Attribute that applies to a >>>> Label or Interface. If the subobject would be inserted after a Label >>>> Subobject, the Attribute TLVs would apply to the Labels. >>>> >>>> This is based on the following review comment:" >>>> I think *this* I-D needs to make it clear what the expectations are: >>>> >>>> 1. The sub-object is allowed at any point in the ERO >>>> 2. The document that specifies a TLV for the sub-object must make it >>>> clear where in an ERO a sub-object containing that TLV is allowed >>>> and >>>> not allowed." >>>> >>>> Do you think this is reasonable or we should exclude TLVs scoped to >>>> labels? >>>> In the latter case, I would add you suggested text. >>>> >>>> Best Regards. >>>> Cyril >>>> >>>> PS: It seems there are errors with the tools.ietf.org aliases >>>> >>>> >>>> My suggestion for rewording, based on the assumption that the hop >>>> >>>>> attributes apply to the hop rather than any of the labels, would be: >>>>> >>>>> As described in [RFC3209] the ERO is managed as a list of >>>>> subobjects >>>>> each identifying a specific entity, an abstract node or a link. >>>>> Identifying >>>>> subobjects of various types are defined in [RFC3209], [RFC3477], >>>>> [RFC4873], >>>>> [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO >>>>> list >>>>> by >>>>> allowing one or two Label subobjects to be interposed in the list >>>>> after >>>>> a >>>>> subobject identifying an entity by its IP address or interface >>>>> identifier. One >>>>> or more ERO Hop attributes subobjects applicable to a particular >>>>> hop >>>>> MAY >>>>> be inserted after any of the existing identifying subobjects >>>>> defined >>>>> in >>>>> [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and >>>>> [RFC5553]. >>>>> If any Label subobjects are present for a hop, the ERO Hop >>>>> attributes >>>>> subobject(s) MUST be inserted after the Label subobjects. >>>>> >>>>> The last two sentences would need to be altered if Hop attributes were >>>>> applicable to Labels rather than just to the hop as a whole. >>>>> >>>>> Regards, >>>>> Elwyn >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Teas mailing list >>>>> Teas@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/teas >>>>> >>>>> >>>>> >>>>> > --047d7b86d5741bbedf05108b8cb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Elwyn,

Thanks, a new revision a= ddressing the comments have been posted
Name:=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 draft-ietf-teas-lsp-attribute-ro
Revision:=C2=A0=C2=A0=C2= =A0 04
Title:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 LSP Attribute in ERO<= br>Document date:=C2=A0=C2=A0=C2=A0 2015-03-04
Group:=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 teas
Pages:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 14URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/internet-drafts/draft-ietf-teas-lsp-attribut= e-ro-04.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/<= br>Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html= /draft-ietf-teas-lsp-attribute-ro-04
Diff:=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-teas-lsp-attribute-ro-04

Best Regards.
=

On 5 March = 2015 at 08:26, Elwyn Davies <elwynd@folly.org.uk> wrote:
Hi, Cyril.

Yes.. That looks good.=C2=A0 Thanks!

Dong Jie will hopefully take this on board for the loopback flag in draft-i= etf-teas-rsvp-te-li-lb. We have been discussing this earlier today.

Regards,
Elwyn


On 05/03/2015 03:28, Cyril Margaria wrote:
Hi,

Thanks for the quick feedback,
Would the following text modification address your comments .
the wording is a bit different, I tried to simplify the description of the<= br> TLV scope.

=C2=A0 =C2=A0 As described in [RFC3209] the ERO is managed as a list of sub= objects
=C2=A0 =C2=A0 each identifying a specific entity, an abstract node or a lin= k that
=C2=A0 =C2=A0 defines a waypoint in the network path.=C2=A0 Identifying sub= objects of
=C2=A0 =C2=A0 various types are defined in [RFC3209], [RFC3477], [RFC4873],=
=C2=A0 =C2=A0 [RFC4874], [RFC5520] and [RFC5553].

=C2=A0 =C2=A0 [RFC3473] modified the ERO list by allowing one or two Label<= br> =C2=A0 =C2=A0 subobjects to be interposed in the list after a subobject ide= ntifying
=C2=A0 =C2=A0 a link.=C2=A0 One or more ERO Hop Attributes subobjects appli= cable to a
=C2=A0 =C2=A0 particular hop MAY be inserted directly after any of the exis= ting
=C2=A0 =C2=A0 identifying subobjects defined in[RFC3209], [RFC3477], [RFC48= 73],
=C2=A0 =C2=A0 [RFC4874], [RFC5520] and [RFC5553].=C2=A0 If any Label subobj= ects are
=C2=A0 =C2=A0 present for a hop, the ERO Hop Attributes subobject(s) MAY al= so be
=C2=A0 =C2=A0 inserted after the Label subobjects.

=C2=A0 =C2=A0 The attributes specified in a ERO Hop Attributes subobject ap= ply to
=C2=A0 =C2=A0 the immediately preceding subobject(s) in the ERO subobject l= ist.

=C2=A0 =C2=A0 A document defining a specific Hop Attribute TLV has to descr= ibe:

=C2=A0 =C2=A0 o=C2=A0 after which kinds of ERO subobject they are valid ,
=C2=A0 =C2=A0 o=C2=A0 if ordering of the Hop Attributes subobject and other= ERO
=C2=A0 =C2=A0 =C2=A0 =C2=A0subobjects associated with the same hop (e.g., L= abel subobjects)
=C2=A0 =C2=A0 =C2=A0 =C2=A0is significant,

=C2=A0 =C2=A0 o=C2=A0 if ordering is significant, how the attribute is inte= rpreted in
=C2=A0 =C2=A0 =C2=A0 =C2=A0association with the preceding ERO subobjects, a= nd

=C2=A0 =C2=A0 o=C2=A0 any TLV modification rules that might apply.

=C2=A0 =C2=A0 For instance, subobject presence rules can be defined by desc= ribing
=C2=A0 =C2=A0 rules similar to [RFC4990] Section 6.1.


That would allow a TLV to apply to one (or more) preceding subobject, the type of subobject being left to the TLV.

Regarding section 2.2, the following text is proposed:

=C2=A0 =C2=A0 The presence and ordering rule of the Attribute Flags TLV in = an ERO
=C2=A0 =C2=A0 Hop Attributes Subobject is defined by each Flag.=C2=A0 A doc= ument
=C2=A0 =C2=A0 defining a Flag to be used in a Attribute Flags TLV carried i= n the
=C2=A0 =C2=A0 ERO Hop Attributes Subobject has to describe:

=C2=A0 =C2=A0 o=C2=A0 after which kinds of ERO subobject the Flag is valid<= br>
=C2=A0 =C2=A0 o=C2=A0 if ordering of the Flag and other ERO subobjects asso= ciated with
=C2=A0 =C2=A0 =C2=A0 =C2=A0the same hop (e.g., Label subobjects) is signifi= cant,

=C2=A0 =C2=A0 o=C2=A0 if ordering is significant, how the Flag is interpret= ed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0association with the preceding subobjects,

=C2=A0 =C2=A0 o=C2=A0 any Flag modification rules that might apply.


If its Ok, I can post a new revision shortly.

Best Regards
Cyril



On 4 March 2015 at 13:29, Elwyn Davies <elwynd@folly.org.uk> wrote:


On 04/03/2015 06:04, Cyril Margaria wrote:

Hi,

Thanks for your review,
Please not that a new revision addressing IANA , APS-DIR and Gen-ART
comments=C2=A0 on revision -02 is available.
https://tools.ietf.org/html/draft-ietf-teas-lsp-a= ttribute-ro-03

=C2=A0 =C2=A0please see inline.

Hi, Cyril.

Yes:=C2=A0 my comments and the new version crossed.

However -03 doesn't significantly alter para 1 of s2.3.

Firstly, I am far from expert in this area, so I have not much clue as to whether it would ever be useful or meaningful to associate an attribute
with a Label rather than with the entity identified by the other subobject<= br> types.=C2=A0 However, it has just occurred to me that with the loopback cas= e,
one needs to=C2=A0 decide that if there are two labels, does loopback apply= to
both of them or just one?=C2=A0 Arrrgggh!

Perhaps something like the following, replacing the first two paras of
s2.3, would cover all the bases and push the decision down to the document<= br> that defines the TLV(s)/flags used in the Hop attribute subobjects:

OLD:
=C2=A0 =C2=A0 As described in [RFC3209] and [RFC3473] the ERO is managed as= a list
=C2=A0 =C2=A0 where each hop information starts with a subobject identifyin= g an
=C2=A0 =C2=A0 abstract node or link.=C2=A0 The ERO Hop Attributes subobject= MAY be
=C2=A0 =C2=A0 appended after any of the existing subobjects defined in [RFC= 3209],
=C2=A0 =C2=A0 [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RF= C5553].
=C2=A0 =C2=A0 Several ERO Hop Attributes subobject MAY be present, for each= hop.

=C2=A0 =C2=A0 Document defining specific Hop attribute TLV has to describe = after
=C2=A0 =C2=A0 which kind of subobject they are valid and if TLV modificatio= n rules
=C2=A0 =C2=A0 applies.=C2=A0 For instance, subobject presence rules can be = defined by
=C2=A0 =C2=A0 describing rules similar to [RFC4990] Section 6.1.

NEW:
=C2=A0 =C2=A0 As described in [RFC3209] the ERO is managed as a list of sub= objects
=C2=A0 =C2=A0 each identifying a specific entity, an abstract node or a lin= k that
defines
=C2=A0 =C2=A0 a waypoint in the ERO route.=C2=A0 Identifying subobjects of = various types
are
=C2=A0 =C2=A0 defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC55= 20] and
=C2=A0 =C2=A0 [RFC5553].

=C2=A0 =C2=A0 [RFC3473] modified the ERO list by allowing one or two Label = subobjects
=C2=A0 =C2=A0 to be interposed in the list after a subobject identifying an= entity by
its
=C2=A0 =C2=A0 IP address or interface identifier.=C2=A0 =C2=A0One or more E= RO Hop attributes
=C2=A0 =C2=A0 subobjects applicable to a particular hop MAY be inserted dir= ectly after
=C2=A0 =C2=A0 any of the existing identifying subobjects defined in [RFC320= 9],
[RFC3477],
=C2=A0 =C2=A0 [RFC4873], [RFC4874], [RFC5520] and [RFC5553].=C2=A0 If any L= abel subobjects
=C2=A0 =C2=A0 are present for a hop, the ERO Hop attributes subobject(s) MA= Y also be
=C2=A0 =C2=A0 inserted after the Label subobjects.

=C2=A0 =C2=A0 The attributes specified in a ERO Hop attributes subobject ap= ply to the
hop
=C2=A0 =C2=A0 that ends at the route waypoint identified by the immediately= preceding
=C2=A0 =C2=A0 identifying subobject in the ERO subobject list.

=C2=A0 =C2=A0 A document defining a specific Hop attribute TLV has to descr= ibe
=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 after which kinds of subobject they are = valid ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 if ordering of the Hop attributes subobj= ect and other subobjects
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 associated with the same hop (e.g., Labe= l subobjects) is
significant,
=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 if ordering is significant, how the attr= ibute is interpreted in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 association with the preceding subobject= s, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 any TLV modification rules that might ap= ply.
=C2=A0 =C2=A0 For instance, subobject presence rules can be defined by desc= ribing
rules
=C2=A0 =C2=A0 similar to [RFC4990] Section 6.1.

This might require a few words added to s2.2 to specify that the ordering decision for individual flags is up to the definition of the flag.=C2=A0 In= turn
that possibly means that the loopback draft needs to think about whether the loopback applies to both labels or only the one the loopback flag is after as mentioned above.

Regards,
Elwyn

PS
There is discussion about the .all aliases going to WG lists as well as
relevant individuals.=C2=A0 The long standing position was that they didn&#= 39;t but
change has recently been mooted.

/E




On 3 March 2015 at 12:58, Elwyn Davies <elwynd@folly.org.uk> wrote:

=C2=A0 =C2=A0 Hi.
In the process of doing the gen-art review of
draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at
draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments=
about
ordering of subobjects in the loopback draft.

I thought that the text in the first paragraph of s2.3:

=C2=A0 =C2=A0 =C2=A0As described in [RFC3209 <https://tools.ietf.org/html/= rfc3209>] and
[RFC3473 <https://tools.ietf.org/html/rfc3473>] the ERO is managed = as a
list
=C2=A0 =C2=A0 =C2=A0where each hop information starts with a subobject iden= tifying an
=C2=A0 =C2=A0 =C2=A0abstract node or link.=C2=A0 The ERO Hop Attributes sub= object MAY be
=C2=A0 =C2=A0 =C2=A0appended after any of the existing subobjects defined i= n [RFC3209 <
https://t= ools.ietf.org/html/rfc3209>],
=C2=A0 =C2=A0 =C2=A0[RFC3473 <https://tools.ietf.org/html/rfc3473>]= , [RFC3477 <
https://t= ools.ietf.org/html/rfc3477>], [RFC4873 <
https://t= ools.ietf.org/html/rfc4873>], [RFC4874 <
https://t= ools.ietf.org/html/rfc4874>], [RFC5520 <
https://t= ools.ietf.org/html/rfc5520>] and [RFC5553 <
https://t= ools.ietf.org/html/rfc5553>].

=C2=A0 =C2=A0 =C2=A0Several ERO Hop Attributes subobject MAY be present, fo= r each hop.

=C2=A0 =C2=A0was not very clear: The use of 'appended' was slightly= confusing.=C2=A0 I
felt
it needed something a bit closer to the "Presence Rules" that are= given
for
RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going
on.

I am not totally clear what would happen in the case of (say) an IPv4
address subobject followed by two Label subobjects.=C2=A0 The wording seems= to
indicate that Hop attributes can be inserted anywhere in the sequence of three subobjects - but would they specifically apply to one or other
Label
if they were inserted after a Label or would they always apply
generically
to the hop terminated at the IPv4 address entity?


=C2=A0 draft-ietf-teas-lsp-attribute-ro tries to leave that open to = the
documents
defining the TLVs. We are not excluding an Attribute that applies to a
Label or Interface. If the subobject would be inserted after a Label
Subobject, the Attribute TLVs would apply to the Labels.

This is based on the following review comment:"
I think *this* I-D needs to make it clear what the expectations are:

1. The sub-object is allowed at any point in the ERO
2. The document that specifies a TLV for the sub-object must make it
=C2=A0 =C2=A0 =C2=A0clear where in an ERO a sub-object containing that TLV = is allowed and
=C2=A0 =C2=A0 =C2=A0not allowed."

Do you think this is reasonable or we should exclude TLVs scoped to
labels?
In the latter case, I would add you suggested text.

Best Regards.
Cyril

PS: It seems there are errors with the tools.ietf.org aliases


=C2=A0 My suggestion for rewording, based on the assumption that the hop
attributes apply to the hop rather than any of the labels, would be:

=C2=A0 =C2=A0 =C2=A0As described in [RFC3209] the ERO is managed as a list = of subobjects
=C2=A0 =C2=A0 =C2=A0each identifying a specific entity, an abstract node or= a link.
Identifying
=C2=A0 =C2=A0 =C2=A0subobjects of various types are defined in [RFC3209], [= RFC3477],
[RFC4873],
=C2=A0 =C2=A0 =C2=A0[RFC4874], [RFC5520] and [RFC5553].=C2=A0 [RFC3473] mod= ified the ERO list
by
=C2=A0 =C2=A0 =C2=A0allowing one or two Label subobjects to be interposed i= n the list
after
a
=C2=A0 =C2=A0 =C2=A0subobject identifying an entity by its IP address or in= terface
identifier.=C2=A0 =C2=A0One
=C2=A0 =C2=A0 =C2=A0or more ERO Hop attributes subobjects applicable to a p= articular hop
MAY
=C2=A0 =C2=A0 =C2=A0be inserted after any of the existing identifying subob= jects defined
in
=C2=A0 =C2=A0 =C2=A0[RFC3209],=C2=A0 [RFC3477], [RFC4873], [RFC4874], [RFC5= 520] and [RFC5553].
=C2=A0 =C2=A0 =C2=A0If any Label subobjects are present for a hop, the ERO = Hop attributes
=C2=A0 =C2=A0 =C2=A0subobject(s) MUST be inserted after the Label subobject= s.

The last two sentences would need to be altered if Hop attributes were
applicable to Labels rather than just to the hop as a whole.

Regards,
Elwyn



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas





--047d7b86d5741bbedf05108b8cb6-- From nobody Thu Mar 5 06:48:46 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E131A000F; Thu, 5 Mar 2015 06:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8eFOPFKyEmP; Thu, 5 Mar 2015 06:48:40 -0800 (PST) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30:5054:ff:fe5e:1643]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867A61A0006; Thu, 5 Mar 2015 06:48:39 -0800 (PST) Received: from mightyatom.folly.org.uk ([81.187.254.250]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1YTX4m-00028T-Ao; Thu, 05 Mar 2015 14:48:36 +0000 Message-ID: <54F86CC7.8080905@folly.org.uk> Date: Thu, 05 Mar 2015 14:48:39 +0000 From: Elwyn Davies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Cyril Margaria References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> <54F5F635.2050304@folly.org.uk> <54F74F12.3020205@folly.org.uk> <54F85971.6040600@folly.org.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gen-art@ietf.org, Lou Berger , draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , teas@ietf.org Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 14:48:44 -0000 Great. Thanks! /Elwyn On 05/03/2015 14:40, Cyril Margaria wrote: > Hi Elwyn, > > Thanks, a new revision addressing the comments have been posted > Name: draft-ietf-teas-lsp-attribute-ro > Revision: 04 > Title: LSP Attribute in ERO > Document date: 2015-03-04 > Group: teas > Pages: 14 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-teas-lsp-attribute-ro-04.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ > Htmlized: > http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-04 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-04 > > Best Regards. > > On 5 March 2015 at 08:26, Elwyn Davies wrote: > >> Hi, Cyril. >> >> Yes.. That looks good. Thanks! >> >> Dong Jie will hopefully take this on board for the loopback flag in >> draft-ietf-teas-rsvp-te-li-lb. We have been discussing this earlier today. >> >> Regards, >> Elwyn >> >> >> On 05/03/2015 03:28, Cyril Margaria wrote: >> >>> Hi, >>> >>> Thanks for the quick feedback, >>> Would the following text modification address your comments . >>> the wording is a bit different, I tried to simplify the description of the >>> TLV scope. >>> >>> As described in [RFC3209] the ERO is managed as a list of subobjects >>> each identifying a specific entity, an abstract node or a link that >>> defines a waypoint in the network path. Identifying subobjects of >>> various types are defined in [RFC3209], [RFC3477], [RFC4873], >>> [RFC4874], [RFC5520] and [RFC5553]. >>> >>> [RFC3473] modified the ERO list by allowing one or two Label >>> subobjects to be interposed in the list after a subobject identifying >>> a link. One or more ERO Hop Attributes subobjects applicable to a >>> particular hop MAY be inserted directly after any of the existing >>> identifying subobjects defined in[RFC3209], [RFC3477], [RFC4873], >>> [RFC4874], [RFC5520] and [RFC5553]. If any Label subobjects are >>> present for a hop, the ERO Hop Attributes subobject(s) MAY also be >>> inserted after the Label subobjects. >>> >>> The attributes specified in a ERO Hop Attributes subobject apply to >>> the immediately preceding subobject(s) in the ERO subobject list. >>> >>> A document defining a specific Hop Attribute TLV has to describe: >>> >>> o after which kinds of ERO subobject they are valid , >>> >>> o if ordering of the Hop Attributes subobject and other ERO >>> subobjects associated with the same hop (e.g., Label subobjects) >>> is significant, >>> >>> o if ordering is significant, how the attribute is interpreted in >>> association with the preceding ERO subobjects, and >>> >>> o any TLV modification rules that might apply. >>> >>> For instance, subobject presence rules can be defined by describing >>> rules similar to [RFC4990] Section 6.1. >>> >>> >>> That would allow a TLV to apply to one (or more) preceding subobject, the >>> type of subobject being left to the TLV. >>> >>> Regarding section 2.2, the following text is proposed: >>> >>> The presence and ordering rule of the Attribute Flags TLV in an ERO >>> Hop Attributes Subobject is defined by each Flag. A document >>> defining a Flag to be used in a Attribute Flags TLV carried in the >>> ERO Hop Attributes Subobject has to describe: >>> >>> o after which kinds of ERO subobject the Flag is valid >>> >>> o if ordering of the Flag and other ERO subobjects associated with >>> the same hop (e.g., Label subobjects) is significant, >>> >>> o if ordering is significant, how the Flag is interpreted in >>> association with the preceding subobjects, >>> >>> o any Flag modification rules that might apply. >>> >>> >>> If its Ok, I can post a new revision shortly. >>> >>> Best Regards >>> Cyril >>> >>> >>> >>> On 4 March 2015 at 13:29, Elwyn Davies wrote: >>> >>> >>>> On 04/03/2015 06:04, Cyril Margaria wrote: >>>> >>>> Hi, >>>>> Thanks for your review, >>>>> Please not that a new revision addressing IANA , APS-DIR and Gen-ART >>>>> comments on revision -02 is available. >>>>> https://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-03 >>>>> >>>>> please see inline. >>>>> >>>>> Hi, Cyril. >>>> Yes: my comments and the new version crossed. >>>> >>>> However -03 doesn't significantly alter para 1 of s2.3. >>>> >>>> Firstly, I am far from expert in this area, so I have not much clue as to >>>> whether it would ever be useful or meaningful to associate an attribute >>>> with a Label rather than with the entity identified by the other >>>> subobject >>>> types. However, it has just occurred to me that with the loopback case, >>>> one needs to decide that if there are two labels, does loopback apply to >>>> both of them or just one? Arrrgggh! >>>> >>>> Perhaps something like the following, replacing the first two paras of >>>> s2.3, would cover all the bases and push the decision down to the >>>> document >>>> that defines the TLV(s)/flags used in the Hop attribute subobjects: >>>> >>>> OLD: >>>> As described in [RFC3209] and [RFC3473] the ERO is managed as a list >>>> where each hop information starts with a subobject identifying an >>>> abstract node or link. The ERO Hop Attributes subobject MAY be >>>> appended after any of the existing subobjects defined in [RFC3209], >>>> [RFC3473], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. >>>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>>> >>>> Document defining specific Hop attribute TLV has to describe after >>>> which kind of subobject they are valid and if TLV modification rules >>>> applies. For instance, subobject presence rules can be defined by >>>> describing rules similar to [RFC4990] Section 6.1. >>>> >>>> NEW: >>>> As described in [RFC3209] the ERO is managed as a list of subobjects >>>> each identifying a specific entity, an abstract node or a link that >>>> defines >>>> a waypoint in the ERO route. Identifying subobjects of various types >>>> are >>>> defined in [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and >>>> [RFC5553]. >>>> >>>> [RFC3473] modified the ERO list by allowing one or two Label >>>> subobjects >>>> to be interposed in the list after a subobject identifying an entity >>>> by >>>> its >>>> IP address or interface identifier. One or more ERO Hop attributes >>>> subobjects applicable to a particular hop MAY be inserted directly >>>> after >>>> any of the existing identifying subobjects defined in [RFC3209], >>>> [RFC3477], >>>> [RFC4873], [RFC4874], [RFC5520] and [RFC5553]. If any Label >>>> subobjects >>>> are present for a hop, the ERO Hop attributes subobject(s) MAY also >>>> be >>>> inserted after the Label subobjects. >>>> >>>> The attributes specified in a ERO Hop attributes subobject apply to >>>> the >>>> hop >>>> that ends at the route waypoint identified by the immediately >>>> preceding >>>> identifying subobject in the ERO subobject list. >>>> >>>> A document defining a specific Hop attribute TLV has to describe >>>> - after which kinds of subobject they are valid , >>>> - if ordering of the Hop attributes subobject and other >>>> subobjects >>>> associated with the same hop (e.g., Label subobjects) is >>>> significant, >>>> - if ordering is significant, how the attribute is interpreted in >>>> association with the preceding subobjects, and >>>> - any TLV modification rules that might apply. >>>> For instance, subobject presence rules can be defined by describing >>>> rules >>>> similar to [RFC4990] Section 6.1. >>>> >>>> This might require a few words added to s2.2 to specify that the ordering >>>> decision for individual flags is up to the definition of the flag. In >>>> turn >>>> that possibly means that the loopback draft needs to think about whether >>>> the loopback applies to both labels or only the one the loopback flag is >>>> after as mentioned above. >>>> >>>> Regards, >>>> Elwyn >>>> >>>> PS >>>> There is discussion about the .all aliases going to WG lists as well as >>>> relevant individuals. The long standing position was that they didn't >>>> but >>>> change has recently been mooted. >>>> >>>> /E >>>> >>>> >>>> >>>>> On 3 March 2015 at 12:58, Elwyn Davies wrote: >>>>> >>>>> Hi. >>>>> >>>>>> In the process of doing the gen-art review of >>>>>> draft-ietf-teas-rsvp-te-li-lb for IETF last call, I needed to look at >>>>>> draft-ietf-teas-lsp-attribute-ro-02 in connection with some comments >>>>>> about >>>>>> ordering of subobjects in the loopback draft. >>>>>> >>>>>> I thought that the text in the first paragraph of s2.3: >>>>>> >>>>>> As described in [RFC3209 ] >>>>>> and >>>>>> [RFC3473 ] the ERO is managed as >>>>>> a >>>>>> list >>>>>> where each hop information starts with a subobject identifying an >>>>>> abstract node or link. The ERO Hop Attributes subobject MAY be >>>>>> appended after any of the existing subobjects defined in [RFC3209 >>>>>> < >>>>>> https://tools.ietf.org/html/rfc3209>], >>>>>> [RFC3473 ], [RFC3477 < >>>>>> https://tools.ietf.org/html/rfc3477>], [RFC4873 < >>>>>> https://tools.ietf.org/html/rfc4873>], [RFC4874 < >>>>>> https://tools.ietf.org/html/rfc4874>], [RFC5520 < >>>>>> https://tools.ietf.org/html/rfc5520>] and [RFC5553 < >>>>>> https://tools.ietf.org/html/rfc5553>]. >>>>>> >>>>>> Several ERO Hop Attributes subobject MAY be present, for each hop. >>>>>> >>>>>> was not very clear: The use of 'appended' was slightly confusing. I >>>>>> felt >>>>>> it needed something a bit closer to the "Presence Rules" that are given >>>>>> for >>>>>> RRO subobjects in RFC 5420, s7.3.1 to make it quite clear what is going >>>>>> on. >>>>>> >>>>>> I am not totally clear what would happen in the case of (say) an IPv4 >>>>>> address subobject followed by two Label subobjects. The wording seems >>>>>> to >>>>>> indicate that Hop attributes can be inserted anywhere in the sequence >>>>>> of >>>>>> three subobjects - but would they specifically apply to one or other >>>>>> Label >>>>>> if they were inserted after a Label or would they always apply >>>>>> generically >>>>>> to the hop terminated at the IPv4 address entity? >>>>>> >>>>>> >>>>>> draft-ietf-teas-lsp-attribute-ro tries to leave that open to the >>>>>> >>>>> documents >>>>> defining the TLVs. We are not excluding an Attribute that applies to a >>>>> Label or Interface. If the subobject would be inserted after a Label >>>>> Subobject, the Attribute TLVs would apply to the Labels. >>>>> >>>>> This is based on the following review comment:" >>>>> I think *this* I-D needs to make it clear what the expectations are: >>>>> >>>>> 1. The sub-object is allowed at any point in the ERO >>>>> 2. The document that specifies a TLV for the sub-object must make it >>>>> clear where in an ERO a sub-object containing that TLV is allowed >>>>> and >>>>> not allowed." >>>>> >>>>> Do you think this is reasonable or we should exclude TLVs scoped to >>>>> labels? >>>>> In the latter case, I would add you suggested text. >>>>> >>>>> Best Regards. >>>>> Cyril >>>>> >>>>> PS: It seems there are errors with the tools.ietf.org aliases >>>>> >>>>> >>>>> My suggestion for rewording, based on the assumption that the hop >>>>> >>>>>> attributes apply to the hop rather than any of the labels, would be: >>>>>> >>>>>> As described in [RFC3209] the ERO is managed as a list of >>>>>> subobjects >>>>>> each identifying a specific entity, an abstract node or a link. >>>>>> Identifying >>>>>> subobjects of various types are defined in [RFC3209], [RFC3477], >>>>>> [RFC4873], >>>>>> [RFC4874], [RFC5520] and [RFC5553]. [RFC3473] modified the ERO >>>>>> list >>>>>> by >>>>>> allowing one or two Label subobjects to be interposed in the list >>>>>> after >>>>>> a >>>>>> subobject identifying an entity by its IP address or interface >>>>>> identifier. One >>>>>> or more ERO Hop attributes subobjects applicable to a particular >>>>>> hop >>>>>> MAY >>>>>> be inserted after any of the existing identifying subobjects >>>>>> defined >>>>>> in >>>>>> [RFC3209], [RFC3477], [RFC4873], [RFC4874], [RFC5520] and >>>>>> [RFC5553]. >>>>>> If any Label subobjects are present for a hop, the ERO Hop >>>>>> attributes >>>>>> subobject(s) MUST be inserted after the Label subobjects. >>>>>> >>>>>> The last two sentences would need to be altered if Hop attributes were >>>>>> applicable to Labels rather than just to the hop as a whole. >>>>>> >>>>>> Regards, >>>>>> Elwyn >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Teas mailing list >>>>>> Teas@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/teas >>>>>> >>>>>> >>>>>> >>>>>> From nobody Thu Mar 5 07:31:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195B01A0302 for ; Thu, 5 Mar 2015 07:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4rhJzSDsRae for ; Thu, 5 Mar 2015 07:31:22 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id CAED01A016A for ; Thu, 5 Mar 2015 07:31:22 -0800 (PST) Received: (qmail 27600 invoked by uid 0); 5 Mar 2015 15:31:22 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 5 Mar 2015 15:31:22 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id zrW61p00X2SSUrH01rW9YU; Thu, 05 Mar 2015 08:30:09 -0700 X-Authority-Analysis: v=2.1 cv=e6KVF8Z/ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=0ZgzDHaQzhVBHrr1te0A:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=WEnjuxhwMYlwDxV4BKLV0Lxu11POSQ6TkCBkfoPgb+U=; b=ddI1k6O0/jH1eIXgurtdhzH7bGsSlHQB0HpH9K3qc7ru76ZyWMjDmZIub5OAGdSLIceqh6OQ75PcuzWWcgDeg6nmsLYtgljYZGRTSd43Yh1jrmjJMVlXhMXApGPcnmxN; Received: from box313.bluehost.com ([69.89.31.113]:57009 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTXix-0004xr-JO for teas@ietf.org; Thu, 05 Mar 2015 08:30:07 -0700 Message-ID: <54F87679.5080308@labn.net> Date: Thu, 05 Mar 2015 10:30:01 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: teas@ietf.org References: <20150305140816.27105.42841.idtracker@ietfa.amsl.com> In-Reply-To: <20150305140816.27105.42841.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-lsp-attribute-ro-04.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 15:31:24 -0000 WG, It looks like the gen-art review comments have been addressed. Please take a look at this version and comment as you see fit. A diff from the rev submitted for publication can be found at: http://www.ietf.org/rfcdiff?url1=draft-ietf-teas-lsp-attribute-ro-01&url2=draft-ietf-teas-lsp-attribute-ro-04 Thanks, Lou On 3/5/2015 9:08 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. > > Title : LSP Attribute in ERO > Authors : Cyril Margaria > Giovanni Martinelli > Steve Balls > Ben Wright > Filename : draft-ietf-teas-lsp-attribute-ro-04.txt > Pages : 14 > Date : 2015-03-05 > > Abstract: > RFC5420 extends RSVP-TE to specify or record generic attributes which > apply to the whole of the path of a Label Switched Path (LSP). This > document defines an extension to the RSVP Explicit Route Object (ERO) > and Record Route Object (RRO) objects to allow it to specify or > record generic attributes which apply to a given hop. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Mar 5 09:23:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94C1A1BA7 for ; Thu, 5 Mar 2015 09:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwwX-R5Y-ltw for ; Thu, 5 Mar 2015 09:23:35 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 969131A1A04 for ; Thu, 5 Mar 2015 09:19:54 -0800 (PST) Received: (qmail 32742 invoked by uid 0); 5 Mar 2015 17:19:53 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 5 Mar 2015 17:19:53 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id ztJU1p00f2SSUrH01tJXRx; Thu, 05 Mar 2015 10:18:33 -0700 X-Authority-Analysis: v=2.1 cv=bJKFfpOZ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=MAdbLhbQS6qKcJyJOQcA:9 a=WgvnyJsCr2KwxC_k:21 a=oslUO8I_FPtdAQgS:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=0KJwabzZqSmn3PV6dmVvVzjMrAFq+G5gHETTiYOPzzk=; b=y7oA+/cXFer3v15ksFf2YgIyVvkkebT8SJLYiD6HwMAhZNd1GHL5s4ZM/21UxrEyBB+0LgICOfozquqdfx6jW+NlTrUcMSyBrHuR49k830mmkO2YOulsnvjCa4mQWVTS; Received: from box313.bluehost.com ([69.89.31.113]:37050 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTZPp-0002Nh-A4; Thu, 05 Mar 2015 10:18:29 -0700 Message-ID: <54F88FE0.9040206@labn.net> Date: Thu, 05 Mar 2015 12:18:24 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dhruv Dhody , "mpls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Rtg-yang-coord@ietf.org, "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:23:36 -0000 Hi Dhruv, Good stuff! There's already some related work going on based on the TE LSP drafts/work started in MPLS and now in the TEAS WG. -- This was mentioned at the TEAS interim too, see http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes-i= nterim-2014-teas-1 It looks like you don't completely overlap as you are also considering non-TE LSPs.=20 So I guess a basic question to answer is what is the relationship of the models of TE and non-TE LSPs. e.g, - a generic LSP model with parallel TE and non-TE sub models - a generic LSP model with protocol specific models - a generic LSP model with some mix of the above (which I think you are proposing) - no generic LSP model, and separate TE and non-TE sub models - etc It's not clear to me how much value a generic model brings, but details always help to clarify the situation. =20 My preference would be to have more details on the non-TE models (to compare against the TE model) before deciding on the need for / value of a generic LSP model. Lou On 3/5/2015 11:48 AM, Dhruv Dhody wrote: > Hi, > > Xian and I have created generic base yang model for LSPs. This model > is expected to be augmented by seperate data model with specific > signalling protocol and technology. > > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 > > Comments / Suggestions ? > > We need to work out the relationship with the rest of MPLS yang model > which can be hashed out in Dallas. > > Regards, > Dhruv / Xian > > Excuse the obvious nit with the LSP abbreviation expansion :P > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Thu Mar 5 09:29:18 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5091A1B45 for ; Thu, 5 Mar 2015 09:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYjqiGIm2h1M for ; Thu, 5 Mar 2015 09:29:09 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id DD98D1A1B62 for ; Thu, 5 Mar 2015 09:29:07 -0800 (PST) Received: (qmail 1975 invoked by uid 0); 5 Mar 2015 17:29:05 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 5 Mar 2015 17:29:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id ztSV1p0082SSUrH01tTq7N; Thu, 05 Mar 2015 10:27:50 -0700 X-Authority-Analysis: v=2.1 cv=SqADtp+0 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=cyJrvG4EC681TIjjZnoA:9 a=_MfVFuVwUvSDVJMo:21 a=ZrO89E7nRNvlzyWS:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ieRHcYZO+7UYqjo4xCM1cf3z0L27jX8iIU62fYElCik=; b=rff88LofRuF3ynN4Wzfl59xnRo+0LeQ8c13di+lbz/TrdtvFAX0WAEJLYzPy24W3kCOr8ZvydrP/NVjB+XuZUr3NQkpzLcaVHC/sQa016DvE0bVoi8Zw2YaYRbpbkudC; Received: from box313.bluehost.com ([69.89.31.113]:37848 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTZYm-00040J-JY; Thu, 05 Mar 2015 10:27:44 -0700 Message-ID: <54F8920A.2090204@labn.net> Date: Thu, 05 Mar 2015 12:27:38 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dhruv Dhody , "mpls@ietf.org" References: <54F88FE0.9040206@labn.net> In-Reply-To: <54F88FE0.9040206@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Rtg-yang-coord@ietf.org, "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:29:11 -0000 I should have made clear that my previous mail and stated preference was as an individual.=20 As TEAS co-chair: if you need a place to discuss the generic model in Dallas, we're happy to have you in TEAS, and will complement our planned TE model related discussion. Clearly non-te LSP model specifics should be discussed in their respective WGs.=20 Lou On 3/5/2015 12:18 PM, Lou Berger wrote: > Hi Dhruv, > Good stuff! There's already some related work going on based on th= e > TE LSP drafts/work started in MPLS and now in the TEAS WG. -- This was= > mentioned at the TEAS interim too, see > http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes= -interim-2014-teas-1 > > It looks like you don't completely overlap as you are also considering > non-TE LSPs.=20 > > So I guess a basic question to answer is what is the relationship of th= e > models of TE and non-TE LSPs. e.g, > - a generic LSP model with parallel TE and non-TE sub models > - a generic LSP model with protocol specific models > - a generic LSP model with some mix of the above (which I think you are= > proposing) > - no generic LSP model, and separate TE and non-TE sub models > - etc > > It's not clear to me how much value a generic model brings, but details= > always help to clarify the situation. =20 > > My preference would be to have more details on the non-TE models (to > compare against the TE model) before deciding on the need for / value o= f > a generic LSP model. > > Lou > > On 3/5/2015 11:48 AM, Dhruv Dhody wrote: >> Hi, >> >> Xian and I have created generic base yang model for LSPs. This model >> is expected to be augmented by seperate data model with specific >> signalling protocol and technology. >> >> See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 >> >> Comments / Suggestions ? >> >> We need to work out the relationship with the rest of MPLS yang model >> which can be hashed out in Dallas. >> >> Regards, >> Dhruv / Xian >> >> Excuse the obvious nit with the LSP abbreviation expansion :P >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > From nobody Thu Mar 5 19:12:40 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC211AC3E5; Thu, 5 Mar 2015 19:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KpBfYinnTjR; Thu, 5 Mar 2015 19:12:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E89241AC3CE; Thu, 5 Mar 2015 19:12:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306031213.16226.96523.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 19:12:13 -0800 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-network-assigned-upstream-label-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 03:12:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Network Assigned Upstream-Label Authors : Vishnu Pavan Beeram Igor Bryskin Filename : draft-ietf-teas-network-assigned-upstream-label-01.txt Pages : 9 Date : 2015-03-05 Abstract: This document discusses a GMPLS RSVP-TE protocol mechanism that enables the network to assign an upstream-label for a given LSP. This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream-label on its own and needs to rely on the network to pick an appropriate label. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-network-assigned-upstream-label/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-network-assigned-upstream-label-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-network-assigned-upstream-label-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 6 04:00:50 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3E1ACDAE; Fri, 6 Mar 2015 04:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-hvOakU3gpE; Fri, 6 Mar 2015 04:00:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AEB1ACDA3; Fri, 6 Mar 2015 04:00:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPY58768; Fri, 06 Mar 2015 12:00:42 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Mar 2015 12:00:41 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.70]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0158.001; Fri, 6 Mar 2015 17:30:30 +0530 From: Dhruv Dhody To: "'Lou Berger'" , Dhruv Dhody , "mpls@ietf.org" Thread-Topic: [Teas] [mpls] Generic LSP Yang Thread-Index: AQHQV2RAArbxfMQCJkWYNeXdfaQGXZ0NxckAgAFI2RA= Date: Fri, 6 Mar 2015 12:00:29 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> References: <54F88FE0.9040206@labn.net> In-Reply-To: <54F88FE0.9040206@labn.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.41.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:00:48 -0000 Hi Lou, > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 05 March 2015 22:48 > To: Dhruv Dhody; mpls@ietf.org > Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG > Subject: Re: [Teas] [mpls] Generic LSP Yang >=20 > Hi Dhruv, > Good stuff! There's already some related work going on based on the = TE > LSP drafts/work started in MPLS and now in the TEAS WG. -- This was > mentioned at the TEAS interim too, see > http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes- > interim-2014-teas-1 >=20 > It looks like you don't completely overlap as you are also considering no= n-TE > LSPs. [Dhruv]: Yes, our aim is to go one level up and see if we can have a generi= c LSP yang model including TE and non-TE, as well any signaling protocol or= lack thereof (static, SR). =20 >=20 > So I guess a basic question to answer is what is the relationship of the > models of TE and non-TE LSPs. e.g, > - a generic LSP model with parallel TE and non-TE sub models > - a generic LSP model with protocol specific models > - a generic LSP model with some mix of the above (which I think you are > proposing) > - no generic LSP model, and separate TE and non-TE sub models > - etc [Dhruv]: Our aim is to explore and see if we have attributes common to all = LSP irrespective of TE/non-TE; signaling protocol, Segment Routing and even= PCEP to warrant such a generic LSP model.=20 A possible overall relationship with the model is in the draft -=20 +---------------+ | Generic LSPDB | | ietf-lspdb | +-------^-------+ | --------------------------------------------- | | | | | | | | +----+----+ +-------+-------+ +----+----+ +--+--+ | LDP-LSP | | BGP-LSP | | TE-LSP | | SR | | | | | | | | | +---------+ +---------------+ +----^----+ +--^--+ | | ----------- | | | | +----+----+ +--+--+ | RSVP-TE | | SR- | | | | TE | +----^----+ +--^--+ | | | | ----------- | +----+----+ | PCEP | | | +---------+ >=20 > It's not clear to me how much value a generic model brings, but details > always help to clarify the situation. >=20 > My preference would be to have more details on the non-TE models (to comp= are > against the TE model) before deciding on the need for / value of a generi= c > LSP model. [Dhruv]: Yes, I think that would surely help.=20 IMHO the ease of augmentation and having a generic base model is one of the= key advantages of YANG, so we hope its a worthwhile exercise to explore th= e need for such a generic model instead of separate TE and non-TE models.=20 Regards, Dhruv >=20 > Lou >=20 > On 3/5/2015 11:48 AM, Dhruv Dhody wrote: > > Hi, > > > > Xian and I have created generic base yang model for LSPs. This model > > is expected to be augmented by seperate data model with specific > > signalling protocol and technology. > > > > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 > > > > Comments / Suggestions ? > > > > We need to work out the relationship with the rest of MPLS yang model > > which can be hashed out in Dallas. > > > > Regards, > > Dhruv / Xian > > > > Excuse the obvious nit with the LSP abbreviation expansion :P > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Fri Mar 6 04:06:50 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937491ACDB3; Fri, 6 Mar 2015 04:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF1TDSP8Vi4U; Fri, 6 Mar 2015 04:06:45 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 118551ACDAF; Fri, 6 Mar 2015 04:06:45 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Dhruv Dhody'" , "'Lou Berger'" , "'Dhruv Dhody'" , References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> Date: Fri, 6 Mar 2015 07:06:30 -0500 Message-ID: <0eb701d05805$fbb2bc60$f3183520$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGF8qnWNbZVbUsAI+Uo8DjiQRkeSgEd1aRRApdTD6OdhnyfUA== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, "'Zhangxian \(Xian\)'" , 'TEAS WG' Subject: Re: [Teas] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:06:47 -0000 Dhruv, Xian and Lou: Thank you for working on the genric LSP work. After the TEAS WG, could the I2RS WG get a summary of your discussion. Sue Hares -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Friday, March 06, 2015 7:00 AM To: 'Lou Berger'; Dhruv Dhody; mpls@ietf.org Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang Hi Lou, > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 05 March 2015 22:48 > To: Dhruv Dhody; mpls@ietf.org > Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG > Subject: Re: [Teas] [mpls] Generic LSP Yang > > Hi Dhruv, > Good stuff! There's already some related work going on based on > the TE LSP drafts/work started in MPLS and now in the TEAS WG. -- > This was mentioned at the TEAS interim too, see > http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minute > s- > interim-2014-teas-1 > > It looks like you don't completely overlap as you are also considering > non-TE LSPs. [Dhruv]: Yes, our aim is to go one level up and see if we can have a generic LSP yang model including TE and non-TE, as well any signaling protocol or lack thereof (static, SR). > > So I guess a basic question to answer is what is the relationship of > the models of TE and non-TE LSPs. e.g, > - a generic LSP model with parallel TE and non-TE sub models > - a generic LSP model with protocol specific models > - a generic LSP model with some mix of the above (which I think you > are > proposing) > - no generic LSP model, and separate TE and non-TE sub models > - etc [Dhruv]: Our aim is to explore and see if we have attributes common to all LSP irrespective of TE/non-TE; signaling protocol, Segment Routing and even PCEP to warrant such a generic LSP model. A possible overall relationship with the model is in the draft - +---------------+ | Generic LSPDB | | ietf-lspdb | +-------^-------+ | --------------------------------------------- | | | | | | | | +----+----+ +-------+-------+ +----+----+ +--+--+ | LDP-LSP | | BGP-LSP | | TE-LSP | | SR | | | | | | | | | +---------+ +---------------+ +----^----+ +--^--+ | | ----------- | | | | +----+----+ +--+--+ | RSVP-TE | | SR- | | | | TE | +----^----+ +--^--+ | | | | ----------- | +----+----+ | PCEP | | | +---------+ > > It's not clear to me how much value a generic model brings, but > details always help to clarify the situation. > > My preference would be to have more details on the non-TE models (to > compare against the TE model) before deciding on the need for / value > of a generic LSP model. [Dhruv]: Yes, I think that would surely help. IMHO the ease of augmentation and having a generic base model is one of the key advantages of YANG, so we hope its a worthwhile exercise to explore the need for such a generic model instead of separate TE and non-TE models. Regards, Dhruv > > Lou > > On 3/5/2015 11:48 AM, Dhruv Dhody wrote: > > Hi, > > > > Xian and I have created generic base yang model for LSPs. This model > > is expected to be augmented by seperate data model with specific > > signalling protocol and technology. > > > > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 > > > > Comments / Suggestions ? > > > > We need to work out the relationship with the rest of MPLS yang > > model which can be hashed out in Dallas. > > > > Regards, > > Dhruv / Xian > > > > Excuse the obvious nit with the LSP abbreviation expansion :P > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Fri Mar 6 06:05:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960261ACE1D for ; Fri, 6 Mar 2015 06:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lE9mF2CNg-w for ; Fri, 6 Mar 2015 06:05:20 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id EBCCD1ACE30 for ; Fri, 6 Mar 2015 06:05:15 -0800 (PST) Received: (qmail 16244 invoked by uid 0); 6 Mar 2015 14:05:15 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 6 Mar 2015 14:05:15 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 0M5B1q00x2SSUrH01M5EAr; Fri, 06 Mar 2015 14:05:14 -0700 X-Authority-Analysis: v=2.1 cv=U5gBU4bu c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=O0Hm_RYbqtG38CgO0mIA:9 a=kHJIFfDfcLGMyUwK:21 a=JqNYE33C9tJtipj1:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=86egnpqUk9R1OhEdKzQyfQ6tvYZgGFpMj9rAzPxNAXk=; b=Y3OmGBQdlMKCtGtNQpJ9Q56l3oSAj+ZARhBRpo5NaKm7hKuHIoh82C2juq2gDqbsGso3r6jzc+QWfPigE2ZkNbh4EadyqMZhOTXvQyvtzj/r2DrrBxJgQEltpc7WjLJO; Received: from box313.bluehost.com ([69.89.31.113]:33814 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YTssK-000692-Ht; Fri, 06 Mar 2015 07:05:12 -0700 Message-ID: <54F9B415.9040508@labn.net> Date: Fri, 06 Mar 2015 09:05:09 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dhruv Dhody , Dhruv Dhody , "mpls@ietf.org" References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 14:05:24 -0000 Dhruv, On 03/06/2015 07:00 AM, Dhruv Dhody wrote: > Hi Lou, > >> -----Original Message----- >> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: 05 March 2015 22:48 >> To: Dhruv Dhody; mpls@ietf.org >> Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG >> Subject: Re: [Teas] [mpls] Generic LSP Yang >> >> Hi Dhruv, >> Good stuff! There's already some related work going on based on the TE >> LSP drafts/work started in MPLS and now in the TEAS WG. -- This was >> mentioned at the TEAS interim too, see >> http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minutes- >> interim-2014-teas-1 >> >> It looks like you don't completely overlap as you are also considering non-TE >> LSPs. > > [Dhruv]: Yes, our aim is to go one level up and see if we can have a > generic LSP yang model including TE and non-TE, as well any signaling > protocol or lack thereof (static, SR). > Understood. BTW non-signaled TE is still part of TE architecture and the yang model work underway in TEAS. (TP, and to some degree PCE really made this point clear.) >> >> So I guess a basic question to answer is what is the relationship of the >> models of TE and non-TE LSPs. e.g, >> - a generic LSP model with parallel TE and non-TE sub models >> - a generic LSP model with protocol specific models >> - a generic LSP model with some mix of the above (which I think you are >> proposing) >> - no generic LSP model, and separate TE and non-TE sub models >> - etc > > [Dhruv]: Our aim is to explore and see if we have attributes common > to all LSP irrespective of TE/non-TE; signaling protocol, Segment > Routing and even PCEP to warrant such a generic LSP model. > Sure. PCE driven TE LSPs are in scope of the generic TE YANG models being developed. PCEP protocol specifics belong to PCE. > A possible overall relationship with the model is in the draft - > +---------------+ > | Generic LSPDB | > | ietf-lspdb | > +-------^-------+ > | > --------------------------------------------- > | | | | > | | | | > +----+----+ +-------+-------+ +----+----+ +--+--+ > | LDP-LSP | | BGP-LSP | | TE-LSP | | SR | > | | | | | | | | > +---------+ +---------------+ +----^----+ +--^--+ > | | > ----------- > | | > | | > +----+----+ +--+--+ > | RSVP-TE | | SR- | > | | | TE | > +----^----+ +--^--+ > | | > | | > ----------- > | > +----+----+ > | PCEP | > | | > +---------+ > > >> >> It's not clear to me how much value a generic model brings, but details >> always help to clarify the situation. >> >> My preference would be to have more details on the non-TE models (to compare >> against the TE model) before deciding on the need for / value of a generic >> LSP model. > > [Dhruv]: Yes, I think that would surely help. Glad to hear we're in agreement. > IMHO the ease of augmentation and having a generic base model is one > of the key advantages of YANG, so we hope its a worthwhile exercise > to explore the need for such a generic model instead of separate TE > and non-TE models. > The details of each will certainly demonstrate the degree of overlap. Thanks, Lou > Regards, > Dhruv > >> >> Lou >> >> On 3/5/2015 11:48 AM, Dhruv Dhody wrote: >>> Hi, >>> >>> Xian and I have created generic base yang model for LSPs. This model >>> is expected to be augmented by seperate data model with specific >>> signalling protocol and technology. >>> >>> See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 >>> >>> Comments / Suggestions ? >>> >>> We need to work out the relationship with the rest of MPLS yang model >>> which can be hashed out in Dallas. >>> >>> Regards, >>> Dhruv / Xian >>> >>> Excuse the obvious nit with the LSP abbreviation expansion :P >>> >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > From nobody Fri Mar 6 08:06:48 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12C1ACE0A; Fri, 6 Mar 2015 05:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDlbta1Zm7Le; Fri, 6 Mar 2015 05:11:46 -0800 (PST) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0C71ACE06; Fri, 6 Mar 2015 05:11:39 -0800 (PST) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t26DBUV7014065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Mar 2015 08:11:30 -0500 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 6 Mar 2015 08:11:30 -0500 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1076.3; Fri, 6 Mar 2015 08:11:30 -0500 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Fri, 6 Mar 2015 08:11:30 -0500 From: Igor Bryskin To: Dhruv Dhody , "'Lou Berger'" , Dhruv Dhody , "mpls@ietf.org" Thread-Topic: [mpls] [Teas] Generic LSP Yang Thread-Index: AQHQWAUzsQkQu7Ewm0G1yY1vtfqWpZ0PbO1g Date: Fri, 6 Mar 2015 13:11:28 +0000 Message-ID: <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> In-Reply-To: <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-06_04:2015-03-06,2015-03-06,1970-01-01 signatures=0 Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 08:06:40 -0800 Cc: "Rtg-yang-coord@ietf.org" , "Zhangxian \(Xian\)" , TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 13:11:52 -0000 Druv, IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should hav= e totally independent models each being developed in respective WG. Igor -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: Friday, March 06, 2015 7:00 AM To: 'Lou Berger'; Dhruv Dhody; mpls@ietf.org Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG Subject: Re: [mpls] [Teas] Generic LSP Yang Hi Lou, > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 05 March 2015 22:48 > To: Dhruv Dhody; mpls@ietf.org > Cc: Rtg-yang-coord@ietf.org; Zhangxian (Xian); TEAS WG > Subject: Re: [Teas] [mpls] Generic LSP Yang >=20 > Hi Dhruv, > Good stuff! There's already some related work going on based on=20 > the TE LSP drafts/work started in MPLS and now in the TEAS WG. --=20 > This was mentioned at the TEAS interim too, see > http://www.ietf.org/proceedings/interim/2014/12/18/teas/minutes/minute > s- > interim-2014-teas-1 >=20 > It looks like you don't completely overlap as you are also considering=20 > non-TE LSPs. [Dhruv]: Yes, our aim is to go one level up and see if we can have a generi= c LSP yang model including TE and non-TE, as well any signaling protocol or= lack thereof (static, SR). =20 >=20 > So I guess a basic question to answer is what is the relationship of=20 > the models of TE and non-TE LSPs. e.g, > - a generic LSP model with parallel TE and non-TE sub models > - a generic LSP model with protocol specific models > - a generic LSP model with some mix of the above (which I think you=20 > are > proposing) > - no generic LSP model, and separate TE and non-TE sub models > - etc [Dhruv]: Our aim is to explore and see if we have attributes common to all = LSP irrespective of TE/non-TE; signaling protocol, Segment Routing and even= PCEP to warrant such a generic LSP model.=20 A possible overall relationship with the model is in the draft -=20 +---------------+ | Generic LSPDB | | ietf-lspdb | +-------^-------+ | --------------------------------------------- | | | | | | | | +----+----+ +-------+-------+ +----+----+ +--+--+ | LDP-LSP | | BGP-LSP | | TE-LSP | | SR | | | | | | | | | +---------+ +---------------+ +----^----+ +--^--+ | | ----------- | | | | +----+----+ +--+--+ | RSVP-TE | | SR- | | | | TE | +----^----+ +--^--+ | | | | ----------- | +----+----+ | PCEP | | | +---------+ >=20 > It's not clear to me how much value a generic model brings, but=20 > details always help to clarify the situation. >=20 > My preference would be to have more details on the non-TE models (to=20 > compare against the TE model) before deciding on the need for / value=20 > of a generic LSP model. [Dhruv]: Yes, I think that would surely help.=20 IMHO the ease of augmentation and having a generic base model is one of the= key advantages of YANG, so we hope its a worthwhile exercise to explore th= e need for such a generic model instead of separate TE and non-TE models.=20 Regards, Dhruv >=20 > Lou >=20 > On 3/5/2015 11:48 AM, Dhruv Dhody wrote: > > Hi, > > > > Xian and I have created generic base yang model for LSPs. This model=20 > > is expected to be augmented by seperate data model with specific=20 > > signalling protocol and technology. > > > > See https://tools.ietf.org/html/draft-zhang-mpls-lspdb-yang-00 > > > > Comments / Suggestions ? > > > > We need to work out the relationship with the rest of MPLS yang=20 > > model which can be hashed out in Dallas. > > > > Regards, > > Dhruv / Xian > > > > Excuse the obvious nit with the LSP abbreviation expansion :P > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Sat Mar 7 03:47:49 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7451A8AFC; Sat, 7 Mar 2015 03:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv25GS90-kgP; Sat, 7 Mar 2015 03:47:45 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382A31A8944; Sat, 7 Mar 2015 03:47:45 -0800 (PST) Received: by iebtr6 with SMTP id tr6so18802128ieb.2; Sat, 07 Mar 2015 03:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KIL9YhltzCEfaudBN6DptPw+SBWWO39pPiMNcYg6Uwg=; b=IZEpRcdUn8NecUTYgDMVLk9oIU1oRuFBz8eaC5dXM0dPSiKO9doJ/q1b7Q04q4Dlxs 7GjjPqlQmgXYltWKfMoEA8luKATBW/O9I6nvDy32Jcapzi5EjRrN//pCZgSRN9LEwJ1Q hy8HrHtIZ+LkpIM3Ndijha3a7oyQdxVgrSXpiR0q4R+Qb8dv06ek1q4VG4yRqZtZTGsP mUGPvLdYoBHwfA/LKtyc/OQ3kGEP/pbyi36sJX3LZ0RtsdYn8pvmcRYJAZ849/x0vnRj xSWpTfODu8LclqObRYp8GwV7wFyyJkjtF281qdn5h2LZI/yoeoEXwBZomqTDNRVLU0Zn 4MhQ== MIME-Version: 1.0 X-Received: by 10.50.131.196 with SMTP id oo4mr34713906igb.2.1425728864709; Sat, 07 Mar 2015 03:47:44 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sat, 7 Mar 2015 03:47:44 -0800 (PST) In-Reply-To: <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> Date: Sat, 7 Mar 2015 12:47:44 +0100 X-Google-Sender-Auth: 8rM4PVxET_R5zMNNlI6UAfaRfos Message-ID: From: Robert Raszuk To: Igor Bryskin , Dhruv Dhody Content-Type: multipart/alternative; boundary=047d7b2e146587353e0510b15ed2 Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "mpls@ietf.org" , TEAS WG Subject: Re: [Teas] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 11:47:46 -0000 --047d7b2e146587353e0510b15ed2 Content-Type: text/plain; charset=UTF-8 I would agree with Igor. Other then name overlap those are completely different technologies and artificially putting them under "LSP" umbrella just does not bring any value, but only confuses things even more. Q: What SPRING-LSP has anything in common with "label" when you use v6 header ? If you want to search for some commonalities let's remove LDP-LSPs from this mix (as the is not relevant) and leave TE-LSP & SPRING + maybe also add BIER as well as change the name to Generic-EP (Engineered Paths). I see no value of goruping based on the fact that data plane uses mpls labels, but rather I would see reasonable to provide models based on the transport path characteristics for the traffic it is to carry. Best, r. On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin wrote: > Druv, > > IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should > have totally independent models each being developed in respective WG. > > Igor > --047d7b2e146587353e0510b15ed2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would agree with I= gor.

Other then name overlap tho= se are completely different technologies and artificially putting them unde= r "LSP" umbrella just does not bring any value, but only confuses= things even more.=C2=A0

Q: What= SPRING-LSP has anything in common with "label" when you use v6 h= eader ?=C2=A0

If you want to sea= rch for some commonalities let's remove LDP-LSPs from this mix (as the = is not relevant) and leave TE-LSP & SPRING + maybe also add BIER as wel= l as change the name to Generic-EP (Engineered Paths).
<= br>
I see no value of goruping based on the fact that da= ta plane uses mpls labels, but rather I would see reasonable to provide mod= els based on the transport path characteristics for the traffic it is to ca= rry. =C2=A0

Best,
r.


On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin <= IBryskin@advaoptical.com> wrote:
Druv,

IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should hav= e totally independent models each being developed in respective WG.

Igor

=C2=A0
--047d7b2e146587353e0510b15ed2-- From nobody Sat Mar 7 05:18:34 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CD61A9028; Sat, 7 Mar 2015 05:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kOqbkjLO9qB; Sat, 7 Mar 2015 05:18:27 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819D11A8AC7; Sat, 7 Mar 2015 05:18:27 -0800 (PST) Received: from [192.168.1.6] (unknown [49.149.191.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2AF6A1801127; Sat, 7 Mar 2015 14:18:25 +0100 (CET) From: Loa Andersson Content-Type: multipart/alternative; boundary=Apple-Mail-29E763CC-C36B-4A19-8FBA-59CDF33D8E5A Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Sat, 7 Mar 2015 21:18:23 +0800 References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: To: "teas@ietf.org, mpls@ietf.org, robert@raszuk.net" X-Mailer: iPad Mail (12B466) Archived-At: Subject: Re: [Teas] [Rtg-yang-coord] [mpls] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 13:18:32 -0000 --Apple-Mail-29E763CC-C36B-4A19-8FBA-59CDF33D8E5A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Robert, =46rom one perspective I agree with you and Igor, however if you think about= MPLS LSPs, from a data plane perspective - and that is where OAM operates, t= here almost no difference between a TE-LSP a LDP-LSP and a SPRING MPLS LSP c= ome very close.=20 If you the other hand think of LSPs for other data planes the "nothing in co= mmon" is an almost true statement. =46rom that point of view I think differe= nt models are where we will end up, but I also think that we need "separatio= n with moderation".=20 But nothing is so simple that we can capture it in one very simple statemen= t, we have hacking away on this for 30 years now, I'd advice taking architec= ture and history into consideration, as well as viewing the sky from a diffe= rent perspective than from the bottom of a deep well. Let me also say that I'm very supportive of all the good work going on in th= is area.=20 /Loa Sent from my iPad > On 07 Mar 2015, at 19:47, Robert Raszuk wrote: >=20 >=20 > I would agree with Igor. >=20 > Other then name overlap those are completely different technologies and ar= tificially putting them under "LSP" umbrella just does not bring any value, b= ut only confuses things even more.=20 >=20 > Q: What SPRING-LSP has anything in common with "label" when you use v6 hea= der ?=20 >=20 > If you want to search for some commonalities let's remove LDP-LSPs from th= is mix (as the is not relevant) and leave TE-LSP & SPRING + maybe also add B= IER as well as change the name to Generic-EP (Engineered Paths). >=20 > I see no value of goruping based on the fact that data plane uses mpls lab= els, but rather I would see reasonable to provide models based on the transp= ort path characteristics for the traffic it is to carry. =20 >=20 > Best, > r. >=20 >=20 >> On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin w= rote: >> Druv, >>=20 >> IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should h= ave totally independent models each being developed in respective WG. >>=20 >> Igor >=20 > =20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord --Apple-Mail-29E763CC-C36B-4A19-8FBA-59CDF33D8E5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Robert,

=46rom= one perspective I agree with you and Igor, however if you think about MPLS L= SPs, from a data plane perspective - and that is where OAM operates, there a= lmost no difference between a TE-LSP a LDP-LSP and a SPRING MPLS LSP come ve= ry close. 

If you the other hand think of LSPs= for other data planes the "nothing in common" is an almost true statement. = =46rom that point of view I think different models are where we will end up,= but I also think that we need "separation with moderation". 

 But nothing is so simple that we can capture it in one= very simple statement, we have hacking away on this for 30 years now, I'd a= dvice taking architecture and history into consideration, as well as viewing= the sky from a different perspective than from the bottom of a deep well.

Let me also say that I'm very supportive of all the g= ood work going on in this area. 

/Loa

S= ent from my iPad

On 07 Mar 2015, at 19:47, Robert Raszuk <<= a href=3D"mailto:robert@raszuk.net">robert@raszuk.net> wrote:

=

I would agree with Igor.

Other then name overlap those are completely different technologies and a= rtificially putting them under "LSP" umbrella just does not bring any value,= but only confuses things even more. 

Q: What SPRING-LSP has anything in common with "label" when you use v= 6 header ? 

If you want to sea= rch for some commonalities let's remove LDP-LSPs from this mix (as the is no= t relevant) and leave TE-LSP & SPRING + maybe also add BIER as well as c= hange the name to Generic-EP (Engineered Paths).

I see no value of goruping based on the fact that data plane u= ses mpls labels, but rather I would see reasonable to provide models based o= n the transport path characteristics for the traffic it is to carry.  <= /div>

Best,
r.


On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin <IBryskin@advaoptical.= com> wrote:
Druv,

IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should have= totally independent models each being developed in respective WG.

Igor

 
____________________= ___________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.o= rg
https://www.ietf.org/mailman/listinfo/rtg-yang-coord<= br>
= --Apple-Mail-29E763CC-C36B-4A19-8FBA-59CDF33D8E5A-- From nobody Sat Mar 7 07:19:28 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956D51A89A8; Sat, 7 Mar 2015 07:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkNN8fH4UN-K; Sat, 7 Mar 2015 07:19:24 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA561A87B1; Sat, 7 Mar 2015 07:19:23 -0800 (PST) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id t27FEh6o009807; Sat, 7 Mar 2015 10:19:23 -0500 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 1syekjkc56-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 07 Mar 2015 10:19:22 -0500 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 7 Mar 2015 10:19:21 -0500 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWEXCHCGSIHT01.ciena.com (10.4.140.106) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 7 Mar 2015 10:19:15 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Sat, 7 Mar 2015 10:19:09 -0500 From: "Shah, Himanshu" To: Loa Andersson , "teas@ietf.org" , "mpls@ietf.org" , "robert@raszuk.net" Date: Sat, 7 Mar 2015 10:19:13 -0500 Thread-Topic: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang Thread-Index: AdBY2TuuDqDhjHzdRh6IX6UeckPbrQAEJNjg Message-ID: <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: 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_40746B2300A8FC4AB04EE722A593182B85D178B3ONWVEXCHMB04cie_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-21384.000 X-TM-AS-Result: No--33.741700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-07_01:2015-03-06,2015-03-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503070164 Archived-At: Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 15:19:27 -0000 --_000_40746B2300A8FC4AB04EE722A593182B85D178B3ONWVEXCHMB04cie_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFJvYmVydCBhbmQgSWdvciwgcHV0dGluZyBldmVyeXRoaW5nIGluIHRoZSBz YW1lIGJ1Y2tldCBiZWNhdXNlIG9mIGNvbW1vbiBkYXRhIHBsYW5lICYgT0FNIGRvZXMgbm90IGp1 c3RpZnkuDQpXZSB3b3VsZG7igJl0IGNvbnNpZGVyIGRvaW5nIHNhbWUgZm9yIElQIGRhdGEgcGxh bmUuLg0KSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFyYXRlIHRoZXNlIG1vZGVscyBhbmQgYXMgbWVu dGlvbmVkIGVhcmxpZXIsIHRoZXJlIGlzIGFscmVhZHkgd29yayBnb2luZyBvbiBpbiByZXNwZWN0 aXZlIFdHcy4NCg0KVGhhbmtzLA0KaGltYW5zaHUNCg0KDQoNCkZyb206IG1wbHMgW21haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb2EgQW5kZXJzc29uDQpTZW50OiBT YXR1cmRheSwgTWFyY2ggMDcsIDIwMTUgODoxOCBBTQ0KVG86IHRlYXNAaWV0Zi5vcmcsIG1wbHNA aWV0Zi5vcmcsIHJvYmVydEByYXN6dWsubmV0DQpTdWJqZWN0OiBSZTogW21wbHNdIFtSdGcteWFu Zy1jb29yZF0gW1RlYXNdIEdlbmVyaWMgTFNQIFlhbmcNCg0KUm9iZXJ0LA0KDQpGcm9tIG9uZSBw ZXJzcGVjdGl2ZSBJIGFncmVlIHdpdGggeW91IGFuZCBJZ29yLCBob3dldmVyIGlmIHlvdSB0aGlu ayBhYm91dCBNUExTIExTUHMsIGZyb20gYSBkYXRhIHBsYW5lIHBlcnNwZWN0aXZlIC0gYW5kIHRo YXQgaXMgd2hlcmUgT0FNIG9wZXJhdGVzLCB0aGVyZSBhbG1vc3Qgbm8gZGlmZmVyZW5jZSBiZXR3 ZWVuIGEgVEUtTFNQIGEgTERQLUxTUCBhbmQgYSBTUFJJTkcgTVBMUyBMU1AgY29tZSB2ZXJ5IGNs b3NlLg0KDQpJZiB5b3UgdGhlIG90aGVyIGhhbmQgdGhpbmsgb2YgTFNQcyBmb3Igb3RoZXIgZGF0 YSBwbGFuZXMgdGhlICJub3RoaW5nIGluIGNvbW1vbiIgaXMgYW4gYWxtb3N0IHRydWUgc3RhdGVt ZW50LiBGcm9tIHRoYXQgcG9pbnQgb2YgdmlldyBJIHRoaW5rIGRpZmZlcmVudCBtb2RlbHMgYXJl IHdoZXJlIHdlIHdpbGwgZW5kIHVwLCBidXQgSSBhbHNvIHRoaW5rIHRoYXQgd2UgbmVlZCAic2Vw YXJhdGlvbiB3aXRoIG1vZGVyYXRpb24iLg0KDQogQnV0IG5vdGhpbmcgaXMgc28gc2ltcGxlIHRo YXQgd2UgY2FuIGNhcHR1cmUgaXQgaW4gb25lIHZlcnkgc2ltcGxlIHN0YXRlbWVudCwgd2UgaGF2 ZSBoYWNraW5nIGF3YXkgb24gdGhpcyBmb3IgMzAgeWVhcnMgbm93LCBJJ2QgYWR2aWNlIHRha2lu ZyBhcmNoaXRlY3R1cmUgYW5kIGhpc3RvcnkgaW50byBjb25zaWRlcmF0aW9uLCBhcyB3ZWxsIGFz IHZpZXdpbmcgdGhlIHNreSBmcm9tIGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIHRoYW4gZnJvbSB0 aGUgYm90dG9tIG9mIGEgZGVlcCB3ZWxsLg0KDQpMZXQgbWUgYWxzbyBzYXkgdGhhdCBJJ20gdmVy eSBzdXBwb3J0aXZlIG9mIGFsbCB0aGUgZ29vZCB3b3JrIGdvaW5nIG9uIGluIHRoaXMgYXJlYS4N Cg0KL0xvYQ0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQpPbiAwNyBNYXIgMjAxNSwgYXQgMTk6NDcs IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5l dD4+IHdyb3RlOg0KDQpJIHdvdWxkIGFncmVlIHdpdGggSWdvci4NCg0KT3RoZXIgdGhlbiBuYW1l IG92ZXJsYXAgdGhvc2UgYXJlIGNvbXBsZXRlbHkgZGlmZmVyZW50IHRlY2hub2xvZ2llcyBhbmQg YXJ0aWZpY2lhbGx5IHB1dHRpbmcgdGhlbSB1bmRlciAiTFNQIiB1bWJyZWxsYSBqdXN0IGRvZXMg bm90IGJyaW5nIGFueSB2YWx1ZSwgYnV0IG9ubHkgY29uZnVzZXMgdGhpbmdzIGV2ZW4gbW9yZS4N Cg0KUTogV2hhdCBTUFJJTkctTFNQIGhhcyBhbnl0aGluZyBpbiBjb21tb24gd2l0aCAibGFiZWwi IHdoZW4geW91IHVzZSB2NiBoZWFkZXIgPw0KDQpJZiB5b3Ugd2FudCB0byBzZWFyY2ggZm9yIHNv bWUgY29tbW9uYWxpdGllcyBsZXQncyByZW1vdmUgTERQLUxTUHMgZnJvbSB0aGlzIG1peCAoYXMg dGhlIGlzIG5vdCByZWxldmFudCkgYW5kIGxlYXZlIFRFLUxTUCAmIFNQUklORyArIG1heWJlIGFs c28gYWRkIEJJRVIgYXMgd2VsbCBhcyBjaGFuZ2UgdGhlIG5hbWUgdG8gR2VuZXJpYy1FUCAoRW5n aW5lZXJlZCBQYXRocykuDQoNCkkgc2VlIG5vIHZhbHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRo ZSBmYWN0IHRoYXQgZGF0YSBwbGFuZSB1c2VzIG1wbHMgbGFiZWxzLCBidXQgcmF0aGVyIEkgd291 bGQgc2VlIHJlYXNvbmFibGUgdG8gcHJvdmlkZSBtb2RlbHMgYmFzZWQgb24gdGhlIHRyYW5zcG9y dCBwYXRoIGNoYXJhY3RlcmlzdGljcyBmb3IgdGhlIHRyYWZmaWMgaXQgaXMgdG8gY2FycnkuDQoN CkJlc3QsDQpyLg0KDQoNCk9uIEZyaSwgTWFyIDYsIDIwMTUgYXQgMjoxMSBQTSwgSWdvciBCcnlz a2luIDxJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb208bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2Fs LmNvbT4+IHdyb3RlOg0KRHJ1diwNCg0KSU1ITyBURS1MU1AsIExEUC1MU1AgYW5kIFNQUklORy1M U1AgaGF2ZSBub3RoaW5nIGluIGNvbW1vbi4gVGhleSBzaG91bGQgaGF2ZSB0b3RhbGx5IGluZGVw ZW5kZW50IG1vZGVscyBlYWNoIGJlaW5nIGRldmVsb3BlZCBpbiByZXNwZWN0aXZlIFdHLg0KDQpJ Z29yDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8bWFp bHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0K --_000_40746B2300A8FC4AB04EE722A593182B85D178B3ONWVEXCHMB04cie_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FtYnJpYSIsInNl cmlmIjsNCgljb2xvcjojMDA0MEMwOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Oml0YWxpYzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1i bHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3Jt YWw+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbWJyaWEi LCJzZXJpZiI7Y29sb3I6IzAwNDBDMCc+SSBhZ3JlZSB3aXRoIFJvYmVydCBhbmQgSWdvciwgcHV0 dGluZyBldmVyeXRoaW5nIGluIHRoZSBzYW1lIGJ1Y2tldCBiZWNhdXNlIG9mIGNvbW1vbiBkYXRh IHBsYW5lICZhbXA7IE9BTSBkb2VzIG5vdCBqdXN0aWZ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDQwQzAnPldlIHdvdWxkbuKAmXQg Y29uc2lkZXIgZG9pbmcgc2FtZSBmb3IgSVAgZGF0YSBwbGFuZS4uPG86cD48L286cD48L3NwYW4+ PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7Y29sb3I6IzAwNDBDMCc+SSB0aGluayB3 ZSBuZWVkIHRvIHNlcGFyYXRlIHRoZXNlIG1vZGVscyBhbmQgYXMgbWVudGlvbmVkIGVhcmxpZXIs IHRoZXJlIGlzIGFscmVhZHkgd29yayBnb2luZyBvbiBpbiByZXNwZWN0aXZlIFdHcy48bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtjb2xvcjojMDA0MEMw Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlm Ijtjb2xvcjojMDA0MEMwJz5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbWJyaWEiLCJzZXJpZiI7Y29sb3I6IzAwNDBDMCc+aGltYW5zaHU8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtjb2xvcjojMDA0MEMwJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtjb2xvcjoj MDA0MEMwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48aT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIs InNlcmlmIjtjb2xvcjojMDA0MEMwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkxvYSBBbmRlcnNzb248YnI+PGI+U2VudDo8L2I+IFNh dHVyZGF5LCBNYXJjaCAwNywgMjAxNSA4OjE4IEFNPGJyPjxiPlRvOjwvYj4gdGVhc0BpZXRmLm9y ZywgbXBsc0BpZXRmLm9yZywgcm9iZXJ0QHJhc3p1ay5uZXQ8YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbbXBsc10gW1J0Zy15YW5nLWNvb3JkXSBbVGVhc10gR2VuZXJpYyBMU1AgWWFuZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Um9iZXJ0LDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPkZyb20gb25lIHBlcnNwZWN0aXZlIEkgYWdyZWUgd2l0aCB5 b3UgYW5kIElnb3IsIGhvd2V2ZXIgaWYgeW91IHRoaW5rIGFib3V0IE1QTFMgTFNQcywgZnJvbSBh IGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUgLSBhbmQgdGhhdCBpcyB3aGVyZSBPQU0gb3BlcmF0ZXMs IHRoZXJlIGFsbW9zdCBubyBkaWZmZXJlbmNlIGJldHdlZW4gYSBURS1MU1AgYSBMRFAtTFNQIGFu ZCBhIFNQUklORyBNUExTIExTUCBjb21lIHZlcnkgY2xvc2UuJm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SWYgeW91IHRoZSBvdGhlciBoYW5kIHRoaW5rIG9mIExT UHMgZm9yIG90aGVyIGRhdGEgcGxhbmVzIHRoZSAmcXVvdDtub3RoaW5nIGluIGNvbW1vbiZxdW90 OyBpcyBhbiBhbG1vc3QgdHJ1ZSBzdGF0ZW1lbnQuIEZyb20gdGhhdCBwb2ludCBvZiB2aWV3IEkg dGhpbmsgZGlmZmVyZW50IG1vZGVscyBhcmUgd2hlcmUgd2Ugd2lsbCBlbmQgdXAsIGJ1dCBJIGFs c28gdGhpbmsgdGhhdCB3ZSBuZWVkICZxdW90O3NlcGFyYXRpb24gd2l0aCBtb2RlcmF0aW9uJnF1 b3Q7LiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwO0J1 dCBub3RoaW5nIGlzIHNvIHNpbXBsZSB0aGF0IHdlIGNhbiBjYXB0dXJlIGl0IGluIG9uZSB2ZXJ5 IHNpbXBsZSBzdGF0ZW1lbnQsIHdlIGhhdmUgaGFja2luZyBhd2F5IG9uIHRoaXMgZm9yIDMwIHll YXJzIG5vdywgSSdkIGFkdmljZSB0YWtpbmcgYXJjaGl0ZWN0dXJlIGFuZCBoaXN0b3J5IGludG8g Y29uc2lkZXJhdGlvbiwgYXMgd2VsbCBhcyB2aWV3aW5nIHRoZSBza3kgZnJvbSBhIGRpZmZlcmVu dCBwZXJzcGVjdGl2ZSB0aGFuIGZyb20gdGhlIGJvdHRvbSBvZiBhIGRlZXAgd2VsbC48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5MZXQgbWUgYWxzbyBzYXkgdGhhdCBJJ20g dmVyeSBzdXBwb3J0aXZlIG9mIGFsbCB0aGUgZ29vZCB3b3JrIGdvaW5nIG9uIGluIHRoaXMgYXJl YS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4vTG9hPGJyPjxi cj5TZW50IGZyb20gbXkgaVBhZDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPk9uIDA3IE1hciAyMDE1LCBh dCAxOTo0NywgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsu bmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQn PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXci Jz5JIHdvdWxkIGFncmVlIHdpdGggSWdvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+T3RoZXIgdGhlbiBu YW1lIG92ZXJsYXAgdGhvc2UgYXJlIGNvbXBsZXRlbHkgZGlmZmVyZW50IHRlY2hub2xvZ2llcyBh bmQgYXJ0aWZpY2lhbGx5IHB1dHRpbmcgdGhlbSB1bmRlciAmcXVvdDtMU1AmcXVvdDsgdW1icmVs bGEganVzdCBkb2VzIG5vdCBicmluZyBhbnkgdmFsdWUsIGJ1dCBvbmx5IGNvbmZ1c2VzIHRoaW5n cyBldmVuIG1vcmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlE6IFdoYXQgU1BSSU5HLUxTUCBo YXMgYW55dGhpbmcgaW4gY29tbW9uIHdpdGggJnF1b3Q7bGFiZWwmcXVvdDsgd2hlbiB5b3UgdXNl IHY2IGhlYWRlciA/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPklmIHlvdSB3YW50IHRvIHNlYXJj aCBmb3Igc29tZSBjb21tb25hbGl0aWVzIGxldCdzIHJlbW92ZSBMRFAtTFNQcyBmcm9tIHRoaXMg bWl4IChhcyB0aGUgaXMgbm90IHJlbGV2YW50KSBhbmQgbGVhdmUgVEUtTFNQICZhbXA7IFNQUklO RyArIG1heWJlIGFsc28gYWRkIEJJRVIgYXMgd2VsbCBhcyBjaGFuZ2UgdGhlIG5hbWUgdG8gR2Vu ZXJpYy1FUCAoRW5naW5lZXJlZCBQYXRocykuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBO ZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkkgc2VlIG5vIHZh bHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgZGF0YSBwbGFuZSB1c2VzIG1w bHMgbGFiZWxzLCBidXQgcmF0aGVyIEkgd291bGQgc2VlIHJlYXNvbmFibGUgdG8gcHJvdmlkZSBt b2RlbHMgYmFzZWQgb24gdGhlIHRyYW5zcG9ydCBwYXRoIGNoYXJhY3RlcmlzdGljcyBmb3IgdGhl IHRyYWZmaWMgaXQgaXMgdG8gY2FycnkuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5CZXN0LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5PbiBGcmksIE1hciA2LCAyMDE1IGF0IDI6MTEgUE0sIElnb3IgQnJ5c2tpbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPklCcnlz a2luQGFkdmFvcHRpY2FsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD5EcnV2LDxicj48YnI+SU1ITyBURS1MU1AsIExEUC1MU1AgYW5kIFNQUklORy1M U1AgaGF2ZSBub3RoaW5nIGluIGNvbW1vbi4gVGhleSBzaG91bGQgaGF2ZSB0b3RhbGx5IGluZGVw ZW5kZW50IG1vZGVscyBlYWNoIGJlaW5nIGRldmVsb3BlZCBpbiByZXNwZWN0aXZlIFdHLjxicj48 c3BhbiBzdHlsZT0nY29sb3I6Izg4ODg4OCc+PGJyPjxzcGFuIGNsYXNzPWhvZW56Yj5JZ29yPC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+UnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0 bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8L2E+PGJy PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmct Y29vcmQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29v cmQ8L2E+PG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_40746B2300A8FC4AB04EE722A593182B85D178B3ONWVEXCHMB04cie_-- From nobody Sun Mar 8 01:28:13 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110341A6EF2; Sun, 8 Mar 2015 01:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96lQ3NEMLsFh; Sun, 8 Mar 2015 01:28:07 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26821A01E7; Sun, 8 Mar 2015 01:28:05 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.191.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3007418013C8; Sun, 8 Mar 2015 10:28:01 +0100 (CET) Message-ID: <54FC161A.3070006@pi.nu> Date: Sun, 08 Mar 2015 17:27:54 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Shah, Himanshu" , "teas@ietf.org" , "mpls@ietf.org" , "robert@raszuk.net" References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 09:28:10 -0000 Himanshu, et.al., I think there are two issues here and if sorting them out corrrectly we are very close. The first issue is similarities between different types of LSPs. Here I said that, at least for a MPLS PSN, there are similarities, e.g. the data plane is (nearly) the same. This was said in reaction to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common." I still don't think that Igor's statement is really correct. If he had said "IMHO there are not enough similarites between TE-LSP, LDP-LSP and SPRING-LSP to motivate a common model". I think that we be a much more accurate statement. And that is the other issue - Is it reasonable to model TE-LSP, LDP-LSP and SPRING-LSP in the same model? I don't not think it is, but that we need an overlap of people working with the different models. Hope this is clear enough. /Loa On 2015-03-07 23:19, Shah, Himanshu wrote: > /I agree with Robert and Igor, putting everything in the same bucket > because of common data plane & OAM does not justify./ > > /We wouldn’t consider doing same for IP data plane../ > > /I think we need to separate these models and as mentioned earlier, > there is already work going on in respective WGs./ > > // > > /Thanks,/ > > /himanshu/ > > // > > // > > // > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson > *Sent:* Saturday, March 07, 2015 8:18 AM > *To:* teas@ietf.org, mpls@ietf.org, robert@raszuk.net > *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang > > Robert, > > From one perspective I agree with you and Igor, however if you think > about MPLS LSPs, from a data plane perspective - and that is where OAM > operates, there almost no difference between a TE-LSP a LDP-LSP and a > SPRING MPLS LSP come very close. > > If you the other hand think of LSPs for other data planes the "nothing > in common" is an almost true statement. From that point of view I think > different models are where we will end up, but I also think that we need > "separation with moderation". > > But nothing is so simple that we can capture it in one very simple > statement, we have hacking away on this for 30 years now, I'd advice > taking architecture and history into consideration, as well as viewing > the sky from a different perspective than from the bottom of a deep well. > > Let me also say that I'm very supportive of all the good work going on > in this area. > > /Loa > > Sent from my iPad > > > On 07 Mar 2015, at 19:47, Robert Raszuk > wrote: > > I would agree with Igor. > > Other then name overlap those are completely different technologies > and artificially putting them under "LSP" umbrella just does not > bring any value, but only confuses things even more. > > Q: What SPRING-LSP has anything in common with "label" when you use > v6 header ? > > If you want to search for some commonalities let's remove LDP-LSPs > from this mix (as the is not relevant) and leave TE-LSP & SPRING + > maybe also add BIER as well as change the name to Generic-EP > (Engineered Paths). > > I see no value of goruping based on the fact that data plane uses > mpls labels, but rather I would see reasonable to provide models > based on the transport path characteristics for the traffic it is to > carry. > > Best, > > r. > > On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin > > wrote: > > Druv, > > IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They > should have totally independent models each being developed in > respective WG. > > Igor > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Mar 8 03:58:18 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5541D1A711A; Sun, 8 Mar 2015 03:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58WhAxboHPOb; Sun, 8 Mar 2015 03:58:13 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0FFD1A70FE; Sun, 8 Mar 2015 03:58:13 -0700 (PDT) Received: by iecrl12 with SMTP id rl12so13451889iec.5; Sun, 08 Mar 2015 03:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fIy5P2nYcnMo/uHx+m5B86cxPWmhXAMO2qC52mMmNQo=; b=dLw2jYJen1Pz/12C0ewZ1k/6EJQkv2VzCGEXxsqAg6sPhOwNiijR5s46JWRfrVbJHN XilAxcTsiy6pw3H+M0fU0Uh16Wzlpasr1ptJN/29hIkEk+U3glEZxHM4O7effvO1MYLd u68w/XFsl0U1b3cJxyX0EPXWzh5X+S6r1pqQ90O/fjUKLpjRwWpVCXkR0o6kYz94/aXS +wczOWuxFdq347owy8VI079N6ZBJoSzWQz69+Q6FX7X3yhafv3bwBd7ggzjiKI73Ib9u xECQ17uXDqy+dUYOVQWrQEtQR64buMKx8ai+OD0cjBmbJf5AdO7FZ9W9lMu2CaYMIznh UlTA== MIME-Version: 1.0 X-Received: by 10.107.39.132 with SMTP id n126mr40101648ion.75.1425812293132; Sun, 08 Mar 2015 03:58:13 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 03:58:12 -0700 (PDT) In-Reply-To: <54FC161A.3070006@pi.nu> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> Date: Sun, 8 Mar 2015 11:58:12 +0100 X-Google-Sender-Auth: gul3XhJbsqOQXHBote1MCxnv0lA Message-ID: From: Robert Raszuk To: Loa Andersson Content-Type: multipart/alternative; boundary=001a114085243faa8a0510c4cb2b Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" , "Shah, Himanshu" Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 10:58:16 -0000 --001a114085243faa8a0510c4cb2b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Loa, The way I read Igor statement and agreed with it in a sense of "nothing in common" was that it was referring to the control plane. The subject of this thread is "Generic LSP YANG" and to me Yang model describes control aspect of protocol or functionality not the choice of forwarding header in the data plane. So if you and others agree we should be all in sync and perhaps we could consider as proposed before Generic Engineered Path model branching at the lower layer between unicast and multicast. However if you still think that Yang is about data plane and OAM then perhaps we have a bigger issue here .... Cheers, R. On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson wrote: > Himanshu, et.al., > > I think there are two issues here and if sorting them out corrrectly > we are very close. > > The first issue is similarities between different types of LSPs. > > Here I said that, at least for a MPLS PSN, there are similarities, > e.g. the data plane is (nearly) the same. This was said in reaction > to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing > in common." I still don't think that Igor's statement is really correct. > If he had said "IMHO there are not enough similarites between TE-LSP, > LDP-LSP and SPRING-LSP to motivate a common model". I think that we be > a much more accurate statement. > > And that is the other issue - Is it reasonable to model TE-LSP, > LDP-LSP and SPRING-LSP in the same model? I don't not think it is, > but that we need an overlap of people working with the different models. > > Hope this is clear enough. > > /Loa > > > On 2015-03-07 23:19, Shah, Himanshu wrote: > >> /I agree with Robert and Igor, putting everything in the same bucket >> because of common data plane & OAM does not justify./ >> >> /We wouldn=E2=80=99t consider doing same for IP data plane../ >> >> /I think we need to separate these models and as mentioned earlier, >> there is already work going on in respective WGs./ >> >> // >> >> /Thanks,/ >> >> /himanshu/ >> >> // >> >> // >> >> // >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson >> *Sent:* Saturday, March 07, 2015 8:18 AM >> *To:* teas@ietf.org, mpls@ietf.org, robert@raszuk.net >> *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang >> >> Robert, >> >> From one perspective I agree with you and Igor, however if you think >> about MPLS LSPs, from a data plane perspective - and that is where OAM >> operates, there almost no difference between a TE-LSP a LDP-LSP and a >> SPRING MPLS LSP come very close. >> >> If you the other hand think of LSPs for other data planes the "nothing >> in common" is an almost true statement. From that point of view I think >> different models are where we will end up, but I also think that we need >> "separation with moderation". >> >> But nothing is so simple that we can capture it in one very simple >> statement, we have hacking away on this for 30 years now, I'd advice >> taking architecture and history into consideration, as well as viewing >> the sky from a different perspective than from the bottom of a deep well= . >> >> Let me also say that I'm very supportive of all the good work going on >> in this area. >> >> /Loa >> >> Sent from my iPad >> >> >> On 07 Mar 2015, at 19:47, Robert Raszuk > > wrote: >> >> I would agree with Igor. >> >> Other then name overlap those are completely different technologies >> and artificially putting them under "LSP" umbrella just does not >> bring any value, but only confuses things even more. >> >> Q: What SPRING-LSP has anything in common with "label" when you use >> v6 header ? >> >> If you want to search for some commonalities let's remove LDP-LSPs >> from this mix (as the is not relevant) and leave TE-LSP & SPRING + >> maybe also add BIER as well as change the name to Generic-EP >> (Engineered Paths). >> >> I see no value of goruping based on the fact that data plane uses >> mpls labels, but rather I would see reasonable to provide models >> based on the transport path characteristics for the traffic it is to >> carry. >> >> Best, >> >> r. >> >> On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin >> > wrote: >> >> Druv, >> >> IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They >> should have totally independent models each being developed in >> respective WG. >> >> Igor >> >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a114085243faa8a0510c4cb2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa,

The way I read Igor statement and agreed with it in a sense of "= ;nothing in common" was that it was referring to the control plane.=C2= =A0

The subject of this thread i= s "Generic LSP YANG" and to me Yang model describes control aspec= t of protocol or functionality not the choice of forwarding header in the d= ata plane.=C2=A0

So if you and o= thers agree we should be all in sync and perhaps we could consider as propo= sed before Generic Engineered Path model branching at the lower layer betwe= en unicast and multicast.=C2=A0

= However if you still think that Yang is about data plane and OAM then perha= ps we have a bigger issue here ....

Cheers,
R.




On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson &= lt;loa@pi.nu> = wrote:
Himanshu, et.al.,

I think there are two issues here and if sorting them out corrrectly
we are very close.

The first issue is similarities between different types of LSPs.

Here I said that, at least for a MPLS PSN, there are similarities,
e.g. the data plane is (nearly) the same. This was said in reaction
to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have noth= ing
in common." I still don't think that Igor's statement is reall= y correct.
If he had said "IMHO there are not enough similarites between TE-LSP,<= br> LDP-LSP and SPRING-LSP to motivate a common model". I think that we be=
a much more accurate statement.

And that is the other issue - Is it reasonable to model TE-LSP,
LDP-LSP and SPRING-LSP in the same model? I don't not think it is,
but that we need an overlap of people working with the different models.
Hope this is clear enough.

/Loa


On 2015-03-07 23:19, Shah, Himanshu wrote:
/I agree with Robert and Igor, putting everything in the same bucket
because of common data plane & OAM does not justify./

/We wouldn=E2=80=99t consider doing same for IP data plane../

/I think we need to separate these models and as mentioned earlier,
there is already work going on in respective WGs./

//

/Thanks,/

/himanshu/

//

//

//

*From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson
*Sent:* Saturday, March 07, 2015 8:18 AM
*To:* teas@ietf.org,= mpls@ietf.org, robert@raszuk.net *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang

Robert,

=C2=A0From one perspective I agree with you and Igor, however if you think<= br> about MPLS LSPs, from a data plane perspective - and that is where OAM
operates, there almost no difference between a TE-LSP a LDP-LSP and a
SPRING MPLS LSP come very close.

If you the other hand think of LSPs for other data planes the "nothing=
in common" is an almost true statement. From that point of view I thin= k
different models are where we will end up, but I also think that we need "separation with moderation".

=C2=A0 But nothing is so simple that we can capture it in one very simple statement, we have hacking away on this for 30 years now, I'd advice taking architecture and history into consideration, as well as viewing
the sky from a different perspective than from the bottom of a deep well.
Let me also say that I'm very supportive of all the good work going on<= br> in this area.

/Loa

Sent from my iPad


On 07 Mar 2015, at 19:47, Robert Raszuk <robert@raszuk.net
 <mailto:robert@ra= szuk.net>> wrote:

=C2=A0 =C2=A0 I would agree with Igor.

=C2=A0 =C2=A0 Other then name overlap those are completely different techno= logies
=C2=A0 =C2=A0 and artificially putting them under "LSP" umbrella = just does not
=C2=A0 =C2=A0 bring any value, but only confuses things even more.

=C2=A0 =C2=A0 Q: What SPRING-LSP has anything in common with "label&qu= ot; when you use
=C2=A0 =C2=A0 v6 header ?

=C2=A0 =C2=A0 If you want to search for some commonalities let's remove= LDP-LSPs
=C2=A0 =C2=A0 from this mix (as the is not relevant) and leave TE-LSP &= SPRING +
=C2=A0 =C2=A0 maybe also add BIER as well as change the name to Generic-EP<= br> =C2=A0 =C2=A0 (Engineered Paths).

=C2=A0 =C2=A0 I see no value of goruping based on the fact that data plane = uses
=C2=A0 =C2=A0 mpls labels, but rather I would see reasonable to provide mod= els
=C2=A0 =C2=A0 based on the transport path characteristics for the traffic i= t is to
=C2=A0 =C2=A0 carry.

=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 r.

=C2=A0 =C2=A0 On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin
 =C2=A0 =C2=A0 <IBryskin@advaoptical.com <mailto:IBryskin@advaoptical.com>>= wrote:

=C2=A0 =C2=A0 Druv,

=C2=A0 =C2=A0 IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. T= hey
=C2=A0 =C2=A0 should have totally independent models each being developed i= n
=C2=A0 =C2=A0 respective WG.

=C2=A0 =C2=A0 Igor

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Rtg-yang-coord mailing list
 =C2=A0 =C2=A0 = Rtg-yang-coord@ietf.org <mailto:Rtg-yang-coord@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtg-yang= -coord



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--001a114085243faa8a0510c4cb2b-- From nobody Sun Mar 8 06:29:24 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BAE1A8704; Sun, 8 Mar 2015 06:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu2nfPFOGbUu; Sun, 8 Mar 2015 06:29:17 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576D71A8703; Sun, 8 Mar 2015 06:29:16 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t28DTD90001015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Mar 2015 09:29:13 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 8 Mar 2015 09:29:13 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1076.3; Sun, 8 Mar 2015 09:29:12 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Sun, 8 Mar 2015 09:29:12 -0400 From: Igor Bryskin To: Robert Raszuk , Loa Andersson Thread-Topic: [mpls] [Teas] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWY7NuNEcsrE2iEGI3ykMvO5zf50SjSJF Date: Sun, 8 Mar 2015 13:29:11 +0000 Message-ID: References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-08_02:2015-03-06,2015-03-08,1970-01-01 signatures=0 Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 13:29:20 -0000 Hi guys, Robert, your interpretation is spot on. Considering the context (the statem= ent was made in response to Druv's email) I don't see how it could be read = differently. LSP model defines how we configure, manipulate an LSP, interpret its parame= ters, stuff like that. This means the management and control planes. It is important to keep in perspective why do we do this modelling in IETF.= In his presentation on MPLS/SDN 2014 conference Kireeti said that in MPLS = networks we have achieved full interoperability in data plane and sufficien= t one in control plane. The problem and perpetual pain for operators is tha= t each vendor exposes very different interfaces and tools to configure and = manage the services. Contemporary management protocols like NETCONF in conj= unction with standardized models will solve this. However, we do not attempt to (re-)model the data plane, right? Cheers Igor ________________________________________ From: mpls [mpls-bounces@ietf.org] on behalf of Robert Raszuk [robert@raszu= k.net] Sent: Sunday, March 8, 2015 6:58 AM To: Loa Andersson Cc: mpls@ietf.org; teas@ietf.org Subject: Re: [mpls] [Teas] [Rtg-yang-coord] Generic LSP Yang Hi Loa, The way I read Igor statement and agreed with it in a sense of "nothing in = common" was that it was referring to the control plane. The subject of this thread is "Generic LSP YANG" and to me Yang model descr= ibes control aspect of protocol or functionality not the choice of forwardi= ng header in the data plane. So if you and others agree we should be all in sync and perhaps we could co= nsider as proposed before Generic Engineered Path model branching at the lo= wer layer between unicast and multicast. However if you still think that Yang is about data plane and OAM then perha= ps we have a bigger issue here .... Cheers, R. On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson = > wrote: Himanshu, et.al., I think there are two issues here and if sorting them out corrrectly we are very close. The first issue is similarities between different types of LSPs. Here I said that, at least for a MPLS PSN, there are similarities, e.g. the data plane is (nearly) the same. This was said in reaction to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common." I still don't think that Igor's statement is really correct. If he had said "IMHO there are not enough similarites between TE-LSP, LDP-LSP and SPRING-LSP to motivate a common model". I think that we be a much more accurate statement. And that is the other issue - Is it reasonable to model TE-LSP, LDP-LSP and SPRING-LSP in the same model? I don't not think it is, but that we need an overlap of people working with the different models. Hope this is clear enough. /Loa On 2015-03-07 23:19, Shah, Himanshu wrote: /I agree with Robert and Igor, putting everything in the same bucket because of common data plane & OAM does not justify./ /We wouldn=92t consider doing same for IP data plane../ /I think we need to separate these models and as mentioned earlier, there is already work going on in respective WGs./ // /Thanks,/ /himanshu/ // // // *From:*mpls [mailto:mpls-bounces@ietf.org] *O= n Behalf Of *Loa Andersson *Sent:* Saturday, March 07, 2015 8:18 AM *To:* teas@ietf.org, mpls@ietf.org, robert@raszuk.net *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang Robert, From one perspective I agree with you and Igor, however if you think about MPLS LSPs, from a data plane perspective - and that is where OAM operates, there almost no difference between a TE-LSP a LDP-LSP and a SPRING MPLS LSP come very close. If you the other hand think of LSPs for other data planes the "nothing in common" is an almost true statement. From that point of view I think different models are where we will end up, but I also think that we need "separation with moderation". But nothing is so simple that we can capture it in one very simple statement, we have hacking away on this for 30 years now, I'd advice taking architecture and history into consideration, as well as viewing the sky from a different perspective than from the bottom of a deep well. Let me also say that I'm very supportive of all the good work going on in this area. /Loa Sent from my iPad On 07 Mar 2015, at 19:47, Robert Raszuk >> wrote: I would agree with Igor. Other then name overlap those are completely different technologies and artificially putting them under "LSP" umbrella just does not bring any value, but only confuses things even more. Q: What SPRING-LSP has anything in common with "label" when you use v6 header ? If you want to search for some commonalities let's remove LDP-LSPs from this mix (as the is not relevant) and leave TE-LSP & SPRING + maybe also add BIER as well as change the name to Generic-EP (Engineered Paths). I see no value of goruping based on the fact that data plane uses mpls labels, but rather I would see reasonable to provide models based on the transport path characteristics for the traffic it is to carry. Best, r. On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin >> wrote: Druv, IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should have totally independent models each being developed in respective WG. Igor _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Mar 8 06:57:16 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0021A8711 for ; Sun, 8 Mar 2015 06:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUYQXabZ82Yv for ; Sun, 8 Mar 2015 06:57:14 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id BFCCE1A870F for ; Sun, 8 Mar 2015 06:57:14 -0700 (PDT) Received: (qmail 30306 invoked by uid 0); 8 Mar 2015 13:57:11 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 8 Mar 2015 13:57:11 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 11wu1q00L2SSUrH011wxji; Sun, 08 Mar 2015 07:57:09 -0600 X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=hUXq7yzdp1YA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=wOF4LelmCnIrrtnXsgAA:9 a=pILNOxqGKmIA:10 a=8x_bXrrxqLEA:10 a=Hcxmd5gMIKYA:10 a=2E6WERCcqXkA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=jqdI4vKTOSP32byF9dp0C57UnHcnvw5EaPgiqy5H5kQ=; b=mmslXezMlS+gwwOUh2wV0BazKIxDRvT67xeS2a613BtU9ZHQ5SINVl7SHnidjjkSdY4eoBQpsJZ/W1fQFghq+RB0YslssPdt3sgUOr4pSxLHR3E21KSu59PddnAjIvku; Received: from box313.bluehost.com ([69.89.31.113]:60597 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YUbhQ-0003xZ-DD; Sun, 08 Mar 2015 07:56:56 -0600 Message-ID: <54FC5525.5060501@labn.net> Date: Sun, 08 Mar 2015 09:56:53 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Igor Bryskin , Robert Raszuk , Loa Andersson References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu>, In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 13:57:15 -0000 On 03/08/2015 09:29 AM, Igor Bryskin wrote: > However, we do not attempt to (re-)model the data plane, right? Really? I don't see a TP LSP that is managed without control plane as out of scope... Lou From nobody Sun Mar 8 07:01:39 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16A1A8711; Sun, 8 Mar 2015 07:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPJpAqPTmviC; Sun, 8 Mar 2015 07:01:37 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BC51A8710; Sun, 8 Mar 2015 07:01:36 -0700 (PDT) Received: from [192.168.1.12] (unknown [49.149.191.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 26205180145E; Sun, 8 Mar 2015 15:01:32 +0100 (CET) Message-ID: <54FC5637.6020002@pi.nu> Date: Sun, 08 Mar 2015 22:01:27 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Lou Berger , Igor Bryskin , Robert Raszuk References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu>, <54FC5525.5060501@labn.net> In-Reply-To: <54FC5525.5060501@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 14:01:38 -0000 Lou, On 2015-03-08 21:56, Lou Berger wrote: > On 03/08/2015 09:29 AM, Igor Bryskin wrote: >> However, we do not attempt to (re-)model the data plane, right? > > Really? I don't see a TP LSP that is managed without control plane as > out of scope... No it is not out of scope - at least not until we decide so - but the crue here that the mpls-tp data plane and mpls data plane are identical, so the mpls data plane is also in scope. So there is sure something to discuss around the the different types of LSPs and the differences and commonalities. /Loa > > Lou > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Mar 8 08:15:18 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584F21A1B4A; Sun, 8 Mar 2015 08:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA3x6TbaUG0V; Sun, 8 Mar 2015 08:15:10 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFCF1A014B; Sun, 8 Mar 2015 08:15:10 -0700 (PDT) Received: by iecat20 with SMTP id at20so43533541iec.6; Sun, 08 Mar 2015 08:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=snGaSrQB0xXd+6JVl4yNWJcP1kn+sdSCPYqx0r9tC9o=; b=beTUb0xdU0xcXQ1XfaFE3kd1NVzOOywt/CjEuRJKrowsHquQ7mLIIG9ZvRXXHXNdN9 RaWmRQloN5e2xgs0sSGP91CPfpwKRpVSifGKBXEbqqp3RmfLnqjuPEB+dEaYd92w6J78 daYxwhgBMyu7YoclL9UGMGpFtchKxDacV7e8Xy7Gk/uqLMk6cKxKyYBXfVHIjoCpvdmY 3rlKeKQ9H0SkZdI2uujHo5WbkyaiOYpjk6lC3/2lnyDqUhURZ9ZhbBdadAfucU+uCJTa r4F+JGe5aszWI8fhMss2DfE4fY2GpZI4KeWhVyna0bYSWvaB5uImgZUGfa5AoE6Bk45i RKxg== MIME-Version: 1.0 X-Received: by 10.107.138.232 with SMTP id c101mr13956603ioj.47.1425827709565; Sun, 08 Mar 2015 08:15:09 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 08:15:09 -0700 (PDT) Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 08:15:09 -0700 (PDT) In-Reply-To: <54FC5525.5060501@labn.net> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <54FC5525.5060501@labn.net> Date: Sun, 8 Mar 2015 16:15:09 +0100 X-Google-Sender-Auth: g5FRNR8o4LLaI9s7QDrbFp_2HKo Message-ID: From: Robert Raszuk To: Lou Berger Content-Type: multipart/alternative; boundary=001a113ed3f823c1880510c862b3 Archived-At: Cc: "mpls@ietf.org" , Igor Bryskin , teas@ietf.org, Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 15:15:11 -0000 --001a113ed3f823c1880510c862b3 Content-Type: text/plain; charset=UTF-8 Hi Lou, TP-LSP have a real control plane. It is a centralized one. You don't need distributed control plane to call it as such. However tht is still far from data plane which I hope this discussion has really nothing in common with. Best, R. On Mar 8, 2015 2:57 PM, "Lou Berger" wrote: > On 03/08/2015 09:29 AM, Igor Bryskin wrote: > > However, we do not attempt to (re-)model the data plane, right? > > Really? I don't see a TP LSP that is managed without control plane as > out of scope... > > Lou > --001a113ed3f823c1880510c862b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Lou,

TP-LSP have a real control plane. It is a centralized one.

You don't need distributed control plane to call it as s= uch.

However tht is still far from data plane which I hope this d= iscussion has really nothing in common with.

Best,
R.

On Mar 8, 2015 2:57 PM, "Lou Berger" &= lt;lberger@labn.net> wrote:
On 03/08/2015 09:29 AM, = Igor Bryskin wrote:
>=C2=A0 However, we do not attempt to (re-)model the data plane, right?<= br>
Really?=C2=A0 I don't see a TP LSP that is managed without control plan= e as
out of scope...

Lou
--001a113ed3f823c1880510c862b3-- From nobody Sun Mar 8 08:24:16 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC941A1A04; Sun, 8 Mar 2015 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvcOUSuGUsQy; Sun, 8 Mar 2015 08:24:11 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0371A014B; Sun, 8 Mar 2015 08:24:11 -0700 (PDT) Received: from [192.168.1.12] (unknown [49.149.191.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2332F180145E; Sun, 8 Mar 2015 16:24:07 +0100 (CET) Message-ID: <54FC6992.6090901@pi.nu> Date: Sun, 08 Mar 2015 23:24:02 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Robert Raszuk , Lou Berger References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <54FC5525.5060501@labn.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , Igor Bryskin , teas@ietf.org Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 15:24:13 -0000 Robert, The jury is not out on this - if you want to split hair do that - but RFC 5654 says: 22 MPLS-TP MUST support the capability for network operation via the management plane (without the use of any control-plane protocols). This includes the configuration and control of OAM and recovery functions. The odd thing about this is that I'm not particulary fond of running my networks without a control plane :) ! But I must live with what is out there. /Loa On 2015-03-08 23:15, Robert Raszuk wrote: > Hi Lou, > > TP-LSP have a real control plane. It is a centralized one. > > You don't need distributed control plane to call it as such. > > However tht is still far from data plane which I hope this discussion > has really nothing in common with. > > Best, > R. > > On Mar 8, 2015 2:57 PM, "Lou Berger" > wrote: > > On 03/08/2015 09:29 AM, Igor Bryskin wrote: > > However, we do not attempt to (re-)model the data plane, right? > > Really? I don't see a TP LSP that is managed without control plane as > out of scope... > > Lou > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Mar 8 08:29:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5A41A19F2; Sun, 8 Mar 2015 08:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWRygI5WBpZD; Sun, 8 Mar 2015 08:29:16 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5442A1A03A8; Sun, 8 Mar 2015 08:29:16 -0700 (PDT) Received: by iery20 with SMTP id y20so3776280ier.11; Sun, 08 Mar 2015 08:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Kf/V4L/Q6yNea1/vhqVuUEwvhJccfFvnphLbbFBfNlc=; b=gwU0LChHLBPx69iVFNd87NTEhats1p0EfCvCvWNH2DHsoGEUdj9W+Ql2X7nUW8GeXA QHH6+2S75PEYzjuoDs+fv/9TXdYcQ+oT6PaC9gmFFwsRF6yedce0mFfEPeKnuB+KI69y A605u2oHOlNwwdeyFVYcZs0paEYKDW3Kzgqjy6r36rSDtBiUIXIXEC6j/jdjOTy9f3wI aab5HJdV2J5j4KqnAWZaE5GrzonvJ2b8wEEWhpSL4j0aXq0vFaN7zrs4rCX6o/U2AX7D 22DSAAFXpUvDmeGF9QY/hDSq0GYfq8C9eBrBGTM30azb3vgz8t3aVFH8l2DA1V0besW6 ORqw== MIME-Version: 1.0 X-Received: by 10.42.123.135 with SMTP id s7mr21292029icr.55.1425828555770; Sun, 08 Mar 2015 08:29:15 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 08:29:15 -0700 (PDT) Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 08:29:15 -0700 (PDT) In-Reply-To: <54FC6992.6090901@pi.nu> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <54FC5525.5060501@labn.net> <54FC6992.6090901@pi.nu> Date: Sun, 8 Mar 2015 16:29:15 +0100 X-Google-Sender-Auth: y2LBbJfVmunxa-faAjNQzwJSFpM Message-ID: From: Robert Raszuk To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf3010e7a993d2d40510c8942d Archived-At: Cc: "mpls@ietf.org" , Lou Berger , Igor Bryskin , teas@ietf.org Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 15:29:18 -0000 --20cf3010e7a993d2d40510c8942d Content-Type: text/plain; charset=UTF-8 Loa, The quote you brought says "control-plane protocols" not "control-plane". That is here a big difference. Rgs, R. On Mar 8, 2015 4:24 PM, "Loa Andersson" wrote: > Robert, > > The jury is not out on this - if you want to split hair do that - > but RFC 5654 says: > > 22 MPLS-TP MUST support the capability for network operation via the > management plane (without the use of any control-plane > protocols). This includes the configuration and control of OAM > and recovery functions. > > The odd thing about this is that I'm not particulary fond of running my > networks without a control plane :) ! But I must live with what is out > there. > > /Loa > > On 2015-03-08 23:15, Robert Raszuk wrote: > >> Hi Lou, >> >> TP-LSP have a real control plane. It is a centralized one. >> >> You don't need distributed control plane to call it as such. >> >> However tht is still far from data plane which I hope this discussion >> has really nothing in common with. >> >> Best, >> R. >> >> On Mar 8, 2015 2:57 PM, "Lou Berger" > > wrote: >> >> On 03/08/2015 09:29 AM, Igor Bryskin wrote: >> > However, we do not attempt to (re-)model the data plane, right? >> >> Really? I don't see a TP LSP that is managed without control plane as >> out of scope... >> >> Lou >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --20cf3010e7a993d2d40510c8942d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Loa,

The quote you brought says "control-plane protocols&quo= t; not "control-plane".

That is here a big difference.

Rgs,
R.

On Mar 8, 2015 4:24 PM, "Loa Andersson"= ; <loa@pi.nu> wrote:
Robert,

The jury is not out on this - if you want to split hair do that -
but RFC 5654 says:

=C2=A0 =C2=A022=C2=A0 MPLS-TP MUST support the capability for network opera= tion via the
=C2=A0 =C2=A0 =C2=A0 =C2=A0management plane (without the use of any control= -plane
=C2=A0 =C2=A0 =C2=A0 =C2=A0protocols).=C2=A0 This includes the configuratio= n and control of OAM
=C2=A0 =C2=A0 =C2=A0 =C2=A0and recovery functions.

The odd thing about this is that I'm not particulary fond of running my=
networks without a control plane :) ! But I must live with what is out
there.

/Loa

On 2015-03-08 23:15, Robert Raszuk wrote:
Hi Lou,

TP-LSP have a real control plane. It is a centralized one.

You don't need distributed control plane to call it as such.

However tht is still far from data plane which I hope this discussion
has really nothing in common with.

Best,
R.

On Mar 8, 2015 2:57 PM, "Lou Berger" <lberger@labn.net
<mailto:lberger@la= bn.net>> wrote:

=C2=A0 =C2=A0 On 03/08/2015 09:29 AM, Igor Bryskin wrote:
=C2=A0 =C2=A0 =C2=A0>=C2=A0 However, we do not attempt to (re-)model the= data plane, right?

=C2=A0 =C2=A0 Really?=C2=A0 I don't see a TP LSP that is managed withou= t control plane as
=C2=A0 =C2=A0 out of scope...

=C2=A0 =C2=A0 Lou



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64
--20cf3010e7a993d2d40510c8942d-- From nobody Sun Mar 8 08:31:58 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF951A19F8; Sun, 8 Mar 2015 08:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbCSxRPJ4g9E; Sun, 8 Mar 2015 08:31:54 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C95A1A19F2; Sun, 8 Mar 2015 08:31:54 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t28FVqlP001829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Mar 2015 11:31:53 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 8 Mar 2015 11:31:52 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1076.3; Sun, 8 Mar 2015 11:31:51 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Sun, 8 Mar 2015 11:31:51 -0400 From: Igor Bryskin To: Lou Berger , Robert Raszuk , "Loa Andersson" Thread-Topic: [mpls] [Teas] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWY7NuNEcsrE2iEGI3ykMvO5zf50SjSJFgABSRYD//9aAHA== Date: Sun, 8 Mar 2015 15:31:50 +0000 Message-ID: References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu>, , <54FC5525.5060501@labn.net> In-Reply-To: <54FC5525.5060501@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-08_03:2015-03-06,2015-03-08,1970-01-01 signatures=0 Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 15:31:56 -0000 Neither do I. But what this has to do with the data plane? ________________________________________ From: Lou Berger [lberger@labn.net] Sent: Sunday, March 8, 2015 9:56 AM To: Igor Bryskin; Robert Raszuk; Loa Andersson Cc: mpls@ietf.org; teas@ietf.org Subject: Re: [mpls] [Teas] [Rtg-yang-coord] Generic LSP Yang On 03/08/2015 09:29 AM, Igor Bryskin wrote: > However, we do not attempt to (re-)model the data plane, right? Really? I don't see a TP LSP that is managed without control plane as out of scope... Lou From nobody Sun Mar 8 08:40:03 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C435E1A7030; Sun, 8 Mar 2015 08:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq-TPhIfmCbT; Sun, 8 Mar 2015 08:40:00 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7F61A19F2; Sun, 8 Mar 2015 08:39:59 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t28FdwZ1006470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Mar 2015 11:39:59 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 8 Mar 2015 11:39:58 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1076.3; Sun, 8 Mar 2015 11:39:58 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Sun, 8 Mar 2015 11:39:58 -0400 From: Igor Bryskin To: Robert Raszuk , Lou Berger Thread-Topic: [mpls] [Teas] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWbKtay0a975tUUmCjBofCfDoEZ0SuKDw Date: Sun, 8 Mar 2015 15:39:57 +0000 Message-ID: References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <54FC5525.5060501@labn.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-08_03:2015-03-06,2015-03-08,1970-01-01 signatures=0 Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" , Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 15:40:00 -0000 Exactly ________________________________________ From: rraszuk@gmail.com [rraszuk@gmail.com] on behalf of Robert Raszuk [rob= ert@raszuk.net] Sent: Sunday, March 8, 2015 11:15 AM To: Lou Berger Cc: teas@ietf.org; Loa Andersson; Igor Bryskin; mpls@ietf.org Subject: Re: [mpls] [Teas] [Rtg-yang-coord] Generic LSP Yang Hi Lou, TP-LSP have a real control plane. It is a centralized one. You don't need distributed control plane to call it as such. However tht is still far from data plane which I hope this discussion has r= eally nothing in common with. Best, R. On Mar 8, 2015 2:57 PM, "Lou Berger" > wrote: On 03/08/2015 09:29 AM, Igor Bryskin wrote: > However, we do not attempt to (re-)model the data plane, right? Really? I don't see a TP LSP that is managed without control plane as out of scope... Lou From nobody Sun Mar 8 08:46:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3611A8741; Sun, 8 Mar 2015 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOuYgnntLbcA; Sun, 8 Mar 2015 08:46:40 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FFA1A872F; Sun, 8 Mar 2015 08:46:39 -0700 (PDT) Received: from [192.168.1.12] (unknown [49.149.191.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8E65D180145E; Sun, 8 Mar 2015 16:46:36 +0100 (CET) Message-ID: <54FC6ED6.8060807@pi.nu> Date: Sun, 08 Mar 2015 23:46:30 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Robert Raszuk References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <54FC5525.5060501@labn.net> <54FC6992.6090901@pi.nu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "mpls@ietf.org" , Lou Berger , Igor Bryskin , teas@ietf.org Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 15:46:41 -0000 Robert, I will rest the case now, just two more points - if you have protocols that constitute a control plane, why aren't they control plane protocols - Same RFC as before "Note that it MUST be possible to operate an MPLS-TP network without using a control plane." /Loa On 2015-03-08 23:29, Robert Raszuk wrote: > Loa, > > The quote you brought says "control-plane protocols" not "control-plane". > > That is here a big difference. > > Rgs, > R. > > On Mar 8, 2015 4:24 PM, "Loa Andersson" > > wrote: > > Robert, > > The jury is not out on this - if you want to split hair do that - > but RFC 5654 says: > > 22 MPLS-TP MUST support the capability for network operation > via the > management plane (without the use of any control-plane > protocols). This includes the configuration and control of OAM > and recovery functions. > > The odd thing about this is that I'm not particulary fond of running my > networks without a control plane :) ! But I must live with what is out > there. > > /Loa > > On 2015-03-08 23:15, Robert Raszuk wrote: > > Hi Lou, > > TP-LSP have a real control plane. It is a centralized one. > > You don't need distributed control plane to call it as such. > > However tht is still far from data plane which I hope this > discussion > has really nothing in common with. > > Best, > R. > > On Mar 8, 2015 2:57 PM, "Lou Berger" > >> wrote: > > On 03/08/2015 09:29 AM, Igor Bryskin wrote: > > However, we do not attempt to (re-)model the data > plane, right? > > Really? I don't see a TP LSP that is managed without > control plane as > out of scope... > > Lou > > > > _________________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/__listinfo/teas > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Mar 8 10:06:33 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285AC1A0053 for ; Sun, 8 Mar 2015 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2p53D8RfNk3 for ; Sun, 8 Mar 2015 10:06:31 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 497801A0055 for ; Sun, 8 Mar 2015 10:06:30 -0700 (PDT) Received: (qmail 7186 invoked by uid 0); 8 Mar 2015 17:06:29 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 8 Mar 2015 17:06:29 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 1C691q00D2SSUrH01C6CCC; Sun, 08 Mar 2015 18:06:27 -0600 X-Authority-Analysis: v=2.1 cv=CaGbutbl c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=99K8i5EPIjMA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=TdaWkMAuKw8A:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=YusZQoAvJVFmraGbYjQA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=V3eQEqgMRXsFXUhCbkHA85tvfT3r2dEJA4+Ic2UgUUs=; b=ZL6idCjovVHU4Fv2THLfkglXnJqmMVJwjsQKtNKaYRqA5Cs34Vh9U2t/GHxH3XxXAcBGnSxaWtQcotW5N+7wlF3o/ylGlZA1A8iDflOn4n8uM4tcAA3BcnfsgHNOxX1M; Received: from [172.56.2.45] (port=19387 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YUeeX-0002jQ-Fr; Sun, 08 Mar 2015 11:06:10 -0600 From: Lou Berger To: Loa Andersson , Igor Bryskin , Robert Raszuk Date: Sun, 08 Mar 2015 13:06:05 -0400 Message-ID: <14bfa59c490.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <54FC5637.6020002@pi.nu> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu>, <54FC5525.5060501@labn.net> <54FC5637.6020002@pi.nu> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.1.13 (build: 21020013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.2.45 authed with lberger@labn.net} Archived-At: Cc: mpls@ietf.org, teas@ietf.org Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 17:06:32 -0000 Sure. The details will show the overlap. .. Lou On March 8, 2015 10:02:06 AM Loa Andersson wrote: > Lou, > > On 2015-03-08 21:56, Lou Berger wrote: > > On 03/08/2015 09:29 AM, Igor Bryskin wrote: > >> However, we do not attempt to (re-)model the data plane, right? > > > > Really? I don't see a TP LSP that is managed without control plane as > > out of scope... > > No it is not out of scope - at least not until we decide so - but the > crue here that the mpls-tp data plane and mpls data plane are identical, > so the mpls data plane is also in scope. > > So there is sure something to discuss around the the different types of > LSPs and the differences and commonalities. > > /Loa > > > > Lou > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Sun Mar 8 10:10:40 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0885D1A0053 for ; Sun, 8 Mar 2015 10:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILeYPgFnO78X for ; Sun, 8 Mar 2015 10:10:37 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 3BF771A0039 for ; Sun, 8 Mar 2015 10:10:37 -0700 (PDT) Received: (qmail 30725 invoked by uid 0); 8 Mar 2015 17:10:33 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 8 Mar 2015 17:10:33 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 1CAU1q00n2SSUrH01CAXrd; Sun, 08 Mar 2015 18:10:31 -0600 X-Authority-Analysis: v=2.1 cv=CaGbutbl c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=99K8i5EPIjMA:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=TdaWkMAuKw8A:10 a=emO1SXQWCLwA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=2clOPd4PAAAA:8 a=jGaSLAFHMJ4qkHWYE3wA:9 a=CjuIK1q_8ugA:10 a=BzvcjTyMhFVOHIF4nR8A:9 a=-tw7UvuVcQ6JJrxu:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=9w5ZjpnQpqSbIMOS7PocpG4CQiGPaPWNayOTSXfjr+Q=; b=TnwyrV/lJKUd+XoVrH6lWj3RLpP936c0TxGhmXOumcmMIAo1OPcYC8xlrDxrtt1zL4MCHF5bg17pB529Pziaj5RLlXcIbSf4WNSCyKVdZKrgl4qr/8zOgIyJcZLkiFYz; Received: from [172.56.2.45] (port=21383 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YUeig-0003JH-Ek; Sun, 08 Mar 2015 11:10:30 -0600 From: Lou Berger To: Robert Raszuk Date: Sun, 08 Mar 2015 13:10:22 -0400 Message-ID: <14bfa5db078.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <54FC5525.5060501@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.1.13 (build: 21020013) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------14bfa5dbf5316bd27e94366b520" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.2.45 authed with lberger@labn.net} Archived-At: Cc: mpls@ietf.org, Igor Bryskin , teas@ietf.org, Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 17:10:38 -0000 This is a multi-part message in MIME format. ------------14bfa5dbf5316bd27e94366b520 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit On March 8, 2015 11:15:32 AM Robert Raszuk wrote: > Hi Lou, > > TP-LSP have a real control plane. It is a centralized one. > Agreed. > You don't need distributed control plane to call it as such. > No disagreement, the function is the same. But I don't think your definition is commonly understood or agreed upon. Lou > However tht is still far from data plane which I hope this discussion has > really nothing in common with. > > Best, > R. > On Mar 8, 2015 2:57 PM, "Lou Berger" wrote: > > > On 03/08/2015 09:29 AM, Igor Bryskin wrote: > > > However, we do not attempt to (re-)model the data plane, right? > > > > Really? I don't see a TP LSP that is managed without control plane as > > out of scope... > > > > Lou > > ------------14bfa5dbf5316bd27e94366b520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

On March 8, 2015 11:15:32 AM Robert Raszuk <robert@raszuk.net> wrote:

> Hi Lou,
>
> TP-LSP have a real control plane. It is a centralized one.
>

Agreed.

> You don't need distributed control plane to call it as such.
>

No disagreement, the function is the same. But I don't think your definition  is commonly  understood or agreed upon.

Lou

> However tht is still far from data plane which I hope this discussion has
> really nothing in common with.
>
> Best,
> R.
> On Mar 8, 2015 2:57 PM, "Lou Berger" <lberger@labn.net> wrote:
>
> > On 03/08/2015 09:29 AM, Igor Bryskin wrote:
> > >  However, we do not attempt to (re-)model the data plane, right?
> >
> > Really?  I don't see a TP LSP that is managed without control plane as
> > out of scope...
> >
> > Lou
> >

------------14bfa5dbf5316bd27e94366b520-- From nobody Sun Mar 8 11:20:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1901A00C3; Sun, 8 Mar 2015 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCqr84rT0Nc7; Sun, 8 Mar 2015 11:20:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0551A009E; Sun, 8 Mar 2015 11:20:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150308182013.27226.47673.idtracker@ietfa.amsl.com> Date: Sun, 08 Mar 2015 11:20:13 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-interconnected-te-info-exchange-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 18:20:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks Authors : Adrian Farrel John Drake Nabil Bitar George Swallow Daniele Ceccarelli Xian Zhang Filename : draft-ietf-teas-interconnected-te-info-exchange-02.txt Pages : 63 Date : 2015-03-08 Abstract: In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement and architecture for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-interconnected-te-info-exchange/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-interconnected-te-info-exchange-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-interconnected-te-info-exchange-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 8 11:22:41 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D331A00B5 for ; Sun, 8 Mar 2015 11:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.9 X-Spam-Level: X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYEafu4v3w2o for ; Sun, 8 Mar 2015 11:22:39 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F1F1A0006 for ; Sun, 8 Mar 2015 11:22:38 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t28IMag5019827; Sun, 8 Mar 2015 18:22:36 GMT Received: from 950129200 (089144218078.atnat0027.highway.a1.net [89.144.218.78]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t28IMZo8019821 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 8 Mar 2015 18:22:36 GMT From: "Adrian Farrel" To: Date: Sun, 8 Mar 2015 18:22:36 -0000 Message-ID: <00c001d059cc$db4ea830$91ebf890$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBZzNheTZ4xEFF/T3u6noZXtzl1eA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21386.001 X-TM-AS-Result: No--5.318-10.0-31-10 X-imss-scan-details: No--5.318-10.0-31-10 X-TMASE-MatchedRID: bmFMcyfDfoBeDtEKgt5AZriMC5wdwKqd0BciT9B07b5rMbakJN8OeVOS 95hWV5LTKOa+i7mFmZvkmehxuLOiwh43bpPn/5bkdiLDwvWethgLitYSIrUiB5TC1rfVPDgkEX4 5YqIU5dSzUZOarCZTLpzFzvc3r0xpZF6ysdFjt0pVnniKh7YTC30tCKdnhB58vqq8s2MNhPB9j2 GwzTE3vSq2rl3dzGQ1P7Kdytmoae7tqy2T1j45Kvt3UM702m078wb5X6grXwaglV+nnZAsLcC+k sT6a9fy Archived-At: Cc: draft-ietf-teas-interconnected-te-info-exchange@tools.ietf.org Subject: [Teas] New version of draft-ietf-teas-interconnected-te-info-exchange X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 18:22:41 -0000 Hi, According to the schedule presented at IETF-91 (in the CCAMP meeting), I have updated and posted a revision of this I-D. The changes are: - Added Section 5.3.3.2 "Mutual Exclusivity" as a severely cut-down version of Pavan's suggested text. - Filled in Section 5.4 about Dynamic Abstraction. - Filled in Section 5.6 about Address Management. - New Section 6.4 "Notes on a Solution" using material from John Drake and Hannes Gredler. - Filled in Section 11 "Manageability Considerations". - Minor tweaks to Section 13 for Security Considerations using comments from Xian Zhang. - Fixed a number of stylistic and typographic issues. At this point, there are no more sections marked and no more editor's notes. I believe I have addressed all comments from the mailing list(s) and fulfilled the promises made at IETF-91. I would really appreciate detailed reviews before asking the chairs to take the document to last call. Especially: what can we delete? :-) Thanks, Adrian From nobody Sun Mar 8 11:48:47 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEC41A00CA; Sun, 8 Mar 2015 11:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSqk-V8wJdhQ; Sun, 8 Mar 2015 11:48:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A557C1A00C7; Sun, 8 Mar 2015 11:48:41 -0700 (PDT) X-AuditID: c618062d-f79876d000003ebd-48-54fc449d623b Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F0.62.16061.D944CF45; Sun, 8 Mar 2015 13:46:22 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Sun, 8 Mar 2015 14:48:40 -0400 From: Gregory Mirsky To: Robert Raszuk , Loa Andersson Thread-Topic: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWY7Le4cVv75dNkqZzU3p3HVhN50S6nlA Date: Sun, 8 Mar 2015 18:48:39 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B91C163eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPrO48lz8hBk0nWCx2bVzNaPFv7hxm i1tLV7JaNC1sYrZo/bGDxYHV4+zNfyweS5b8ZPKYNb2NzWP3xgVMASxRXDYpqTmZZalF+nYJ XBl7Tj5kL2i5yVixcfZPtgbGFZcZuxg5OCQETCTOPGPqYuQEMsUkLtxbz9bFyMUhJHCEUWLX +TUsEM4yRoneF9dZQarYBIwkXmzsYQexRQQcJHas28MMYjMLZEnc/tkKViMsYCNx7s0MRoga W4l9ze+ZIWwjiQs/5oPVsAioSKzceJ4FxOYV8JX4c+spK8SyGSwSK3e3gDVzCgRKvO/eCbaM Eei876fWMEEsE5e49WQ+1NkCEkv2nGeGsEUlXj7+xwphK0nMeX0N6rh8iUntj9khlglKnJz5 hGUCo+gsJKNmISmbhaRsFjCQmAU0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRo7S4tSy 3HQjg02MwFg8JsGmu4Nxz0vLQ4wCHIxKPLwGu3+HCLEmlhVX5h5ilOZgURLnXfTgYIiQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGRvepH4OZr704+u9e3NTSM6pWy1df+ppzOrHr5eMTEkH/ c87MZP1ukvfhXkWY1d2NDpffZ0yXW2P4xEPqHfOdK2znpPWYOJVVPT4Y72c8ZLp378d1sXL7 k2VlSyw7Nmj0xFbu/+j1cPb5InMn47WPZ99yVxJektqvYX38kOgrrWDnEr8pOatiLiixFGck GmoxFxUnAgAr/GHFpgIAAA== Archived-At: Cc: "mpls@ietf.org" , "Shah, Himanshu" , "teas@ietf.org" Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 18:48:45 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B91C163eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LCBldC4gYWwsDQppZiBJIGludGVycHJldCB0aGUg4oCcTFNQIFlBTkcgbW9kZWzi gJ0sIHRoZW4gaXQgcmVhZHMgYXMgWUFORyBtb2RlbCBvZiBNUExTIGRhdGEgcGxhbmUsIG5vdCBj b250cm9sIHByb3RvY29sLCBiZSBpdCBSU1ZQLVRFLCBMRFAsIFBDRVAsIG9yIElHUC1URSBvZiBT UFJJTkcuIEFuZCwgc2luY2UgdGhlIE1QTFMgZGF0YSBwbGFuZSBpcyBpbmRlZWQgY29tbW9uIGFu ZCBpbiBmYWN0IHRoZSBvbmUgYW5kIG9ubHksIHN1Y2ggTFNQIFlBTkcgbW9kZWwgcmlnaHRmdWxs eSBjYW4gYmUgY2hhcmFjdGVyaXplZCBhcyDigJxHZW5lcmlj4oCdLg0KQnV0IGlmIGF1dGhvcnMg aW50ZW5kZWQgdG8gZGVzY3JpYmUgY29tbW9uIHNldCBhbW9uZyBsaXN0ZWQgYWJvdmUgY29udHJv bCBwcm90b2NvbHMgcGVydGFpbmluZyB0byBzaWduYWxpbmcgb2YgYW4gTVBMUyBMU1AsIHRoZW4s IElNTywgc3VjaCBjb21tb24gc2V0IGZpcnN0IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBpZGVudGlm aWVkIHRvIGRlbW9uc3RyYXRlIHRoYXQgaXQgZG9lcyBleGlzdCBhbmQgaXMgc3VmZmljaWVudCB0 byBoYXZlIFlBTkcgbW9kZWwgb2YgaXRzIG93biByYXRoZXIgdGhhbiBZQU5HIG1vZGVscyB0aGF0 IGRlc2NyaWJlIExTUCBjb250cm9sIGJ5IGVhY2ggc2lnbmFsaW5nIHByb3RvY29scy4gVGhhdCB0 byBtZSBsb29rcyB2ZXJ5IG11Y2ggbGlrZSB3aGF0IExJTUUgV0cgaXMgd29ya2luZyBvbiwgaW52 ZXN0aWdhdGluZyB3aGV0aGVyIGNvbW1vbiBtb2RlbCBvZiBJUCwgSVAvTVBMUywgTVBMUy1UUCwg YW5kIFRSSUxMIE9BTSBleGlzdHMgYW5kIGl0cyBleHRlbnQgaXMgc3VmZmljaWVudCB0byBiZSBv ZiBpbnRlcmVzdC4NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFN1bmRheSwgTWFyY2gg MDgsIDIwMTUgMzo1OCBBTQ0KVG86IExvYSBBbmRlcnNzb24NCkNjOiBtcGxzQGlldGYub3JnOyB0 ZWFzQGlldGYub3JnOyBTaGFoLCBIaW1hbnNodQ0KU3ViamVjdDogUmU6IFtUZWFzXSBbbXBsc10g W1J0Zy15YW5nLWNvb3JkXSBHZW5lcmljIExTUCBZYW5nDQoNCkhpIExvYSwNCg0KVGhlIHdheSBJ IHJlYWQgSWdvciBzdGF0ZW1lbnQgYW5kIGFncmVlZCB3aXRoIGl0IGluIGEgc2Vuc2Ugb2YgIm5v dGhpbmcgaW4gY29tbW9uIiB3YXMgdGhhdCBpdCB3YXMgcmVmZXJyaW5nIHRvIHRoZSBjb250cm9s IHBsYW5lLg0KDQpUaGUgc3ViamVjdCBvZiB0aGlzIHRocmVhZCBpcyAiR2VuZXJpYyBMU1AgWUFO RyIgYW5kIHRvIG1lIFlhbmcgbW9kZWwgZGVzY3JpYmVzIGNvbnRyb2wgYXNwZWN0IG9mIHByb3Rv Y29sIG9yIGZ1bmN0aW9uYWxpdHkgbm90IHRoZSBjaG9pY2Ugb2YgZm9yd2FyZGluZyBoZWFkZXIg aW4gdGhlIGRhdGEgcGxhbmUuDQoNClNvIGlmIHlvdSBhbmQgb3RoZXJzIGFncmVlIHdlIHNob3Vs ZCBiZSBhbGwgaW4gc3luYyBhbmQgcGVyaGFwcyB3ZSBjb3VsZCBjb25zaWRlciBhcyBwcm9wb3Nl ZCBiZWZvcmUgR2VuZXJpYyBFbmdpbmVlcmVkIFBhdGggbW9kZWwgYnJhbmNoaW5nIGF0IHRoZSBs b3dlciBsYXllciBiZXR3ZWVuIHVuaWNhc3QgYW5kIG11bHRpY2FzdC4NCg0KSG93ZXZlciBpZiB5 b3Ugc3RpbGwgdGhpbmsgdGhhdCBZYW5nIGlzIGFib3V0IGRhdGEgcGxhbmUgYW5kIE9BTSB0aGVu IHBlcmhhcHMgd2UgaGF2ZSBhIGJpZ2dlciBpc3N1ZSBoZXJlIC4uLi4NCg0KQ2hlZXJzLA0KUi4N Cg0KDQoNCg0KT24gU3VuLCBNYXIgOCwgMjAxNSBhdCAxMDoyNyBBTSwgTG9hIEFuZGVyc3NvbiA8 bG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToNCkhpbWFuc2h1LCBldC5hbDxodHRw Oi8vZXQuYWw+LiwNCg0KSSB0aGluayB0aGVyZSBhcmUgdHdvIGlzc3VlcyBoZXJlIGFuZCBpZiBz b3J0aW5nIHRoZW0gb3V0IGNvcnJyZWN0bHkNCndlIGFyZSB2ZXJ5IGNsb3NlLg0KDQpUaGUgZmly c3QgaXNzdWUgaXMgc2ltaWxhcml0aWVzIGJldHdlZW4gZGlmZmVyZW50IHR5cGVzIG9mIExTUHMu DQoNCkhlcmUgSSBzYWlkIHRoYXQsIGF0IGxlYXN0IGZvciBhIE1QTFMgUFNOLCB0aGVyZSBhcmUg c2ltaWxhcml0aWVzLA0KZS5nLiB0aGUgZGF0YSBwbGFuZSBpcyAobmVhcmx5KSB0aGUgc2FtZS4g VGhpcyB3YXMgc2FpZCBpbiByZWFjdGlvbg0KdG8gSWdvcidzIHN0YXRlbWVudCAiSU1ITyBURS1M U1AsIExEUC1MU1AgYW5kIFNQUklORy1MU1AgaGF2ZSBub3RoaW5nDQppbiBjb21tb24uIiBJIHN0 aWxsIGRvbid0IHRoaW5rIHRoYXQgSWdvcidzIHN0YXRlbWVudCBpcyByZWFsbHkgY29ycmVjdC4N CklmIGhlIGhhZCBzYWlkICJJTUhPIHRoZXJlIGFyZSBub3QgZW5vdWdoIHNpbWlsYXJpdGVzIGJl dHdlZW4gVEUtTFNQLA0KTERQLUxTUCBhbmQgU1BSSU5HLUxTUCB0byBtb3RpdmF0ZSBhIGNvbW1v biBtb2RlbCIuIEkgdGhpbmsgdGhhdCB3ZSBiZQ0KYSBtdWNoIG1vcmUgYWNjdXJhdGUgc3RhdGVt ZW50Lg0KDQpBbmQgdGhhdCBpcyB0aGUgb3RoZXIgaXNzdWUgLSBJcyBpdCByZWFzb25hYmxlIHRv IG1vZGVsIFRFLUxTUCwNCkxEUC1MU1AgYW5kIFNQUklORy1MU1AgaW4gdGhlIHNhbWUgbW9kZWw/ IEkgZG9uJ3Qgbm90IHRoaW5rIGl0IGlzLA0KYnV0IHRoYXQgd2UgbmVlZCBhbiBvdmVybGFwIG9m IHBlb3BsZSB3b3JraW5nIHdpdGggdGhlIGRpZmZlcmVudCBtb2RlbHMuDQoNCkhvcGUgdGhpcyBp cyBjbGVhciBlbm91Z2guDQoNCi9Mb2ENCg0KDQpPbiAyMDE1LTAzLTA3IDIzOjE5LCBTaGFoLCBI aW1hbnNodSB3cm90ZToNCi9JIGFncmVlIHdpdGggUm9iZXJ0IGFuZCBJZ29yLCBwdXR0aW5nIGV2 ZXJ5dGhpbmcgaW4gdGhlIHNhbWUgYnVja2V0DQpiZWNhdXNlIG9mIGNvbW1vbiBkYXRhIHBsYW5l ICYgT0FNIGRvZXMgbm90IGp1c3RpZnkuLw0KDQovV2Ugd291bGRu4oCZdCBjb25zaWRlciBkb2lu ZyBzYW1lIGZvciBJUCBkYXRhIHBsYW5lLi4vDQoNCi9JIHRoaW5rIHdlIG5lZWQgdG8gc2VwYXJh dGUgdGhlc2UgbW9kZWxzIGFuZCBhcyBtZW50aW9uZWQgZWFybGllciwNCnRoZXJlIGlzIGFscmVh ZHkgd29yayBnb2luZyBvbiBpbiByZXNwZWN0aXZlIFdHcy4vDQoNCi8vDQoNCi9UaGFua3MsLw0K DQovaGltYW5zaHUvDQoNCi8vDQoNCi8vDQoNCi8vDQoNCipGcm9tOiptcGxzIFttYWlsdG86bXBs cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSAqT24gQmVo YWxmIE9mICpMb2EgQW5kZXJzc29uDQoqU2VudDoqIFNhdHVyZGF5LCBNYXJjaCAwNywgMjAxNSA4 OjE4IEFNDQoqVG86KiB0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPiwgbXBsc0Bp ZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4sIHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpy b2JlcnRAcmFzenVrLm5ldD4NCipTdWJqZWN0OiogUmU6IFttcGxzXSBbUnRnLXlhbmctY29vcmRd IFtUZWFzXSBHZW5lcmljIExTUCBZYW5nDQoNClJvYmVydCwNCg0KIEZyb20gb25lIHBlcnNwZWN0 aXZlIEkgYWdyZWUgd2l0aCB5b3UgYW5kIElnb3IsIGhvd2V2ZXIgaWYgeW91IHRoaW5rDQphYm91 dCBNUExTIExTUHMsIGZyb20gYSBkYXRhIHBsYW5lIHBlcnNwZWN0aXZlIC0gYW5kIHRoYXQgaXMg d2hlcmUgT0FNDQpvcGVyYXRlcywgdGhlcmUgYWxtb3N0IG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBh IFRFLUxTUCBhIExEUC1MU1AgYW5kIGENClNQUklORyBNUExTIExTUCBjb21lIHZlcnkgY2xvc2Uu DQoNCklmIHlvdSB0aGUgb3RoZXIgaGFuZCB0aGluayBvZiBMU1BzIGZvciBvdGhlciBkYXRhIHBs YW5lcyB0aGUgIm5vdGhpbmcNCmluIGNvbW1vbiIgaXMgYW4gYWxtb3N0IHRydWUgc3RhdGVtZW50 LiBGcm9tIHRoYXQgcG9pbnQgb2YgdmlldyBJIHRoaW5rDQpkaWZmZXJlbnQgbW9kZWxzIGFyZSB3 aGVyZSB3ZSB3aWxsIGVuZCB1cCwgYnV0IEkgYWxzbyB0aGluayB0aGF0IHdlIG5lZWQNCiJzZXBh cmF0aW9uIHdpdGggbW9kZXJhdGlvbiIuDQoNCiAgQnV0IG5vdGhpbmcgaXMgc28gc2ltcGxlIHRo YXQgd2UgY2FuIGNhcHR1cmUgaXQgaW4gb25lIHZlcnkgc2ltcGxlDQpzdGF0ZW1lbnQsIHdlIGhh dmUgaGFja2luZyBhd2F5IG9uIHRoaXMgZm9yIDMwIHllYXJzIG5vdywgSSdkIGFkdmljZQ0KdGFr aW5nIGFyY2hpdGVjdHVyZSBhbmQgaGlzdG9yeSBpbnRvIGNvbnNpZGVyYXRpb24sIGFzIHdlbGwg YXMgdmlld2luZw0KdGhlIHNreSBmcm9tIGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIHRoYW4gZnJv bSB0aGUgYm90dG9tIG9mIGEgZGVlcCB3ZWxsLg0KDQpMZXQgbWUgYWxzbyBzYXkgdGhhdCBJJ20g dmVyeSBzdXBwb3J0aXZlIG9mIGFsbCB0aGUgZ29vZCB3b3JrIGdvaW5nIG9uDQppbiB0aGlzIGFy ZWEuDQoNCi9Mb2ENCg0KU2VudCBmcm9tIG15IGlQYWQNCg0KDQpPbiAwNyBNYXIgMjAxNSwgYXQg MTk6NDcsIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFz enVrLm5ldD4NCjxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsu bmV0Pj4+IHdyb3RlOg0KDQogICAgSSB3b3VsZCBhZ3JlZSB3aXRoIElnb3IuDQoNCiAgICBPdGhl ciB0aGVuIG5hbWUgb3ZlcmxhcCB0aG9zZSBhcmUgY29tcGxldGVseSBkaWZmZXJlbnQgdGVjaG5v bG9naWVzDQogICAgYW5kIGFydGlmaWNpYWxseSBwdXR0aW5nIHRoZW0gdW5kZXIgIkxTUCIgdW1i cmVsbGEganVzdCBkb2VzIG5vdA0KICAgIGJyaW5nIGFueSB2YWx1ZSwgYnV0IG9ubHkgY29uZnVz ZXMgdGhpbmdzIGV2ZW4gbW9yZS4NCg0KICAgIFE6IFdoYXQgU1BSSU5HLUxTUCBoYXMgYW55dGhp bmcgaW4gY29tbW9uIHdpdGggImxhYmVsIiB3aGVuIHlvdSB1c2UNCiAgICB2NiBoZWFkZXIgPw0K DQogICAgSWYgeW91IHdhbnQgdG8gc2VhcmNoIGZvciBzb21lIGNvbW1vbmFsaXRpZXMgbGV0J3Mg cmVtb3ZlIExEUC1MU1BzDQogICAgZnJvbSB0aGlzIG1peCAoYXMgdGhlIGlzIG5vdCByZWxldmFu dCkgYW5kIGxlYXZlIFRFLUxTUCAmIFNQUklORyArDQogICAgbWF5YmUgYWxzbyBhZGQgQklFUiBh cyB3ZWxsIGFzIGNoYW5nZSB0aGUgbmFtZSB0byBHZW5lcmljLUVQDQogICAgKEVuZ2luZWVyZWQg UGF0aHMpLg0KDQogICAgSSBzZWUgbm8gdmFsdWUgb2YgZ29ydXBpbmcgYmFzZWQgb24gdGhlIGZh Y3QgdGhhdCBkYXRhIHBsYW5lIHVzZXMNCiAgICBtcGxzIGxhYmVscywgYnV0IHJhdGhlciBJIHdv dWxkIHNlZSByZWFzb25hYmxlIHRvIHByb3ZpZGUgbW9kZWxzDQogICAgYmFzZWQgb24gdGhlIHRy YW5zcG9ydCBwYXRoIGNoYXJhY3RlcmlzdGljcyBmb3IgdGhlIHRyYWZmaWMgaXQgaXMgdG8NCiAg ICBjYXJyeS4NCg0KICAgIEJlc3QsDQoNCiAgICByLg0KDQogICAgT24gRnJpLCBNYXIgNiwgMjAx NSBhdCAyOjExIFBNLCBJZ29yIEJyeXNraW4NCiAgICA8SUJyeXNraW5AYWR2YW9wdGljYWwuY29t PG1haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20+IDxtYWlsdG86SUJyeXNraW5AYWR2YW9w dGljYWwuY29tPG1haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20+Pj4gd3JvdGU6DQoNCiAg ICBEcnV2LA0KDQogICAgSU1ITyBURS1MU1AsIExEUC1MU1AgYW5kIFNQUklORy1MU1AgaGF2ZSBu b3RoaW5nIGluIGNvbW1vbi4gVGhleQ0KICAgIHNob3VsZCBoYXZlIHRvdGFsbHkgaW5kZXBlbmRl bnQgbW9kZWxzIGVhY2ggYmVpbmcgZGV2ZWxvcGVkIGluDQogICAgcmVzcGVjdGl2ZSBXRy4NCg0K ICAgIElnb3INCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQogICAgUnRnLXlhbmctY29v cmRAaWV0Zi5vcmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPiA8bWFpbHRvOlJ0Zy15 YW5nLWNvb3JkQGlldGYub3JnPG1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZz4+DQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRlYXMg bWFpbGluZyBsaXN0DQpUZWFzQGlldGYub3JnPG1haWx0bzpUZWFzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQoNCi0tDQoNCg0KTG9hIEFuZGVy c3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208 bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbT4NClNlbmlvciBNUExTIEV4cGVydCAgICAgICAg ICAgICAgICAgICAgICAgICAgbG9hQHBpLm51PG1haWx0bzpsb2FAcGkubnU+DQpIdWF3ZWkgVGVj aG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQ8dGVsOiUy QjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0Pg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B91C163eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhv ZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBSb2JlcnQsIGV0LiBhbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+aWYgSSBpbnRlcnByZXQgdGhlIOKAnExTUCBZQU5HIG1vZGVs4oCdLCB0aGVuIGl0 IHJlYWRzIGFzIFlBTkcgbW9kZWwgb2YgTVBMUyBkYXRhIHBsYW5lLCBub3QgY29udHJvbCBwcm90 b2NvbCwgYmUgaXQgUlNWUC1URSwgTERQLCBQQ0VQLCBvciBJR1AtVEUgb2YgU1BSSU5HLiBBbmQs DQogc2luY2UgdGhlIE1QTFMgZGF0YSBwbGFuZSBpcyBpbmRlZWQgY29tbW9uIGFuZCBpbiBmYWN0 IHRoZSBvbmUgYW5kIG9ubHksIHN1Y2ggTFNQIFlBTkcgbW9kZWwgcmlnaHRmdWxseSBjYW4gYmUg Y2hhcmFjdGVyaXplZCBhcyDigJxHZW5lcmlj4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5CdXQgaWYgYXV0aG9ycyBpbnRlbmRlZCB0byBkZXNjcmliZSBjb21tb24gc2V0IGFtb25n IGxpc3RlZCBhYm92ZSBjb250cm9sIHByb3RvY29scyBwZXJ0YWluaW5nIHRvIHNpZ25hbGluZyBv ZiBhbiBNUExTIExTUCwgdGhlbiwgSU1PLCBzdWNoIGNvbW1vbiBzZXQgZmlyc3QNCiBtdXN0IGJl IGRpc2N1c3NlZCBhbmQgaWRlbnRpZmllZCB0byBkZW1vbnN0cmF0ZSB0aGF0IGl0IGRvZXMgZXhp c3QgYW5kIGlzIHN1ZmZpY2llbnQgdG8gaGF2ZSBZQU5HIG1vZGVsIG9mIGl0cyBvd24gcmF0aGVy IHRoYW4gWUFORyBtb2RlbHMgdGhhdCBkZXNjcmliZSBMU1AgY29udHJvbCBieSBlYWNoIHNpZ25h bGluZyBwcm90b2NvbHMuIFRoYXQgdG8gbWUgbG9va3MgdmVyeSBtdWNoIGxpa2Ugd2hhdCBMSU1F IFdHIGlzIHdvcmtpbmcgb24sIGludmVzdGlnYXRpbmcNCiB3aGV0aGVyIGNvbW1vbiBtb2RlbCBv ZiBJUCwgSVAvTVBMUywgTVBMUy1UUCwgYW5kIFRSSUxMIE9BTSBleGlzdHMgYW5kIGl0cyBleHRl bnQgaXMgc3VmZmljaWVudCB0byBiZSBvZiBpbnRlcmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1hcmNo IDA4LCAyMDE1IDM6NTggQU08YnI+DQo8Yj5Ubzo8L2I+IExvYSBBbmRlcnNzb248YnI+DQo8Yj5D Yzo8L2I+IG1wbHNAaWV0Zi5vcmc7IHRlYXNAaWV0Zi5vcmc7IFNoYWgsIEhpbWFuc2h1PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbVGVhc10gW21wbHNdIFtSdGcteWFuZy1jb29yZF0gR2VuZXJp YyBMU1AgWWFuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkhpIExvYSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhl IHdheSBJIHJlYWQgSWdvciBzdGF0ZW1lbnQgYW5kIGFncmVlZCB3aXRoIGl0IGluIGEgc2Vuc2Ug b2YgJnF1b3Q7bm90aGluZyBpbiBjb21tb24mcXVvdDsgd2FzIHRoYXQgaXQgd2FzIHJlZmVycmlu ZyB0byB0aGUgY29udHJvbCBwbGFuZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHN1YmplY3Qgb2YgdGhpcyB0aHJlYWQgaXMg JnF1b3Q7R2VuZXJpYyBMU1AgWUFORyZxdW90OyBhbmQgdG8gbWUgWWFuZyBtb2RlbCBkZXNjcmli ZXMgY29udHJvbCBhc3BlY3Qgb2YgcHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBub3QgdGhlIGNo b2ljZSBvZiBmb3J3YXJkaW5nIGhlYWRlciBpbiB0aGUgZGF0YSBwbGFuZS4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gaWYgeW91 IGFuZCBvdGhlcnMgYWdyZWUgd2Ugc2hvdWxkIGJlIGFsbCBpbiBzeW5jIGFuZCBwZXJoYXBzIHdl IGNvdWxkIGNvbnNpZGVyIGFzIHByb3Bvc2VkIGJlZm9yZSBHZW5lcmljIEVuZ2luZWVyZWQgUGF0 aCBtb2RlbCBicmFuY2hpbmcgYXQgdGhlIGxvd2VyIGxheWVyIGJldHdlZW4gdW5pY2FzdCBhbmQg bXVsdGljYXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5Ib3dldmVyIGlmIHlvdSBzdGlsbCB0aGluayB0aGF0IFlhbmcgaXMgYWJv dXQgZGF0YSBwbGFuZSBhbmQgT0FNIHRoZW4gcGVyaGFwcyB3ZSBoYXZlIGEgYmlnZ2VyIGlzc3Vl IGhlcmUgLi4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5DaGVlcnMsPGJyPg0KUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgTWFyIDgsIDIwMTUgYXQg MTA6MjcgQU0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRh cmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpbWFuc2h1LCA8YSBocmVmPSJodHRwOi8vZXQuYWwiIHRhcmdl dD0iX2JsYW5rIj5ldC5hbDwvYT4uLDxicj4NCjxicj4NCkkgdGhpbmsgdGhlcmUgYXJlIHR3byBp c3N1ZXMgaGVyZSBhbmQgaWYgc29ydGluZyB0aGVtIG91dCBjb3JycmVjdGx5PGJyPg0Kd2UgYXJl IHZlcnkgY2xvc2UuPGJyPg0KPGJyPg0KVGhlIGZpcnN0IGlzc3VlIGlzIHNpbWlsYXJpdGllcyBi ZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZiBMU1BzLjxicj4NCjxicj4NCkhlcmUgSSBzYWlkIHRo YXQsIGF0IGxlYXN0IGZvciBhIE1QTFMgUFNOLCB0aGVyZSBhcmUgc2ltaWxhcml0aWVzLDxicj4N CmUuZy4gdGhlIGRhdGEgcGxhbmUgaXMgKG5lYXJseSkgdGhlIHNhbWUuIFRoaXMgd2FzIHNhaWQg aW4gcmVhY3Rpb248YnI+DQp0byBJZ29yJ3Mgc3RhdGVtZW50ICZxdW90O0lNSE8gVEUtTFNQLCBM RFAtTFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZzxicj4NCmluIGNvbW1vbi4mcXVvdDsg SSBzdGlsbCBkb24ndCB0aGluayB0aGF0IElnb3IncyBzdGF0ZW1lbnQgaXMgcmVhbGx5IGNvcnJl Y3QuPGJyPg0KSWYgaGUgaGFkIHNhaWQgJnF1b3Q7SU1ITyB0aGVyZSBhcmUgbm90IGVub3VnaCBz aW1pbGFyaXRlcyBiZXR3ZWVuIFRFLUxTUCw8YnI+DQpMRFAtTFNQIGFuZCBTUFJJTkctTFNQIHRv IG1vdGl2YXRlIGEgY29tbW9uIG1vZGVsJnF1b3Q7LiBJIHRoaW5rIHRoYXQgd2UgYmU8YnI+DQph IG11Y2ggbW9yZSBhY2N1cmF0ZSBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KQW5kIHRoYXQgaXMgdGhl IG90aGVyIGlzc3VlIC0gSXMgaXQgcmVhc29uYWJsZSB0byBtb2RlbCBURS1MU1AsPGJyPg0KTERQ LUxTUCBhbmQgU1BSSU5HLUxTUCBpbiB0aGUgc2FtZSBtb2RlbD8gSSBkb24ndCBub3QgdGhpbmsg aXQgaXMsPGJyPg0KYnV0IHRoYXQgd2UgbmVlZCBhbiBvdmVybGFwIG9mIHBlb3BsZSB3b3JraW5n IHdpdGggdGhlIGRpZmZlcmVudCBtb2RlbHMuPGJyPg0KPGJyPg0KSG9wZSB0aGlzIGlzIGNsZWFy IGVub3VnaC48YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxNS0wMy0wNyAy MzoxOSwgU2hhaCwgSGltYW5zaHUgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi9JIGFncmVlIHdpdGggUm9iZXJ0 IGFuZCBJZ29yLCBwdXR0aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHNhbWUgYnVja2V0PGJyPg0KYmVj YXVzZSBvZiBjb21tb24gZGF0YSBwbGFuZSAmYW1wOyBPQU0gZG9lcyBub3QganVzdGlmeS4vPGJy Pg0KPGJyPg0KL1dlIHdvdWxkbuKAmXQgY29uc2lkZXIgZG9pbmcgc2FtZSBmb3IgSVAgZGF0YSBw bGFuZS4uLzxicj4NCjxicj4NCi9JIHRoaW5rIHdlIG5lZWQgdG8gc2VwYXJhdGUgdGhlc2UgbW9k ZWxzIGFuZCBhcyBtZW50aW9uZWQgZWFybGllciw8YnI+DQp0aGVyZSBpcyBhbHJlYWR5IHdvcmsg Z29pbmcgb24gaW4gcmVzcGVjdGl2ZSBXR3MuLzxicj4NCjxicj4NCi8vPGJyPg0KPGJyPg0KL1Ro YW5rcywvPGJyPg0KPGJyPg0KL2hpbWFuc2h1Lzxicj4NCjxicj4NCi8vPGJyPg0KPGJyPg0KLy88 YnI+DQo8YnI+DQovLzxicj4NCjxicj4NCipGcm9tOiptcGxzIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2YgKkxvYSBBbmRlcnNzb248YnI+DQoqU2VudDoqIFNh dHVyZGF5LCBNYXJjaCAwNywgMjAxNSA4OjE4IEFNPGJyPg0KKlRvOiogPGEgaHJlZj0ibWFpbHRv OnRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzQGlldGYub3JnPC9hPiwgPGEgaHJl Zj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm1wbHNAaWV0Zi5vcmc8 L2E+LCA8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5y b2JlcnRAcmFzenVrLm5ldDwvYT48YnI+DQoqU3ViamVjdDoqIFJlOiBbbXBsc10gW1J0Zy15YW5n LWNvb3JkXSBbVGVhc10gR2VuZXJpYyBMU1AgWWFuZzxicj4NCjxicj4NClJvYmVydCw8YnI+DQo8 YnI+DQombmJzcDtGcm9tIG9uZSBwZXJzcGVjdGl2ZSBJIGFncmVlIHdpdGggeW91IGFuZCBJZ29y LCBob3dldmVyIGlmIHlvdSB0aGluazxicj4NCmFib3V0IE1QTFMgTFNQcywgZnJvbSBhIGRhdGEg cGxhbmUgcGVyc3BlY3RpdmUgLSBhbmQgdGhhdCBpcyB3aGVyZSBPQU08YnI+DQpvcGVyYXRlcywg dGhlcmUgYWxtb3N0IG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIFRFLUxTUCBhIExEUC1MU1AgYW5k IGE8YnI+DQpTUFJJTkcgTVBMUyBMU1AgY29tZSB2ZXJ5IGNsb3NlLjxicj4NCjxicj4NCklmIHlv dSB0aGUgb3RoZXIgaGFuZCB0aGluayBvZiBMU1BzIGZvciBvdGhlciBkYXRhIHBsYW5lcyB0aGUg JnF1b3Q7bm90aGluZzxicj4NCmluIGNvbW1vbiZxdW90OyBpcyBhbiBhbG1vc3QgdHJ1ZSBzdGF0 ZW1lbnQuIEZyb20gdGhhdCBwb2ludCBvZiB2aWV3IEkgdGhpbms8YnI+DQpkaWZmZXJlbnQgbW9k ZWxzIGFyZSB3aGVyZSB3ZSB3aWxsIGVuZCB1cCwgYnV0IEkgYWxzbyB0aGluayB0aGF0IHdlIG5l ZWQ8YnI+DQomcXVvdDtzZXBhcmF0aW9uIHdpdGggbW9kZXJhdGlvbiZxdW90Oy48YnI+DQo8YnI+ DQombmJzcDsgQnV0IG5vdGhpbmcgaXMgc28gc2ltcGxlIHRoYXQgd2UgY2FuIGNhcHR1cmUgaXQg aW4gb25lIHZlcnkgc2ltcGxlPGJyPg0Kc3RhdGVtZW50LCB3ZSBoYXZlIGhhY2tpbmcgYXdheSBv biB0aGlzIGZvciAzMCB5ZWFycyBub3csIEknZCBhZHZpY2U8YnI+DQp0YWtpbmcgYXJjaGl0ZWN0 dXJlIGFuZCBoaXN0b3J5IGludG8gY29uc2lkZXJhdGlvbiwgYXMgd2VsbCBhcyB2aWV3aW5nPGJy Pg0KdGhlIHNreSBmcm9tIGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIHRoYW4gZnJvbSB0aGUgYm90 dG9tIG9mIGEgZGVlcCB3ZWxsLjxicj4NCjxicj4NCkxldCBtZSBhbHNvIHNheSB0aGF0IEknbSB2 ZXJ5IHN1cHBvcnRpdmUgb2YgYWxsIHRoZSBnb29kIHdvcmsgZ29pbmcgb248YnI+DQppbiB0aGlz IGFyZWEuPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGFkPGJyPg0K PGJyPg0KPGJyPg0KT24gMDcgTWFyIDIwMTUsIGF0IDE5OjQ3LCBSb2JlcnQgUmFzenVrICZsdDs8 YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRA cmFzenVrLm5ldDwvYT48YnI+DQombHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFz enVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsmZ3Q7IHdy b3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSB3b3VsZCBhZ3JlZSB3aXRoIElnb3IuPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPdGhlciB0aGVuIG5hbWUgb3ZlcmxhcCB0aG9zZSBhcmUg Y29tcGxldGVseSBkaWZmZXJlbnQgdGVjaG5vbG9naWVzPGJyPg0KJm5ic3A7ICZuYnNwOyBhbmQg YXJ0aWZpY2lhbGx5IHB1dHRpbmcgdGhlbSB1bmRlciAmcXVvdDtMU1AmcXVvdDsgdW1icmVsbGEg anVzdCBkb2VzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgYnJpbmcgYW55IHZhbHVlLCBidXQgb25s eSBjb25mdXNlcyB0aGluZ3MgZXZlbiBtb3JlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUTog V2hhdCBTUFJJTkctTFNQIGhhcyBhbnl0aGluZyBpbiBjb21tb24gd2l0aCAmcXVvdDtsYWJlbCZx dW90OyB3aGVuIHlvdSB1c2U8YnI+DQombmJzcDsgJm5ic3A7IHY2IGhlYWRlciA/PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBJZiB5b3Ugd2FudCB0byBzZWFyY2ggZm9yIHNvbWUgY29tbW9uYWxp dGllcyBsZXQncyByZW1vdmUgTERQLUxTUHM8YnI+DQombmJzcDsgJm5ic3A7IGZyb20gdGhpcyBt aXggKGFzIHRoZSBpcyBub3QgcmVsZXZhbnQpIGFuZCBsZWF2ZSBURS1MU1AgJmFtcDsgU1BSSU5H ICYjNDM7PGJyPg0KJm5ic3A7ICZuYnNwOyBtYXliZSBhbHNvIGFkZCBCSUVSIGFzIHdlbGwgYXMg Y2hhbmdlIHRoZSBuYW1lIHRvIEdlbmVyaWMtRVA8YnI+DQombmJzcDsgJm5ic3A7IChFbmdpbmVl cmVkIFBhdGhzKS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgc2VlIG5vIHZhbHVlIG9mIGdv cnVwaW5nIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgZGF0YSBwbGFuZSB1c2VzPGJyPg0KJm5ic3A7 ICZuYnNwOyBtcGxzIGxhYmVscywgYnV0IHJhdGhlciBJIHdvdWxkIHNlZSByZWFzb25hYmxlIHRv IHByb3ZpZGUgbW9kZWxzPGJyPg0KJm5ic3A7ICZuYnNwOyBiYXNlZCBvbiB0aGUgdHJhbnNwb3J0 IHBhdGggY2hhcmFjdGVyaXN0aWNzIGZvciB0aGUgdHJhZmZpYyBpdCBpcyB0bzxicj4NCiZuYnNw OyAmbmJzcDsgY2FycnkuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBCZXN0LDxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgci48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIEZyaSwgTWFyIDYs IDIwMTUgYXQgMjoxMSBQTSwgSWdvciBCcnlza2luPGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7PGEg aHJlZj0ibWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPklC cnlza2luQGFkdmFvcHRpY2FsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SUJy eXNraW5AYWR2YW9wdGljYWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+SUJyeXNraW5AYWR2YW9wdGlj YWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgRHJ1diw8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElNSE8gVEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJTkct TFNQIGhhdmUgbm90aGluZyBpbiBjb21tb24uIFRoZXk8YnI+DQombmJzcDsgJm5ic3A7IHNob3Vs ZCBoYXZlIHRvdGFsbHkgaW5kZXBlbmRlbnQgbW9kZWxzIGVhY2ggYmVpbmcgZGV2ZWxvcGVkIGlu PGJyPg0KJm5ic3A7ICZuYnNwOyByZXNwZWN0aXZlIFdHLjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgSWdvcjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7IFJ0Zy15YW5nLWNvb3Jk IG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5n LWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGcteWFuZy1jb29yZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZDwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRlYXMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRlYXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5UZWFzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhczwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFz cz0iaG9lbnpiIj4tLSA8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56 YiI+TG9hIEFuZGVyc3NvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVtYWlsOiA8YSBocmVm PSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAbWFp bDAxLmh1YXdlaS5jb208L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPlNlbmlv ciBNUExTIEV4cGVydCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJt YWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGkubnU8L2E+PC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQp Jm5ic3A7ICZuYnNwOyAmbmJzcDtwaG9uZTogPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzM5JTIwODEl MjAyMSUyMDY0IiB0YXJnZXQ9Il9ibGFuayI+DQomIzQzOzQ2IDczOSA4MSAyMSA2NDwvYT48L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B91C163eusaamb103erics_-- From nobody Sun Mar 8 12:03:05 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78831A00E9; Sun, 8 Mar 2015 12:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dagD2ke9a7Vz; Sun, 8 Mar 2015 12:03:01 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6401A00E6; Sun, 8 Mar 2015 12:03:00 -0700 (PDT) Received: by iecrp18 with SMTP id rp18so29765475iec.7; Sun, 08 Mar 2015 12:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aGpR1DfgjKZuMjPVca1xa5UoFb9lhgpDlaI2Y1AV7zw=; b=DLsvBh1mhUtDO9vYL0FsLe9EzNYN3tzhOL4zogk7SZfrpuOkHCT0/JvwndKLf1KQ+o uakXjRlNGpxu7SJrfcPvrQhsVjfs2Dv52sFrmx5+wy1fRBrkfsBzxmILIxGGUw9Q6IW4 6Sr1N1qnFBsIx+46x1Ae5rCFBwNY1uRCGZFG6CLb+CBLqkAejSAgfXj/vWwFnW9Ql1n/ mc5JR4bvUusDbMuZi/u77fxA+C8we2t8AdGC3tehXCAtIV1OBmNvmC3oWyIrCjxjRpAS e7FriyefHTUEgX59lAbs/mv0unE103TYAk0hEfm4OLUeTBibQSZx4cPYXt8IQnsXagPv 482g== MIME-Version: 1.0 X-Received: by 10.42.106.204 with SMTP id a12mr21999560icp.90.1425841380342; Sun, 08 Mar 2015 12:03:00 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 12:03:00 -0700 (PDT) Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 12:03:00 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> Date: Sun, 8 Mar 2015 20:03:00 +0100 X-Google-Sender-Auth: hMgL_oqKAdPnvEVfZKCY4ZcrZyQ Message-ID: From: Robert Raszuk To: Gregory Mirsky Content-Type: multipart/alternative; boundary=20cf304352b6fb453e0510cb90b3 Archived-At: Cc: "mpls@ietf.org" , teas@ietf.org, Himanshu Shah , Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:03:04 -0000 --20cf304352b6fb453e0510cb90b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Whow .. i think we are discovering that we all have no clue what Yang model is :) That is in fact I think great discussion to have sooner then later. To me Yang model is a way to represent unified (across inplementations) picture of control plane for a given network application. It has nothing to do with data plane to the extend of avoiding lock-in to mpls or ipv4 or ipv6. The attempt to generalize LSP would be equivalent to generalize Routing regardless if this is IGP or BGP or TRILL ... the outcome of that would be rather poor I suppose ... Cheers, R. On Mar 8, 2015 7:48 PM, "Gregory Mirsky" wrote: > Hi Robert, et. al, > > if I interpret the =E2=80=9CLSP YANG model=E2=80=9D, then it reads as YAN= G model of MPLS > data plane, not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of > SPRING. And, since the MPLS data plane is indeed common and in fact the o= ne > and only, such LSP YANG model rightfully can be characterized as =E2=80= =9CGeneric=E2=80=9D. > > But if authors intended to describe common set among listed above control > protocols pertaining to signaling of an MPLS LSP, then, IMO, such common > set first must be discussed and identified to demonstrate that it does > exist and is sufficient to have YANG model of its own rather than YANG > models that describe LSP control by each signaling protocols. That to me > looks very much like what LIME WG is working on, investigating whether > common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its extent > is sufficient to be of interest. > > > > Regards, > > Greg > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Sunday, March 08, 2015 3:58 AM > *To:* Loa Andersson > *Cc:* mpls@ietf.org; teas@ietf.org; Shah, Himanshu > *Subject:* Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang > > > > Hi Loa, > > > > The way I read Igor statement and agreed with it in a sense of "nothing i= n > common" was that it was referring to the control plane. > > > > The subject of this thread is "Generic LSP YANG" and to me Yang model > describes control aspect of protocol or functionality not the choice of > forwarding header in the data plane. > > > > So if you and others agree we should be all in sync and perhaps we could > consider as proposed before Generic Engineered Path model branching at th= e > lower layer between unicast and multicast. > > > > However if you still think that Yang is about data plane and OAM then > perhaps we have a bigger issue here .... > > > > Cheers, > R. > > > > > > > > > > On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson wrote: > > Himanshu, et.al., > > I think there are two issues here and if sorting them out corrrectly > we are very close. > > The first issue is similarities between different types of LSPs. > > Here I said that, at least for a MPLS PSN, there are similarities, > e.g. the data plane is (nearly) the same. This was said in reaction > to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing > in common." I still don't think that Igor's statement is really correct. > If he had said "IMHO there are not enough similarites between TE-LSP, > LDP-LSP and SPRING-LSP to motivate a common model". I think that we be > a much more accurate statement. > > And that is the other issue - Is it reasonable to model TE-LSP, > LDP-LSP and SPRING-LSP in the same model? I don't not think it is, > but that we need an overlap of people working with the different models. > > Hope this is clear enough. > > /Loa > > > On 2015-03-07 23:19, Shah, Himanshu wrote: > > /I agree with Robert and Igor, putting everything in the same bucket > because of common data plane & OAM does not justify./ > > /We wouldn=E2=80=99t consider doing same for IP data plane../ > > /I think we need to separate these models and as mentioned earlier, > there is already work going on in respective WGs./ > > // > > /Thanks,/ > > /himanshu/ > > // > > // > > // > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson > *Sent:* Saturday, March 07, 2015 8:18 AM > *To:* teas@ietf.org, mpls@ietf.org, robert@raszuk.net > *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang > > Robert, > > From one perspective I agree with you and Igor, however if you think > about MPLS LSPs, from a data plane perspective - and that is where OAM > operates, there almost no difference between a TE-LSP a LDP-LSP and a > SPRING MPLS LSP come very close. > > If you the other hand think of LSPs for other data planes the "nothing > in common" is an almost true statement. From that point of view I think > different models are where we will end up, but I also think that we need > "separation with moderation". > > But nothing is so simple that we can capture it in one very simple > statement, we have hacking away on this for 30 years now, I'd advice > taking architecture and history into consideration, as well as viewing > the sky from a different perspective than from the bottom of a deep well. > > Let me also say that I'm very supportive of all the good work going on > in this area. > > /Loa > > Sent from my iPad > > > On 07 Mar 2015, at 19:47, Robert Raszuk > wrote: > > I would agree with Igor. > > Other then name overlap those are completely different technologies > and artificially putting them under "LSP" umbrella just does not > bring any value, but only confuses things even more. > > Q: What SPRING-LSP has anything in common with "label" when you use > v6 header ? > > If you want to search for some commonalities let's remove LDP-LSPs > from this mix (as the is not relevant) and leave TE-LSP & SPRING + > maybe also add BIER as well as change the name to Generic-EP > (Engineered Paths). > > I see no value of goruping based on the fact that data plane uses > mpls labels, but rather I would see reasonable to provide models > based on the transport path characteristics for the traffic it is to > carry. > > Best, > > r. > > On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin > > wrote: > > Druv, > > IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They > should have totally independent models each being developed in > respective WG. > > Igor > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --20cf304352b6fb453e0510cb90b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Whow .. i think we are discovering that we all have no clue = what Yang model is :)

That is in fact I think great discussion to have sooner then= later.

To me Yang model is a way to represent unified (across inple= mentations) picture of control plane for a given network application.

It has nothing to do with data plane to the extend of avoidi= ng lock-in to mpls or ipv4 or ipv6.

The attempt to generalize LSP would be equivalent to general= ize Routing regardless if this is IGP or BGP or TRILL ... the outcome of th= at would be rather poor I suppose ...

Cheers,
R.

On Mar 8, 2015 7:48 PM, "Gregory Mirsky&quo= t; <gregory.mirsky@ericss= on.com> wrote:

Hi Robert, et. al,=

if I interpret the =E2=80= =9CLSP YANG model=E2=80=9D, then it reads as YANG model of MPLS data plane,= not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of SPRING. And, since the MPLS data plane is indeed common and in fact the one and only, s= uch LSP YANG model rightfully can be characterized as =E2=80=9CGeneric=E2= =80=9D.

But if authors intended t= o describe common set among listed above control protocols pertaining to si= gnaling of an MPLS LSP, then, IMO, such common set first must be discussed and identified to demonstrate that it does exist and is = sufficient to have YANG model of its own rather than YANG models that descr= ibe LSP control by each signaling protocols. That to me looks very much lik= e what LIME WG is working on, investigating whether common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its= extent is sufficient to be of interest.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Teas [ma= ilto:teas-bounce= s@ietf.org] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 3:58 AM
To: Loa Andersson
Cc: mpls@ietf.org= ; teas@ietf.org;= Shah, Himanshu
Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

= Hi Loa,

= =C2=A0

= The way I read Igor statement and agreed with it in a sense of "nothin= g in common" was that it was referring to the control plane.=C2=A0<= /u>

= =C2=A0

= The subject of this thread is "Generic LSP YANG" and to me Yang m= odel describes control aspect of protocol or functionality not the choice o= f forwarding header in the data plane.=C2=A0

= =C2=A0

= So if you and others agree we should be all in sync and perhaps we could co= nsider as proposed before Generic Engineered Path model branching at the lo= wer layer between unicast and multicast.=C2=A0

= =C2=A0

= However if you still think that Yang is about data plane and OAM then perha= ps we have a bigger issue here ....

= =C2=A0

= Cheers,
R.

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrote:

Himanshu, et.al.,

I think there are two issues here and if sorting them out corrrectly
we are very close.

The first issue is similarities between different types of LSPs.

Here I said that, at least for a MPLS PSN, there are similarities,
e.g. the data plane is (nearly) the same. This was said in reaction
to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have noth= ing
in common." I still don't think that Igor's statement is reall= y correct.
If he had said "IMHO there are not enough similarites between TE-LSP,<= br> LDP-LSP and SPRING-LSP to motivate a common model". I think that we be=
a much more accurate statement.

And that is the other issue - Is it reasonable to model TE-LSP,
LDP-LSP and SPRING-LSP in the same model? I don't not think it is,
but that we need an overlap of people working with the different models.
Hope this is clear enough.

/Loa


On 2015-03-07 23:19, Shah, Himanshu wrote:

/I agree with Robert = and Igor, putting everything in the same bucket
because of common data plane & OAM does not justify./

/We wouldn=E2=80=99t consider doing same for IP data plane../

/I think we need to separate these models and as mentioned earlier,
there is already work going on in respective WGs./

//

/Thanks,/

/himanshu/

//

//

//

*From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson
*Sent:* Saturday, March 07, 2015 8:18 AM
*To:* teas@ietf.org,= mpls@ietf.org, r= obert@raszuk.net
*Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang

Robert,

=C2=A0From one perspective I agree with you and Igor, however if you think<= br> about MPLS LSPs, from a data plane perspective - and that is where OAM
operates, there almost no difference between a TE-LSP a LDP-LSP and a
SPRING MPLS LSP come very close.

If you the other hand think of LSPs for other data planes the "nothing=
in common" is an almost true statement. From that point of view I thin= k
different models are where we will end up, but I also think that we need "separation with moderation".

=C2=A0 But nothing is so simple that we can capture it in one very simple statement, we have hacking away on this for 30 years now, I'd advice taking architecture and history into consideration, as well as viewing
the sky from a different perspective than from the bottom of a deep well.
Let me also say that I'm very supportive of all the good work going on<= br> in this area.

/Loa

Sent from my iPad


On 07 Mar 2015, at 19:47, Robert Raszuk <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

=C2=A0 =C2=A0 I would agree with Igor.

=C2=A0 =C2=A0 Other then name overlap those are completely different techno= logies
=C2=A0 =C2=A0 and artificially putting them under "LSP" umbrella = just does not
=C2=A0 =C2=A0 bring any value, but only confuses things even more.

=C2=A0 =C2=A0 Q: What SPRING-LSP has anything in common with "label&qu= ot; when you use
=C2=A0 =C2=A0 v6 header ?

=C2=A0 =C2=A0 If you want to search for some commonalities let's remove= LDP-LSPs
=C2=A0 =C2=A0 from this mix (as the is not relevant) and leave TE-LSP &= SPRING +
=C2=A0 =C2=A0 maybe also add BIER as well as change the name to Generic-EP<= br> =C2=A0 =C2=A0 (Engineered Paths).

=C2=A0 =C2=A0 I see no value of goruping based on the fact that data plane = uses
=C2=A0 =C2=A0 mpls labels, but rather I would see reasonable to provide mod= els
=C2=A0 =C2=A0 based on the transport path characteristics for the traffic i= t is to
=C2=A0 =C2=A0 carry.

=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 r.

=C2=A0 =C2=A0 On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin
=C2=A0 =C2=A0 <IBryskin@advaoptical.com <mailto:IBryskin@advaoptical.com>> wrote:=

=C2=A0 =C2=A0 Druv,

=C2=A0 =C2=A0 IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. T= hey
=C2=A0 =C2=A0 should have totally independent models each being developed i= n
=C2=A0 =C2=A0 respective WG.

=C2=A0 =C2=A0 Igor

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Rtg-yang-coord mailing list
=C2=A0 =C2=A0 = Rtg-yang-coord@ietf.org <mailto:Rtg-yang-coord@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtg-yang-coord



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0

--20cf304352b6fb453e0510cb90b3-- From nobody Sun Mar 8 12:06:27 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EAA1A00F5; Sun, 8 Mar 2015 12:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91XtbsWsjlnY; Sun, 8 Mar 2015 12:06:22 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0811A00F3; Sun, 8 Mar 2015 12:06:21 -0700 (PDT) X-AuditID: c6180641-f796f6d000004ccc-36-54fc3c96941b Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F9.20.19660.69C3CF45; Sun, 8 Mar 2015 13:12:07 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Sun, 8 Mar 2015 15:06:18 -0400 From: Gregory Mirsky To: Robert Raszuk Thread-Topic: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWY7Le4cVv75dNkqZzU3p3HVhN50S6nlAgABKdQD//70fQA== Date: Sun, 8 Mar 2015 19:06:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91C18D@eusaamb103.ericsson.se> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B91C18Deusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPuO50mz8hBje/MVvs2ria0eLf3DnM FreWrmS1aFrYxGzR+mMHiwOrx9mb/1g8liz5yeQxa3obm8fujQuYAliiuGxSUnMyy1KL9O0S uDL+3NnJXPBtHlPFrx2dzA2MW6YzdTFyckgImEi0PfvADmGLSVy4t56ti5GLQ0jgCKPE445p UM4yRokpy96DdbAJGEm82NgD1iEioCrReeIRM0gRs0ALo0TLzZksIAlhARuJc29mMEIU2Urs a37PDGE7SVz+uwyohoODRUBF4vpiT5Awr4CvxMJV09khli1mlfh0ewnYMk6BQInZPVvZQGxG oPO+n1oDFmcWEJe49WQ+1AsCEkv2nGeGsEUlXj7+xwphK0nMeX2NGaI+X+LUy70sEMsEJU7O fMIygVF0FpJRs5CUzUJSNgvoVGYBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZfwMi+ipGjtDi1 LDfdyHATIzAaj0mwOe5gXPDJ8hCjAAejEg+vwe7fIUKsiWXFlbmHGKU5WJTEecuuHAwREkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwLh20/SzNRH3mRTD5HczGjYWX7jb0eahXGkcczO10f7J r7gFLRyrShR/Zai2yHG3LUvxzFzYuYo7P7D3murf15qrlKVmCfn065z7cHTSzIeh8T/qPnJ9 6DI/0s74pfnfmh1c812ERHleCndun3tyW3PIkuWvuB49/XVUOLjjxQHH3KVB0UmJ/UosxRmJ hlrMRcWJAFPgs6OnAgAA Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" , Himanshu Shah , Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:06:25 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B91C18Deusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KZWFybHkgaW4gTVBMUywgSSB0aGluaywgd2UgYWxsIHBsYXllZCB3aXRoIHdo YXTigJlzIGNhbGxlZCBTdGF0aWMgTFNQLiBMYXRlciB0aGV5IGNhbWUgYmFjayBhcyBMU1AgaW4g TVBMUy1UUCB3aXRob3V0IGEgY29udHJvbCBwbGFuZS4gVG8gbWUgdGhhdCBpcyBob3cgb25lIHNl dHMgdGhlIE1QTFMgZGF0YSBwbGFuZSB3aXRob3V0IGFueSBjb250cm9sIHByb3RvY29sIGJ1dCBj b25maWd1cmluZyBjcm9zcy1jb25uZWN0cyBMU1IgYnkgTFNSLg0KDQogICAgICAgICAgICAgICAg UmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBy cmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2Yg Um9iZXJ0IFJhc3p1aw0KU2VudDogU3VuZGF5LCBNYXJjaCAwOCwgMjAxNSAxMjowMyBQTQ0KVG86 IEdyZWdvcnkgTWlyc2t5DQpDYzogSGltYW5zaHUgU2hhaDsgdGVhc0BpZXRmLm9yZzsgTG9hIEFu ZGVyc3NvbjsgbXBsc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtUZWFzXSBbbXBsc10gW1J0Zy15 YW5nLWNvb3JkXSBHZW5lcmljIExTUCBZYW5nDQoNCg0KV2hvdyAuLiBpIHRoaW5rIHdlIGFyZSBk aXNjb3ZlcmluZyB0aGF0IHdlIGFsbCBoYXZlIG5vIGNsdWUgd2hhdCBZYW5nIG1vZGVsIGlzIDop DQoNClRoYXQgaXMgaW4gZmFjdCBJIHRoaW5rIGdyZWF0IGRpc2N1c3Npb24gdG8gaGF2ZSBzb29u ZXIgdGhlbiBsYXRlci4NCg0KVG8gbWUgWWFuZyBtb2RlbCBpcyBhIHdheSB0byByZXByZXNlbnQg dW5pZmllZCAoYWNyb3NzIGlucGxlbWVudGF0aW9ucykgcGljdHVyZSBvZiBjb250cm9sIHBsYW5l IGZvciBhIGdpdmVuIG5ldHdvcmsgYXBwbGljYXRpb24uDQoNCkl0IGhhcyBub3RoaW5nIHRvIGRv IHdpdGggZGF0YSBwbGFuZSB0byB0aGUgZXh0ZW5kIG9mIGF2b2lkaW5nIGxvY2staW4gdG8gbXBs cyBvciBpcHY0IG9yIGlwdjYuDQoNClRoZSBhdHRlbXB0IHRvIGdlbmVyYWxpemUgTFNQIHdvdWxk IGJlIGVxdWl2YWxlbnQgdG8gZ2VuZXJhbGl6ZSBSb3V0aW5nIHJlZ2FyZGxlc3MgaWYgdGhpcyBp cyBJR1Agb3IgQkdQIG9yIFRSSUxMIC4uLiB0aGUgb3V0Y29tZSBvZiB0aGF0IHdvdWxkIGJlIHJh dGhlciBwb29yIEkgc3VwcG9zZSAuLi4NCg0KQ2hlZXJzLA0KUi4NCk9uIE1hciA4LCAyMDE1IDc6 NDggUE0sICJHcmVnb3J5IE1pcnNreSIgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWls dG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBSb2JlcnQsIGV0LiBh bCwNCmlmIEkgaW50ZXJwcmV0IHRoZSDigJxMU1AgWUFORyBtb2RlbOKAnSwgdGhlbiBpdCByZWFk cyBhcyBZQU5HIG1vZGVsIG9mIE1QTFMgZGF0YSBwbGFuZSwgbm90IGNvbnRyb2wgcHJvdG9jb2ws IGJlIGl0IFJTVlAtVEUsIExEUCwgUENFUCwgb3IgSUdQLVRFIG9mIFNQUklORy4gQW5kLCBzaW5j ZSB0aGUgTVBMUyBkYXRhIHBsYW5lIGlzIGluZGVlZCBjb21tb24gYW5kIGluIGZhY3QgdGhlIG9u ZSBhbmQgb25seSwgc3VjaCBMU1AgWUFORyBtb2RlbCByaWdodGZ1bGx5IGNhbiBiZSBjaGFyYWN0 ZXJpemVkIGFzIOKAnEdlbmVyaWPigJ0uDQpCdXQgaWYgYXV0aG9ycyBpbnRlbmRlZCB0byBkZXNj cmliZSBjb21tb24gc2V0IGFtb25nIGxpc3RlZCBhYm92ZSBjb250cm9sIHByb3RvY29scyBwZXJ0 YWluaW5nIHRvIHNpZ25hbGluZyBvZiBhbiBNUExTIExTUCwgdGhlbiwgSU1PLCBzdWNoIGNvbW1v biBzZXQgZmlyc3QgbXVzdCBiZSBkaXNjdXNzZWQgYW5kIGlkZW50aWZpZWQgdG8gZGVtb25zdHJh dGUgdGhhdCBpdCBkb2VzIGV4aXN0IGFuZCBpcyBzdWZmaWNpZW50IHRvIGhhdmUgWUFORyBtb2Rl bCBvZiBpdHMgb3duIHJhdGhlciB0aGFuIFlBTkcgbW9kZWxzIHRoYXQgZGVzY3JpYmUgTFNQIGNv bnRyb2wgYnkgZWFjaCBzaWduYWxpbmcgcHJvdG9jb2xzLiBUaGF0IHRvIG1lIGxvb2tzIHZlcnkg bXVjaCBsaWtlIHdoYXQgTElNRSBXRyBpcyB3b3JraW5nIG9uLCBpbnZlc3RpZ2F0aW5nIHdoZXRo ZXIgY29tbW9uIG1vZGVsIG9mIElQLCBJUC9NUExTLCBNUExTLVRQLCBhbmQgVFJJTEwgT0FNIGV4 aXN0cyBhbmQgaXRzIGV4dGVudCBpcyBzdWZmaWNpZW50IHRvIGJlIG9mIGludGVyZXN0Lg0KDQog ICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg R3JlZw0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0 ZWFzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDog U3VuZGF5LCBNYXJjaCAwOCwgMjAxNSAzOjU4IEFNDQpUbzogTG9hIEFuZGVyc3Nvbg0KQ2M6IG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyB0ZWFzQGlldGYub3JnPG1haWx0bzp0 ZWFzQGlldGYub3JnPjsgU2hhaCwgSGltYW5zaHUNClN1YmplY3Q6IFJlOiBbVGVhc10gW21wbHNd IFtSdGcteWFuZy1jb29yZF0gR2VuZXJpYyBMU1AgWWFuZw0KDQpIaSBMb2EsDQoNClRoZSB3YXkg SSByZWFkIElnb3Igc3RhdGVtZW50IGFuZCBhZ3JlZWQgd2l0aCBpdCBpbiBhIHNlbnNlIG9mICJu b3RoaW5nIGluIGNvbW1vbiIgd2FzIHRoYXQgaXQgd2FzIHJlZmVycmluZyB0byB0aGUgY29udHJv bCBwbGFuZS4NCg0KVGhlIHN1YmplY3Qgb2YgdGhpcyB0aHJlYWQgaXMgIkdlbmVyaWMgTFNQIFlB TkciIGFuZCB0byBtZSBZYW5nIG1vZGVsIGRlc2NyaWJlcyBjb250cm9sIGFzcGVjdCBvZiBwcm90 b2NvbCBvciBmdW5jdGlvbmFsaXR5IG5vdCB0aGUgY2hvaWNlIG9mIGZvcndhcmRpbmcgaGVhZGVy IGluIHRoZSBkYXRhIHBsYW5lLg0KDQpTbyBpZiB5b3UgYW5kIG90aGVycyBhZ3JlZSB3ZSBzaG91 bGQgYmUgYWxsIGluIHN5bmMgYW5kIHBlcmhhcHMgd2UgY291bGQgY29uc2lkZXIgYXMgcHJvcG9z ZWQgYmVmb3JlIEdlbmVyaWMgRW5naW5lZXJlZCBQYXRoIG1vZGVsIGJyYW5jaGluZyBhdCB0aGUg bG93ZXIgbGF5ZXIgYmV0d2VlbiB1bmljYXN0IGFuZCBtdWx0aWNhc3QuDQoNCkhvd2V2ZXIgaWYg eW91IHN0aWxsIHRoaW5rIHRoYXQgWWFuZyBpcyBhYm91dCBkYXRhIHBsYW5lIGFuZCBPQU0gdGhl biBwZXJoYXBzIHdlIGhhdmUgYSBiaWdnZXIgaXNzdWUgaGVyZSAuLi4uDQoNCkNoZWVycywNClIu DQoNCg0KDQoNCk9uIFN1biwgTWFyIDgsIDIwMTUgYXQgMTA6MjcgQU0sIExvYSBBbmRlcnNzb24g PGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQpIaW1hbnNodSwgZXQuYWw8aHR0 cDovL2V0LmFsPi4sDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHR3byBpc3N1ZXMgaGVyZSBhbmQgaWYg c29ydGluZyB0aGVtIG91dCBjb3JycmVjdGx5DQp3ZSBhcmUgdmVyeSBjbG9zZS4NCg0KVGhlIGZp cnN0IGlzc3VlIGlzIHNpbWlsYXJpdGllcyBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZiBMU1Bz Lg0KDQpIZXJlIEkgc2FpZCB0aGF0LCBhdCBsZWFzdCBmb3IgYSBNUExTIFBTTiwgdGhlcmUgYXJl IHNpbWlsYXJpdGllcywNCmUuZy4gdGhlIGRhdGEgcGxhbmUgaXMgKG5lYXJseSkgdGhlIHNhbWUu IFRoaXMgd2FzIHNhaWQgaW4gcmVhY3Rpb24NCnRvIElnb3IncyBzdGF0ZW1lbnQgIklNSE8gVEUt TFNQLCBMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZw0KaW4gY29tbW9uLiIgSSBz dGlsbCBkb24ndCB0aGluayB0aGF0IElnb3IncyBzdGF0ZW1lbnQgaXMgcmVhbGx5IGNvcnJlY3Qu DQpJZiBoZSBoYWQgc2FpZCAiSU1ITyB0aGVyZSBhcmUgbm90IGVub3VnaCBzaW1pbGFyaXRlcyBi ZXR3ZWVuIFRFLUxTUCwNCkxEUC1MU1AgYW5kIFNQUklORy1MU1AgdG8gbW90aXZhdGUgYSBjb21t b24gbW9kZWwiLiBJIHRoaW5rIHRoYXQgd2UgYmUNCmEgbXVjaCBtb3JlIGFjY3VyYXRlIHN0YXRl bWVudC4NCg0KQW5kIHRoYXQgaXMgdGhlIG90aGVyIGlzc3VlIC0gSXMgaXQgcmVhc29uYWJsZSB0 byBtb2RlbCBURS1MU1AsDQpMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGluIHRoZSBzYW1lIG1vZGVs PyBJIGRvbid0IG5vdCB0aGluayBpdCBpcywNCmJ1dCB0aGF0IHdlIG5lZWQgYW4gb3ZlcmxhcCBv ZiBwZW9wbGUgd29ya2luZyB3aXRoIHRoZSBkaWZmZXJlbnQgbW9kZWxzLg0KDQpIb3BlIHRoaXMg aXMgY2xlYXIgZW5vdWdoLg0KDQovTG9hDQoNCg0KT24gMjAxNS0wMy0wNyAyMzoxOSwgU2hhaCwg SGltYW5zaHUgd3JvdGU6DQovSSBhZ3JlZSB3aXRoIFJvYmVydCBhbmQgSWdvciwgcHV0dGluZyBl dmVyeXRoaW5nIGluIHRoZSBzYW1lIGJ1Y2tldA0KYmVjYXVzZSBvZiBjb21tb24gZGF0YSBwbGFu ZSAmIE9BTSBkb2VzIG5vdCBqdXN0aWZ5Li8NCg0KL1dlIHdvdWxkbuKAmXQgY29uc2lkZXIgZG9p bmcgc2FtZSBmb3IgSVAgZGF0YSBwbGFuZS4uLw0KDQovSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFy YXRlIHRoZXNlIG1vZGVscyBhbmQgYXMgbWVudGlvbmVkIGVhcmxpZXIsDQp0aGVyZSBpcyBhbHJl YWR5IHdvcmsgZ29pbmcgb24gaW4gcmVzcGVjdGl2ZSBXR3MuLw0KDQovLw0KDQovVGhhbmtzLC8N Cg0KL2hpbWFuc2h1Lw0KDQovLw0KDQovLw0KDQovLw0KDQoqRnJvbToqbXBscyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJl aGFsZiBPZiAqTG9hIEFuZGVyc3Nvbg0KKlNlbnQ6KiBTYXR1cmRheSwgTWFyY2ggMDcsIDIwMTUg ODoxOCBBTQ0KKlRvOiogdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4sIG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+LCByb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86 cm9iZXJ0QHJhc3p1ay5uZXQ+DQoqU3ViamVjdDoqIFJlOiBbbXBsc10gW1J0Zy15YW5nLWNvb3Jk XSBbVGVhc10gR2VuZXJpYyBMU1AgWWFuZw0KDQpSb2JlcnQsDQoNCiBGcm9tIG9uZSBwZXJzcGVj dGl2ZSBJIGFncmVlIHdpdGggeW91IGFuZCBJZ29yLCBob3dldmVyIGlmIHlvdSB0aGluaw0KYWJv dXQgTVBMUyBMU1BzLCBmcm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSAtIGFuZCB0aGF0IGlz IHdoZXJlIE9BTQ0Kb3BlcmF0ZXMsIHRoZXJlIGFsbW9zdCBubyBkaWZmZXJlbmNlIGJldHdlZW4g YSBURS1MU1AgYSBMRFAtTFNQIGFuZCBhDQpTUFJJTkcgTVBMUyBMU1AgY29tZSB2ZXJ5IGNsb3Nl Lg0KDQpJZiB5b3UgdGhlIG90aGVyIGhhbmQgdGhpbmsgb2YgTFNQcyBmb3Igb3RoZXIgZGF0YSBw bGFuZXMgdGhlICJub3RoaW5nDQppbiBjb21tb24iIGlzIGFuIGFsbW9zdCB0cnVlIHN0YXRlbWVu dC4gRnJvbSB0aGF0IHBvaW50IG9mIHZpZXcgSSB0aGluaw0KZGlmZmVyZW50IG1vZGVscyBhcmUg d2hlcmUgd2Ugd2lsbCBlbmQgdXAsIGJ1dCBJIGFsc28gdGhpbmsgdGhhdCB3ZSBuZWVkDQoic2Vw YXJhdGlvbiB3aXRoIG1vZGVyYXRpb24iLg0KDQogIEJ1dCBub3RoaW5nIGlzIHNvIHNpbXBsZSB0 aGF0IHdlIGNhbiBjYXB0dXJlIGl0IGluIG9uZSB2ZXJ5IHNpbXBsZQ0Kc3RhdGVtZW50LCB3ZSBo YXZlIGhhY2tpbmcgYXdheSBvbiB0aGlzIGZvciAzMCB5ZWFycyBub3csIEknZCBhZHZpY2UNCnRh a2luZyBhcmNoaXRlY3R1cmUgYW5kIGhpc3RvcnkgaW50byBjb25zaWRlcmF0aW9uLCBhcyB3ZWxs IGFzIHZpZXdpbmcNCnRoZSBza3kgZnJvbSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSB0aGFuIGZy b20gdGhlIGJvdHRvbSBvZiBhIGRlZXAgd2VsbC4NCg0KTGV0IG1lIGFsc28gc2F5IHRoYXQgSSdt IHZlcnkgc3VwcG9ydGl2ZSBvZiBhbGwgdGhlIGdvb2Qgd29yayBnb2luZyBvbg0KaW4gdGhpcyBh cmVhLg0KDQovTG9hDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCg0KT24gMDcgTWFyIDIwMTUsIGF0 IDE5OjQ3LCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJh c3p1ay5uZXQ+DQo8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldD4+PiB3cm90ZToNCg0KICAgIEkgd291bGQgYWdyZWUgd2l0aCBJZ29yLg0KDQogICAgT3Ro ZXIgdGhlbiBuYW1lIG92ZXJsYXAgdGhvc2UgYXJlIGNvbXBsZXRlbHkgZGlmZmVyZW50IHRlY2hu b2xvZ2llcw0KICAgIGFuZCBhcnRpZmljaWFsbHkgcHV0dGluZyB0aGVtIHVuZGVyICJMU1AiIHVt YnJlbGxhIGp1c3QgZG9lcyBub3QNCiAgICBicmluZyBhbnkgdmFsdWUsIGJ1dCBvbmx5IGNvbmZ1 c2VzIHRoaW5ncyBldmVuIG1vcmUuDQoNCiAgICBROiBXaGF0IFNQUklORy1MU1AgaGFzIGFueXRo aW5nIGluIGNvbW1vbiB3aXRoICJsYWJlbCIgd2hlbiB5b3UgdXNlDQogICAgdjYgaGVhZGVyID8N Cg0KICAgIElmIHlvdSB3YW50IHRvIHNlYXJjaCBmb3Igc29tZSBjb21tb25hbGl0aWVzIGxldCdz IHJlbW92ZSBMRFAtTFNQcw0KICAgIGZyb20gdGhpcyBtaXggKGFzIHRoZSBpcyBub3QgcmVsZXZh bnQpIGFuZCBsZWF2ZSBURS1MU1AgJiBTUFJJTkcgKw0KICAgIG1heWJlIGFsc28gYWRkIEJJRVIg YXMgd2VsbCBhcyBjaGFuZ2UgdGhlIG5hbWUgdG8gR2VuZXJpYy1FUA0KICAgIChFbmdpbmVlcmVk IFBhdGhzKS4NCg0KICAgIEkgc2VlIG5vIHZhbHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRoZSBm YWN0IHRoYXQgZGF0YSBwbGFuZSB1c2VzDQogICAgbXBscyBsYWJlbHMsIGJ1dCByYXRoZXIgSSB3 b3VsZCBzZWUgcmVhc29uYWJsZSB0byBwcm92aWRlIG1vZGVscw0KICAgIGJhc2VkIG9uIHRoZSB0 cmFuc3BvcnQgcGF0aCBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSB0cmFmZmljIGl0IGlzIHRvDQog ICAgY2FycnkuDQoNCiAgICBCZXN0LA0KDQogICAgci4NCg0KICAgIE9uIEZyaSwgTWFyIDYsIDIw MTUgYXQgMjoxMSBQTSwgSWdvciBCcnlza2luDQogICAgPElCcnlza2luQGFkdmFvcHRpY2FsLmNv bTxtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPiA8bWFpbHRvOklCcnlza2luQGFkdmFv cHRpY2FsLmNvbTxtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPj4+IHdyb3RlOg0KDQog ICAgRHJ1diwNCg0KICAgIElNSE8gVEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGhhdmUg bm90aGluZyBpbiBjb21tb24uIFRoZXkNCiAgICBzaG91bGQgaGF2ZSB0b3RhbGx5IGluZGVwZW5k ZW50IG1vZGVscyBlYWNoIGJlaW5nIGRldmVsb3BlZCBpbg0KICAgIHJlc3BlY3RpdmUgV0cuDQoN CiAgICBJZ29yDQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgIFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KICAgIFJ0Zy15YW5nLWNv b3JkQGlldGYub3JnPG1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZz4gPG1haWx0bzpSdGct eWFuZy1jb29yZEBpZXRmLm9yZzxtYWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc+Pg0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFz IG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KDQotLQ0KDQoNCkxvYSBBbmRl cnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29t PG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAg ICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRl Y2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDol MkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCg0K --_000_7347100B5761DC41A166AC17F22DF1121B91C18Deusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ZWFy bHkgaW4gTVBMUywgSSB0aGluaywgd2UgYWxsIHBsYXllZCB3aXRoIHdoYXTigJlzIGNhbGxlZCBT dGF0aWMgTFNQLiBMYXRlciB0aGV5IGNhbWUgYmFjayBhcyBMU1AgaW4gTVBMUy1UUCB3aXRob3V0 IGEgY29udHJvbCBwbGFuZS4gVG8gbWUgdGhhdCBpcyBob3cgb25lIHNldHMNCiB0aGUgTVBMUyBk YXRhIHBsYW5lIHdpdGhvdXQgYW55IGNvbnRyb2wgcHJvdG9jb2wgYnV0IGNvbmZpZ3VyaW5nIGNy b3NzLWNvbm5lY3RzIExTUiBieSBMU1IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAw OCwgMjAxNSAxMjowMyBQTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5D Yzo8L2I+IEhpbWFuc2h1IFNoYWg7IHRlYXNAaWV0Zi5vcmc7IExvYSBBbmRlcnNzb247IG1wbHNA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtUZWFzXSBbbXBsc10gW1J0Zy15YW5n LWNvb3JkXSBHZW5lcmljIExTUCBZYW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5XaG93IC4uIGkgdGhpbmsgd2Ug YXJlIGRpc2NvdmVyaW5nIHRoYXQgd2UgYWxsIGhhdmUgbm8gY2x1ZSB3aGF0IFlhbmcgbW9kZWwg aXMgOik8bzpwPjwvbzpwPjwvcD4NCjxwPlRoYXQgaXMgaW4gZmFjdCBJIHRoaW5rIGdyZWF0IGRp c2N1c3Npb24gdG8gaGF2ZSBzb29uZXIgdGhlbiBsYXRlci48bzpwPjwvbzpwPjwvcD4NCjxwPlRv IG1lIFlhbmcgbW9kZWwgaXMgYSB3YXkgdG8gcmVwcmVzZW50IHVuaWZpZWQgKGFjcm9zcyBpbnBs ZW1lbnRhdGlvbnMpIHBpY3R1cmUgb2YgY29udHJvbCBwbGFuZSBmb3IgYSBnaXZlbiBuZXR3b3Jr IGFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+SXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0 aCBkYXRhIHBsYW5lIHRvIHRoZSBleHRlbmQgb2YgYXZvaWRpbmcgbG9jay1pbiB0byBtcGxzIG9y IGlwdjQgb3IgaXB2Ni48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBhdHRlbXB0IHRvIGdlbmVyYWxp emUgTFNQIHdvdWxkIGJlIGVxdWl2YWxlbnQgdG8gZ2VuZXJhbGl6ZSBSb3V0aW5nIHJlZ2FyZGxl c3MgaWYgdGhpcyBpcyBJR1Agb3IgQkdQIG9yIFRSSUxMIC4uLiB0aGUgb3V0Y29tZSBvZiB0aGF0 IHdvdWxkIGJlIHJhdGhlciBwb29yIEkgc3VwcG9zZSAuLi48bzpwPjwvbzpwPjwvcD4NCjxwPkNo ZWVycyw8YnI+DQpSLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1hciA4LCAyMDE1IDc6NDggUE0sICZxdW90O0dyZWdvcnkgTWlyc2t5JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tIj5ncmVnb3J5Lm1pcnNr eUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGkgUm9iZXJ0LCBldC4gYWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+aWYgSSBpbnRlcnByZXQgdGhlIOKAnExTUCBZQU5HIG1vZGVs4oCdLCB0aGVuIGl0IHJl YWRzIGFzIFlBTkcgbW9kZWwgb2YgTVBMUyBkYXRhIHBsYW5lLCBub3QgY29udHJvbA0KIHByb3Rv Y29sLCBiZSBpdCBSU1ZQLVRFLCBMRFAsIFBDRVAsIG9yIElHUC1URSBvZiBTUFJJTkcuIEFuZCwg c2luY2UgdGhlIE1QTFMgZGF0YSBwbGFuZSBpcyBpbmRlZWQgY29tbW9uIGFuZCBpbiBmYWN0IHRo ZSBvbmUgYW5kIG9ubHksIHN1Y2ggTFNQIFlBTkcgbW9kZWwgcmlnaHRmdWxseSBjYW4gYmUgY2hh cmFjdGVyaXplZCBhcyDigJxHZW5lcmlj4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkJ1dCBpZiBhdXRob3JzIGludGVuZGVkIHRvIGRlc2NyaWJlIGNvbW1vbiBzZXQgYW1vbmcg bGlzdGVkIGFib3ZlIGNvbnRyb2wgcHJvdG9jb2xzIHBlcnRhaW5pbmcgdG8NCiBzaWduYWxpbmcg b2YgYW4gTVBMUyBMU1AsIHRoZW4sIElNTywgc3VjaCBjb21tb24gc2V0IGZpcnN0IG11c3QgYmUg ZGlzY3Vzc2VkIGFuZCBpZGVudGlmaWVkIHRvIGRlbW9uc3RyYXRlIHRoYXQgaXQgZG9lcyBleGlz dCBhbmQgaXMgc3VmZmljaWVudCB0byBoYXZlIFlBTkcgbW9kZWwgb2YgaXRzIG93biByYXRoZXIg dGhhbiBZQU5HIG1vZGVscyB0aGF0IGRlc2NyaWJlIExTUCBjb250cm9sIGJ5IGVhY2ggc2lnbmFs aW5nIHByb3RvY29scy4gVGhhdA0KIHRvIG1lIGxvb2tzIHZlcnkgbXVjaCBsaWtlIHdoYXQgTElN RSBXRyBpcyB3b3JraW5nIG9uLCBpbnZlc3RpZ2F0aW5nIHdoZXRoZXIgY29tbW9uIG1vZGVsIG9m IElQLCBJUC9NUExTLCBNUExTLVRQLCBhbmQgVFJJTEwgT0FNIGV4aXN0cyBhbmQgaXRzIGV4dGVu dCBpcyBzdWZmaWNpZW50IHRvIGJlIG9mIGludGVyZXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0ZWFzLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFN1 bmRheSwgTWFyY2ggMDgsIDIwMTUgMzo1OCBBTTxicj4NCjxiPlRvOjwvYj4gTG9hIEFuZGVyc3Nv bjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCnRlYXNAaWV0Zi5vcmc8L2E+OyBTaGFoLCBIaW1hbnNodTxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNdIFttcGxzXSBbUnRnLXlhbmctY29vcmRdIEdlbmVy aWMgTFNQIFlhbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkg TG9hLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+VGhlIHdheSBJIHJlYWQgSWdvciBzdGF0ZW1lbnQgYW5kIGFncmVlZCB3aXRoIGl0IGlu IGEgc2Vuc2Ugb2YgJnF1b3Q7bm90aGluZyBpbiBjb21tb24mcXVvdDsgd2FzIHRoYXQgaXQgd2Fz IHJlZmVycmluZyB0byB0aGUgY29udHJvbCBwbGFuZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBzdWJqZWN0IG9mIHRo aXMgdGhyZWFkIGlzICZxdW90O0dlbmVyaWMgTFNQIFlBTkcmcXVvdDsgYW5kIHRvIG1lIFlhbmcg bW9kZWwgZGVzY3JpYmVzIGNvbnRyb2wgYXNwZWN0IG9mIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxp dHkgbm90IHRoZSBjaG9pY2UNCiBvZiBmb3J3YXJkaW5nIGhlYWRlciBpbiB0aGUgZGF0YSBwbGFu ZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlNvIGlmIHlvdSBhbmQgb3RoZXJzIGFncmVlIHdlIHNob3VsZCBiZSBhbGwgaW4g c3luYyBhbmQgcGVyaGFwcyB3ZSBjb3VsZCBjb25zaWRlciBhcyBwcm9wb3NlZCBiZWZvcmUgR2Vu ZXJpYyBFbmdpbmVlcmVkIFBhdGggbW9kZWwgYnJhbmNoaW5nDQogYXQgdGhlIGxvd2VyIGxheWVy IGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG93ZXZlciBpZiB5b3Ugc3Rp bGwgdGhpbmsgdGhhdCBZYW5nIGlzIGFib3V0IGRhdGEgcGxhbmUgYW5kIE9BTSB0aGVuIHBlcmhh cHMgd2UgaGF2ZSBhIGJpZ2dlciBpc3N1ZSBoZXJlIC4uLi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVycyw8YnI+DQpSLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIFN1biwgTWFyIDgsIDIwMTUgYXQgMTA6MjcgQU0sIExvYSBBbmRl cnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FA cGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SGltYW5zaHUsDQo8YSBocmVmPSJodHRwOi8vZXQuYWwiIHRhcmdldD0iX2JsYW5rIj5ldC5h bDwvYT4uLDxicj4NCjxicj4NCkkgdGhpbmsgdGhlcmUgYXJlIHR3byBpc3N1ZXMgaGVyZSBhbmQg aWYgc29ydGluZyB0aGVtIG91dCBjb3JycmVjdGx5PGJyPg0Kd2UgYXJlIHZlcnkgY2xvc2UuPGJy Pg0KPGJyPg0KVGhlIGZpcnN0IGlzc3VlIGlzIHNpbWlsYXJpdGllcyBiZXR3ZWVuIGRpZmZlcmVu dCB0eXBlcyBvZiBMU1BzLjxicj4NCjxicj4NCkhlcmUgSSBzYWlkIHRoYXQsIGF0IGxlYXN0IGZv ciBhIE1QTFMgUFNOLCB0aGVyZSBhcmUgc2ltaWxhcml0aWVzLDxicj4NCmUuZy4gdGhlIGRhdGEg cGxhbmUgaXMgKG5lYXJseSkgdGhlIHNhbWUuIFRoaXMgd2FzIHNhaWQgaW4gcmVhY3Rpb248YnI+ DQp0byBJZ29yJ3Mgc3RhdGVtZW50ICZxdW90O0lNSE8gVEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJ TkctTFNQIGhhdmUgbm90aGluZzxicj4NCmluIGNvbW1vbi4mcXVvdDsgSSBzdGlsbCBkb24ndCB0 aGluayB0aGF0IElnb3IncyBzdGF0ZW1lbnQgaXMgcmVhbGx5IGNvcnJlY3QuPGJyPg0KSWYgaGUg aGFkIHNhaWQgJnF1b3Q7SU1ITyB0aGVyZSBhcmUgbm90IGVub3VnaCBzaW1pbGFyaXRlcyBiZXR3 ZWVuIFRFLUxTUCw8YnI+DQpMRFAtTFNQIGFuZCBTUFJJTkctTFNQIHRvIG1vdGl2YXRlIGEgY29t bW9uIG1vZGVsJnF1b3Q7LiBJIHRoaW5rIHRoYXQgd2UgYmU8YnI+DQphIG11Y2ggbW9yZSBhY2N1 cmF0ZSBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KQW5kIHRoYXQgaXMgdGhlIG90aGVyIGlzc3VlIC0g SXMgaXQgcmVhc29uYWJsZSB0byBtb2RlbCBURS1MU1AsPGJyPg0KTERQLUxTUCBhbmQgU1BSSU5H LUxTUCBpbiB0aGUgc2FtZSBtb2RlbD8gSSBkb24ndCBub3QgdGhpbmsgaXQgaXMsPGJyPg0KYnV0 IHRoYXQgd2UgbmVlZCBhbiBvdmVybGFwIG9mIHBlb3BsZSB3b3JraW5nIHdpdGggdGhlIGRpZmZl cmVudCBtb2RlbHMuPGJyPg0KPGJyPg0KSG9wZSB0aGlzIGlzIGNsZWFyIGVub3VnaC48YnI+DQo8 YnI+DQovTG9hPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxNS0wMy0wNyAyMzoxOSwgU2hhaCwgSGlt YW5zaHUgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPi9JIGFncmVlIHdp dGggUm9iZXJ0IGFuZCBJZ29yLCBwdXR0aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHNhbWUgYnVja2V0 PGJyPg0KYmVjYXVzZSBvZiBjb21tb24gZGF0YSBwbGFuZSAmYW1wOyBPQU0gZG9lcyBub3QganVz dGlmeS4vPGJyPg0KPGJyPg0KL1dlIHdvdWxkbuKAmXQgY29uc2lkZXIgZG9pbmcgc2FtZSBmb3Ig SVAgZGF0YSBwbGFuZS4uLzxicj4NCjxicj4NCi9JIHRoaW5rIHdlIG5lZWQgdG8gc2VwYXJhdGUg dGhlc2UgbW9kZWxzIGFuZCBhcyBtZW50aW9uZWQgZWFybGllciw8YnI+DQp0aGVyZSBpcyBhbHJl YWR5IHdvcmsgZ29pbmcgb24gaW4gcmVzcGVjdGl2ZSBXR3MuLzxicj4NCjxicj4NCi8vPGJyPg0K PGJyPg0KL1RoYW5rcywvPGJyPg0KPGJyPg0KL2hpbWFuc2h1Lzxicj4NCjxicj4NCi8vPGJyPg0K PGJyPg0KLy88YnI+DQo8YnI+DQovLzxicj4NCjxicj4NCipGcm9tOiptcGxzIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2YgKkxvYSBBbmRlcnNzb248YnI+DQoq U2VudDoqIFNhdHVyZGF5LCBNYXJjaCAwNywgMjAxNSA4OjE4IEFNPGJyPg0KKlRvOiogPGEgaHJl Zj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzQGlldGYub3JnPC9h PiwgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm1wbHNA aWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0i X2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT48YnI+DQoqU3ViamVjdDoqIFJlOiBbbXBsc10g W1J0Zy15YW5nLWNvb3JkXSBbVGVhc10gR2VuZXJpYyBMU1AgWWFuZzxicj4NCjxicj4NClJvYmVy dCw8YnI+DQo8YnI+DQombmJzcDtGcm9tIG9uZSBwZXJzcGVjdGl2ZSBJIGFncmVlIHdpdGggeW91 IGFuZCBJZ29yLCBob3dldmVyIGlmIHlvdSB0aGluazxicj4NCmFib3V0IE1QTFMgTFNQcywgZnJv bSBhIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUgLSBhbmQgdGhhdCBpcyB3aGVyZSBPQU08YnI+DQpv cGVyYXRlcywgdGhlcmUgYWxtb3N0IG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIFRFLUxTUCBhIExE UC1MU1AgYW5kIGE8YnI+DQpTUFJJTkcgTVBMUyBMU1AgY29tZSB2ZXJ5IGNsb3NlLjxicj4NCjxi cj4NCklmIHlvdSB0aGUgb3RoZXIgaGFuZCB0aGluayBvZiBMU1BzIGZvciBvdGhlciBkYXRhIHBs YW5lcyB0aGUgJnF1b3Q7bm90aGluZzxicj4NCmluIGNvbW1vbiZxdW90OyBpcyBhbiBhbG1vc3Qg dHJ1ZSBzdGF0ZW1lbnQuIEZyb20gdGhhdCBwb2ludCBvZiB2aWV3IEkgdGhpbms8YnI+DQpkaWZm ZXJlbnQgbW9kZWxzIGFyZSB3aGVyZSB3ZSB3aWxsIGVuZCB1cCwgYnV0IEkgYWxzbyB0aGluayB0 aGF0IHdlIG5lZWQ8YnI+DQomcXVvdDtzZXBhcmF0aW9uIHdpdGggbW9kZXJhdGlvbiZxdW90Oy48 YnI+DQo8YnI+DQombmJzcDsgQnV0IG5vdGhpbmcgaXMgc28gc2ltcGxlIHRoYXQgd2UgY2FuIGNh cHR1cmUgaXQgaW4gb25lIHZlcnkgc2ltcGxlPGJyPg0Kc3RhdGVtZW50LCB3ZSBoYXZlIGhhY2tp bmcgYXdheSBvbiB0aGlzIGZvciAzMCB5ZWFycyBub3csIEknZCBhZHZpY2U8YnI+DQp0YWtpbmcg YXJjaGl0ZWN0dXJlIGFuZCBoaXN0b3J5IGludG8gY29uc2lkZXJhdGlvbiwgYXMgd2VsbCBhcyB2 aWV3aW5nPGJyPg0KdGhlIHNreSBmcm9tIGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIHRoYW4gZnJv bSB0aGUgYm90dG9tIG9mIGEgZGVlcCB3ZWxsLjxicj4NCjxicj4NCkxldCBtZSBhbHNvIHNheSB0 aGF0IEknbSB2ZXJ5IHN1cHBvcnRpdmUgb2YgYWxsIHRoZSBnb29kIHdvcmsgZ29pbmcgb248YnI+ DQppbiB0aGlzIGFyZWEuPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NClNlbnQgZnJvbSBteSBp UGFkPGJyPg0KPGJyPg0KPGJyPg0KT24gMDcgTWFyIDIwMTUsIGF0IDE5OjQ3LCBSb2JlcnQgUmFz enVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5r Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT48YnI+DQombHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpy b2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0PC9hPiZn dDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSB3b3VsZCBhZ3JlZSB3aXRo IElnb3IuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPdGhlciB0aGVuIG5hbWUgb3ZlcmxhcCB0 aG9zZSBhcmUgY29tcGxldGVseSBkaWZmZXJlbnQgdGVjaG5vbG9naWVzPGJyPg0KJm5ic3A7ICZu YnNwOyBhbmQgYXJ0aWZpY2lhbGx5IHB1dHRpbmcgdGhlbSB1bmRlciAmcXVvdDtMU1AmcXVvdDsg dW1icmVsbGEganVzdCBkb2VzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgYnJpbmcgYW55IHZhbHVl LCBidXQgb25seSBjb25mdXNlcyB0aGluZ3MgZXZlbiBtb3JlLjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgUTogV2hhdCBTUFJJTkctTFNQIGhhcyBhbnl0aGluZyBpbiBjb21tb24gd2l0aCAmcXVv dDtsYWJlbCZxdW90OyB3aGVuIHlvdSB1c2U8YnI+DQombmJzcDsgJm5ic3A7IHY2IGhlYWRlciA/ PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJZiB5b3Ugd2FudCB0byBzZWFyY2ggZm9yIHNvbWUg Y29tbW9uYWxpdGllcyBsZXQncyByZW1vdmUgTERQLUxTUHM8YnI+DQombmJzcDsgJm5ic3A7IGZy b20gdGhpcyBtaXggKGFzIHRoZSBpcyBub3QgcmVsZXZhbnQpIGFuZCBsZWF2ZSBURS1MU1AgJmFt cDsgU1BSSU5HICYjNDM7PGJyPg0KJm5ic3A7ICZuYnNwOyBtYXliZSBhbHNvIGFkZCBCSUVSIGFz IHdlbGwgYXMgY2hhbmdlIHRoZSBuYW1lIHRvIEdlbmVyaWMtRVA8YnI+DQombmJzcDsgJm5ic3A7 IChFbmdpbmVlcmVkIFBhdGhzKS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgc2VlIG5vIHZh bHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgZGF0YSBwbGFuZSB1c2VzPGJy Pg0KJm5ic3A7ICZuYnNwOyBtcGxzIGxhYmVscywgYnV0IHJhdGhlciBJIHdvdWxkIHNlZSByZWFz b25hYmxlIHRvIHByb3ZpZGUgbW9kZWxzPGJyPg0KJm5ic3A7ICZuYnNwOyBiYXNlZCBvbiB0aGUg dHJhbnNwb3J0IHBhdGggY2hhcmFjdGVyaXN0aWNzIGZvciB0aGUgdHJhZmZpYyBpdCBpcyB0bzxi cj4NCiZuYnNwOyAmbmJzcDsgY2FycnkuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBCZXN0LDxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgci48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIEZy aSwgTWFyIDYsIDIwMTUgYXQgMjoxMSBQTSwgSWdvciBCcnlza2luPGJyPg0KJm5ic3A7ICZuYnNw OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPklCcnlza2luQGFkdmFvcHRpY2FsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJt YWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+SUJyeXNraW5A YWR2YW9wdGljYWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgRHJ1diw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElNSE8gVEUtTFNQLCBMRFAtTFNQIGFu ZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZyBpbiBjb21tb24uIFRoZXk8YnI+DQombmJzcDsgJm5i c3A7IHNob3VsZCBoYXZlIHRvdGFsbHkgaW5kZXBlbmRlbnQgbW9kZWxzIGVhY2ggYmVpbmcgZGV2 ZWxvcGVkIGluPGJyPg0KJm5ic3A7ICZuYnNwOyByZXNwZWN0aXZlIFdHLjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgSWdvcjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7IFJ0Zy15 YW5nLWNvb3JkIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRv OlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmctY29vcmRA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGcteWFuZy1jb29yZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZDwvYT48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRlYXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5UZWFzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhczwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4N Ci0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPjxicj4NClNlbmlvciBNUExTIEV4 cGVydCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86bG9h QHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGkubnU8L2E+PGJyPg0KSHVhd2VpIFRlY2hu b2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBocmVmPSJ0 ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYg NzM5IDgxIDIxIDY0PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B91C18Deusaamb103erics_-- From nobody Sun Mar 8 12:34:55 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912781A00D8; Sun, 8 Mar 2015 12:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gI-GSXtJ6Fif; Sun, 8 Mar 2015 12:34:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99EEB1A00CC; Sun, 8 Mar 2015 12:34:49 -0700 (PDT) X-AuditID: c6180641-f796f6d000004ccc-89-54fc434299bb Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 7E.80.19660.2434CF45; Sun, 8 Mar 2015 13:40:35 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Sun, 8 Mar 2015 15:34:47 -0400 From: Gregory Mirsky To: Robert Raszuk Thread-Topic: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWY7Le4cVv75dNkqZzU3p3HVhN50S6nlAgABKdQD//8UFYA== Date: Sun, 8 Mar 2015 19:34:46 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91C1B1@eusaamb103.ericsson.se> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B91C1B1eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPiK6z858Qg3USFrs2rma0+Dd3DrPF raUrWS2aFjYxW7T+2MHiwOpx9uY/Fo8lS34yecya3sbmsXvjAqYAligum5TUnMyy1CJ9uwSu jJebbrMUvJvPVPH3+lumBsYVM5i6GDk5JARMJF7M6GeDsMUkLtxbD2RzcQgJHGGUuNd9ngUk ISSwjFHi7wWwIjYBI4kXG3vYQWwRAVWJzhOPmEEamAVaGCVabs4EaxAWsJE492YGI0SRrcS+ 5vfMELaTxPrTb8BsFgEViflPjoAN4hXwlTjwexYzxObFrBKfbi8BO49TIFBids9WsM2MQOd9 P7UGLM4sIC5x68l8qBcEJJbsOc8MYYtKvHz8jxXCVpKY8/oaM0R9vsSXizuglglKnJz5hGUC o+gsJKNmISmbhaRsFiMHUFxTYv0ufYgSRYkp3Q/ZIWwNidY5c9mRxRcwsq9i5CgtTi3LTTcy 3MQIjMVjEmyOOxgXfLI8xCjAwajEw2uw+3eIEGtiWXFl7iFGaQ4WJXHesisHQ4QE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUw9kfNO3r0v1/bwqCWS/MnWM1p3CiiFHXnwYOP957Oiut84Cxu tUH/k+b+Td8aFz0/ezIt2lWQz8j5KQfTp7YgpT8zGj86VPfxeUa/PT0rOjlJ8SELUwLPdj3d myW9uz6Fr2ibfFSutMIszdr28NegvDhpljrPJxPjYusZTgl9XBwnuHbP59tlSizFGYmGWsxF xYkA6Y4sVKYCAAA= Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" , Himanshu Shah , Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:34:53 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B91C1B1eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgYW4gTFNQLCBpLmUuIExhYmVsIFN3 aXRjaGVkIFBhdGgsIGNhbiBiZSByZWFsaXplZCBvdmVyIElQdjQgb3IgSVB2NiBkYXRhIHBsYW5l Og0KSXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBkYXRhIHBsYW5lIHRvIHRoZSBleHRlbmQgb2Yg YXZvaWRpbmcgbG9jay1pbiB0byBtcGxzIG9yIGlwdjQgb3IgaXB2Ni4NCg0KICAgICAgICAgICAg ICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJv bTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxm IE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFN1bmRheSwgTWFyY2ggMDgsIDIwMTUgMTI6MDMgUE0N ClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IEhpbWFuc2h1IFNoYWg7IHRlYXNAaWV0Zi5vcmc7IExv YSBBbmRlcnNzb247IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbVGVhc10gW21wbHNdIFtS dGcteWFuZy1jb29yZF0gR2VuZXJpYyBMU1AgWWFuZw0KDQoNCldob3cgLi4gaSB0aGluayB3ZSBh cmUgZGlzY292ZXJpbmcgdGhhdCB3ZSBhbGwgaGF2ZSBubyBjbHVlIHdoYXQgWWFuZyBtb2RlbCBp cyA6KQ0KDQpUaGF0IGlzIGluIGZhY3QgSSB0aGluayBncmVhdCBkaXNjdXNzaW9uIHRvIGhhdmUg c29vbmVyIHRoZW4gbGF0ZXIuDQoNClRvIG1lIFlhbmcgbW9kZWwgaXMgYSB3YXkgdG8gcmVwcmVz ZW50IHVuaWZpZWQgKGFjcm9zcyBpbnBsZW1lbnRhdGlvbnMpIHBpY3R1cmUgb2YgY29udHJvbCBw bGFuZSBmb3IgYSBnaXZlbiBuZXR3b3JrIGFwcGxpY2F0aW9uLg0KDQpJdCBoYXMgbm90aGluZyB0 byBkbyB3aXRoIGRhdGEgcGxhbmUgdG8gdGhlIGV4dGVuZCBvZiBhdm9pZGluZyBsb2NrLWluIHRv IG1wbHMgb3IgaXB2NCBvciBpcHY2Lg0KDQpUaGUgYXR0ZW1wdCB0byBnZW5lcmFsaXplIExTUCB3 b3VsZCBiZSBlcXVpdmFsZW50IHRvIGdlbmVyYWxpemUgUm91dGluZyByZWdhcmRsZXNzIGlmIHRo aXMgaXMgSUdQIG9yIEJHUCBvciBUUklMTCAuLi4gdGhlIG91dGNvbWUgb2YgdGhhdCB3b3VsZCBi ZSByYXRoZXIgcG9vciBJIHN1cHBvc2UgLi4uDQoNCkNoZWVycywNClIuDQpPbiBNYXIgOCwgMjAx NSA3OjQ4IFBNLCAiR3JlZ29yeSBNaXJza3kiIDxncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208 bWFpbHRvOmdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgUm9iZXJ0LCBl dC4gYWwsDQppZiBJIGludGVycHJldCB0aGUg4oCcTFNQIFlBTkcgbW9kZWzigJ0sIHRoZW4gaXQg cmVhZHMgYXMgWUFORyBtb2RlbCBvZiBNUExTIGRhdGEgcGxhbmUsIG5vdCBjb250cm9sIHByb3Rv Y29sLCBiZSBpdCBSU1ZQLVRFLCBMRFAsIFBDRVAsIG9yIElHUC1URSBvZiBTUFJJTkcuIEFuZCwg c2luY2UgdGhlIE1QTFMgZGF0YSBwbGFuZSBpcyBpbmRlZWQgY29tbW9uIGFuZCBpbiBmYWN0IHRo ZSBvbmUgYW5kIG9ubHksIHN1Y2ggTFNQIFlBTkcgbW9kZWwgcmlnaHRmdWxseSBjYW4gYmUgY2hh cmFjdGVyaXplZCBhcyDigJxHZW5lcmlj4oCdLg0KQnV0IGlmIGF1dGhvcnMgaW50ZW5kZWQgdG8g ZGVzY3JpYmUgY29tbW9uIHNldCBhbW9uZyBsaXN0ZWQgYWJvdmUgY29udHJvbCBwcm90b2NvbHMg cGVydGFpbmluZyB0byBzaWduYWxpbmcgb2YgYW4gTVBMUyBMU1AsIHRoZW4sIElNTywgc3VjaCBj b21tb24gc2V0IGZpcnN0IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBpZGVudGlmaWVkIHRvIGRlbW9u c3RyYXRlIHRoYXQgaXQgZG9lcyBleGlzdCBhbmQgaXMgc3VmZmljaWVudCB0byBoYXZlIFlBTkcg bW9kZWwgb2YgaXRzIG93biByYXRoZXIgdGhhbiBZQU5HIG1vZGVscyB0aGF0IGRlc2NyaWJlIExT UCBjb250cm9sIGJ5IGVhY2ggc2lnbmFsaW5nIHByb3RvY29scy4gVGhhdCB0byBtZSBsb29rcyB2 ZXJ5IG11Y2ggbGlrZSB3aGF0IExJTUUgV0cgaXMgd29ya2luZyBvbiwgaW52ZXN0aWdhdGluZyB3 aGV0aGVyIGNvbW1vbiBtb2RlbCBvZiBJUCwgSVAvTVBMUywgTVBMUy1UUCwgYW5kIFRSSUxMIE9B TSBleGlzdHMgYW5kIGl0cyBleHRlbnQgaXMgc3VmZmljaWVudCB0byBiZSBvZiBpbnRlcmVzdC4N Cg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEdyZWcNCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86dGVhcy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNl bnQ6IFN1bmRheSwgTWFyY2ggMDgsIDIwMTUgMzo1OCBBTQ0KVG86IExvYSBBbmRlcnNzb24NCkNj OiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPjsgdGVhc0BpZXRmLm9yZzxtYWls dG86dGVhc0BpZXRmLm9yZz47IFNoYWgsIEhpbWFuc2h1DQpTdWJqZWN0OiBSZTogW1RlYXNdIFtt cGxzXSBbUnRnLXlhbmctY29vcmRdIEdlbmVyaWMgTFNQIFlhbmcNCg0KSGkgTG9hLA0KDQpUaGUg d2F5IEkgcmVhZCBJZ29yIHN0YXRlbWVudCBhbmQgYWdyZWVkIHdpdGggaXQgaW4gYSBzZW5zZSBv ZiAibm90aGluZyBpbiBjb21tb24iIHdhcyB0aGF0IGl0IHdhcyByZWZlcnJpbmcgdG8gdGhlIGNv bnRyb2wgcGxhbmUuDQoNClRoZSBzdWJqZWN0IG9mIHRoaXMgdGhyZWFkIGlzICJHZW5lcmljIExT UCBZQU5HIiBhbmQgdG8gbWUgWWFuZyBtb2RlbCBkZXNjcmliZXMgY29udHJvbCBhc3BlY3Qgb2Yg cHJvdG9jb2wgb3IgZnVuY3Rpb25hbGl0eSBub3QgdGhlIGNob2ljZSBvZiBmb3J3YXJkaW5nIGhl YWRlciBpbiB0aGUgZGF0YSBwbGFuZS4NCg0KU28gaWYgeW91IGFuZCBvdGhlcnMgYWdyZWUgd2Ug c2hvdWxkIGJlIGFsbCBpbiBzeW5jIGFuZCBwZXJoYXBzIHdlIGNvdWxkIGNvbnNpZGVyIGFzIHBy b3Bvc2VkIGJlZm9yZSBHZW5lcmljIEVuZ2luZWVyZWQgUGF0aCBtb2RlbCBicmFuY2hpbmcgYXQg dGhlIGxvd2VyIGxheWVyIGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0Lg0KDQpIb3dldmVy IGlmIHlvdSBzdGlsbCB0aGluayB0aGF0IFlhbmcgaXMgYWJvdXQgZGF0YSBwbGFuZSBhbmQgT0FN IHRoZW4gcGVyaGFwcyB3ZSBoYXZlIGEgYmlnZ2VyIGlzc3VlIGhlcmUgLi4uLg0KDQpDaGVlcnMs DQpSLg0KDQoNCg0KDQpPbiBTdW4sIE1hciA4LCAyMDE1IGF0IDEwOjI3IEFNLCBMb2EgQW5kZXJz c29uIDxsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4+IHdyb3RlOg0KSGltYW5zaHUsIGV0LmFs PGh0dHA6Ly9ldC5hbD4uLA0KDQpJIHRoaW5rIHRoZXJlIGFyZSB0d28gaXNzdWVzIGhlcmUgYW5k IGlmIHNvcnRpbmcgdGhlbSBvdXQgY29ycnJlY3RseQ0Kd2UgYXJlIHZlcnkgY2xvc2UuDQoNClRo ZSBmaXJzdCBpc3N1ZSBpcyBzaW1pbGFyaXRpZXMgYmV0d2VlbiBkaWZmZXJlbnQgdHlwZXMgb2Yg TFNQcy4NCg0KSGVyZSBJIHNhaWQgdGhhdCwgYXQgbGVhc3QgZm9yIGEgTVBMUyBQU04sIHRoZXJl IGFyZSBzaW1pbGFyaXRpZXMsDQplLmcuIHRoZSBkYXRhIHBsYW5lIGlzIChuZWFybHkpIHRoZSBz YW1lLiBUaGlzIHdhcyBzYWlkIGluIHJlYWN0aW9uDQp0byBJZ29yJ3Mgc3RhdGVtZW50ICJJTUhP IFRFLUxTUCwgTERQLUxTUCBhbmQgU1BSSU5HLUxTUCBoYXZlIG5vdGhpbmcNCmluIGNvbW1vbi4i IEkgc3RpbGwgZG9uJ3QgdGhpbmsgdGhhdCBJZ29yJ3Mgc3RhdGVtZW50IGlzIHJlYWxseSBjb3Jy ZWN0Lg0KSWYgaGUgaGFkIHNhaWQgIklNSE8gdGhlcmUgYXJlIG5vdCBlbm91Z2ggc2ltaWxhcml0 ZXMgYmV0d2VlbiBURS1MU1AsDQpMRFAtTFNQIGFuZCBTUFJJTkctTFNQIHRvIG1vdGl2YXRlIGEg Y29tbW9uIG1vZGVsIi4gSSB0aGluayB0aGF0IHdlIGJlDQphIG11Y2ggbW9yZSBhY2N1cmF0ZSBz dGF0ZW1lbnQuDQoNCkFuZCB0aGF0IGlzIHRoZSBvdGhlciBpc3N1ZSAtIElzIGl0IHJlYXNvbmFi bGUgdG8gbW9kZWwgVEUtTFNQLA0KTERQLUxTUCBhbmQgU1BSSU5HLUxTUCBpbiB0aGUgc2FtZSBt b2RlbD8gSSBkb24ndCBub3QgdGhpbmsgaXQgaXMsDQpidXQgdGhhdCB3ZSBuZWVkIGFuIG92ZXJs YXAgb2YgcGVvcGxlIHdvcmtpbmcgd2l0aCB0aGUgZGlmZmVyZW50IG1vZGVscy4NCg0KSG9wZSB0 aGlzIGlzIGNsZWFyIGVub3VnaC4NCg0KL0xvYQ0KDQoNCk9uIDIwMTUtMDMtMDcgMjM6MTksIFNo YWgsIEhpbWFuc2h1IHdyb3RlOg0KL0kgYWdyZWUgd2l0aCBSb2JlcnQgYW5kIElnb3IsIHB1dHRp bmcgZXZlcnl0aGluZyBpbiB0aGUgc2FtZSBidWNrZXQNCmJlY2F1c2Ugb2YgY29tbW9uIGRhdGEg cGxhbmUgJiBPQU0gZG9lcyBub3QganVzdGlmeS4vDQoNCi9XZSB3b3VsZG7igJl0IGNvbnNpZGVy IGRvaW5nIHNhbWUgZm9yIElQIGRhdGEgcGxhbmUuLi8NCg0KL0kgdGhpbmsgd2UgbmVlZCB0byBz ZXBhcmF0ZSB0aGVzZSBtb2RlbHMgYW5kIGFzIG1lbnRpb25lZCBlYXJsaWVyLA0KdGhlcmUgaXMg YWxyZWFkeSB3b3JrIGdvaW5nIG9uIGluIHJlc3BlY3RpdmUgV0dzLi8NCg0KLy8NCg0KL1RoYW5r cywvDQoNCi9oaW1hbnNodS8NCg0KLy8NCg0KLy8NCg0KLy8NCg0KKkZyb206Km1wbHMgW21haWx0 bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZz5dICpP biBCZWhhbGYgT2YgKkxvYSBBbmRlcnNzb24NCipTZW50OiogU2F0dXJkYXksIE1hcmNoIDA3LCAy MDE1IDg6MTggQU0NCipUbzoqIHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0Zi5vcmc+LCBt cGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiwgcm9iZXJ0QHJhc3p1ay5uZXQ8bWFp bHRvOnJvYmVydEByYXN6dWsubmV0Pg0KKlN1YmplY3Q6KiBSZTogW21wbHNdIFtSdGcteWFuZy1j b29yZF0gW1RlYXNdIEdlbmVyaWMgTFNQIFlhbmcNCg0KUm9iZXJ0LA0KDQogRnJvbSBvbmUgcGVy c3BlY3RpdmUgSSBhZ3JlZSB3aXRoIHlvdSBhbmQgSWdvciwgaG93ZXZlciBpZiB5b3UgdGhpbmsN CmFib3V0IE1QTFMgTFNQcywgZnJvbSBhIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUgLSBhbmQgdGhh dCBpcyB3aGVyZSBPQU0NCm9wZXJhdGVzLCB0aGVyZSBhbG1vc3Qgbm8gZGlmZmVyZW5jZSBiZXR3 ZWVuIGEgVEUtTFNQIGEgTERQLUxTUCBhbmQgYQ0KU1BSSU5HIE1QTFMgTFNQIGNvbWUgdmVyeSBj bG9zZS4NCg0KSWYgeW91IHRoZSBvdGhlciBoYW5kIHRoaW5rIG9mIExTUHMgZm9yIG90aGVyIGRh dGEgcGxhbmVzIHRoZSAibm90aGluZw0KaW4gY29tbW9uIiBpcyBhbiBhbG1vc3QgdHJ1ZSBzdGF0 ZW1lbnQuIEZyb20gdGhhdCBwb2ludCBvZiB2aWV3IEkgdGhpbmsNCmRpZmZlcmVudCBtb2RlbHMg YXJlIHdoZXJlIHdlIHdpbGwgZW5kIHVwLCBidXQgSSBhbHNvIHRoaW5rIHRoYXQgd2UgbmVlZA0K InNlcGFyYXRpb24gd2l0aCBtb2RlcmF0aW9uIi4NCg0KICBCdXQgbm90aGluZyBpcyBzbyBzaW1w bGUgdGhhdCB3ZSBjYW4gY2FwdHVyZSBpdCBpbiBvbmUgdmVyeSBzaW1wbGUNCnN0YXRlbWVudCwg d2UgaGF2ZSBoYWNraW5nIGF3YXkgb24gdGhpcyBmb3IgMzAgeWVhcnMgbm93LCBJJ2QgYWR2aWNl DQp0YWtpbmcgYXJjaGl0ZWN0dXJlIGFuZCBoaXN0b3J5IGludG8gY29uc2lkZXJhdGlvbiwgYXMg d2VsbCBhcyB2aWV3aW5nDQp0aGUgc2t5IGZyb20gYSBkaWZmZXJlbnQgcGVyc3BlY3RpdmUgdGhh biBmcm9tIHRoZSBib3R0b20gb2YgYSBkZWVwIHdlbGwuDQoNCkxldCBtZSBhbHNvIHNheSB0aGF0 IEknbSB2ZXJ5IHN1cHBvcnRpdmUgb2YgYWxsIHRoZSBnb29kIHdvcmsgZ29pbmcgb24NCmluIHRo aXMgYXJlYS4NCg0KL0xvYQ0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQoNCk9uIDA3IE1hciAyMDE1 LCBhdCAxOTo0NywgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ8bWFpbHRvOnJvYmVy dEByYXN6dWsubmV0Pg0KPG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJh c3p1ay5uZXQ+Pj4gd3JvdGU6DQoNCiAgICBJIHdvdWxkIGFncmVlIHdpdGggSWdvci4NCg0KICAg IE90aGVyIHRoZW4gbmFtZSBvdmVybGFwIHRob3NlIGFyZSBjb21wbGV0ZWx5IGRpZmZlcmVudCB0 ZWNobm9sb2dpZXMNCiAgICBhbmQgYXJ0aWZpY2lhbGx5IHB1dHRpbmcgdGhlbSB1bmRlciAiTFNQ IiB1bWJyZWxsYSBqdXN0IGRvZXMgbm90DQogICAgYnJpbmcgYW55IHZhbHVlLCBidXQgb25seSBj b25mdXNlcyB0aGluZ3MgZXZlbiBtb3JlLg0KDQogICAgUTogV2hhdCBTUFJJTkctTFNQIGhhcyBh bnl0aGluZyBpbiBjb21tb24gd2l0aCAibGFiZWwiIHdoZW4geW91IHVzZQ0KICAgIHY2IGhlYWRl ciA/DQoNCiAgICBJZiB5b3Ugd2FudCB0byBzZWFyY2ggZm9yIHNvbWUgY29tbW9uYWxpdGllcyBs ZXQncyByZW1vdmUgTERQLUxTUHMNCiAgICBmcm9tIHRoaXMgbWl4IChhcyB0aGUgaXMgbm90IHJl bGV2YW50KSBhbmQgbGVhdmUgVEUtTFNQICYgU1BSSU5HICsNCiAgICBtYXliZSBhbHNvIGFkZCBC SUVSIGFzIHdlbGwgYXMgY2hhbmdlIHRoZSBuYW1lIHRvIEdlbmVyaWMtRVANCiAgICAoRW5naW5l ZXJlZCBQYXRocykuDQoNCiAgICBJIHNlZSBubyB2YWx1ZSBvZiBnb3J1cGluZyBiYXNlZCBvbiB0 aGUgZmFjdCB0aGF0IGRhdGEgcGxhbmUgdXNlcw0KICAgIG1wbHMgbGFiZWxzLCBidXQgcmF0aGVy IEkgd291bGQgc2VlIHJlYXNvbmFibGUgdG8gcHJvdmlkZSBtb2RlbHMNCiAgICBiYXNlZCBvbiB0 aGUgdHJhbnNwb3J0IHBhdGggY2hhcmFjdGVyaXN0aWNzIGZvciB0aGUgdHJhZmZpYyBpdCBpcyB0 bw0KICAgIGNhcnJ5Lg0KDQogICAgQmVzdCwNCg0KICAgIHIuDQoNCiAgICBPbiBGcmksIE1hciA2 LCAyMDE1IGF0IDI6MTEgUE0sIElnb3IgQnJ5c2tpbg0KICAgIDxJQnJ5c2tpbkBhZHZhb3B0aWNh bC5jb208bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbT4gPG1haWx0bzpJQnJ5c2tpbkBh ZHZhb3B0aWNhbC5jb208bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbT4+PiB3cm90ZToN Cg0KICAgIERydXYsDQoNCiAgICBJTUhPIFRFLUxTUCwgTERQLUxTUCBhbmQgU1BSSU5HLUxTUCBo YXZlIG5vdGhpbmcgaW4gY29tbW9uLiBUaGV5DQogICAgc2hvdWxkIGhhdmUgdG90YWxseSBpbmRl cGVuZGVudCBtb2RlbHMgZWFjaCBiZWluZyBkZXZlbG9wZWQgaW4NCiAgICByZXNwZWN0aXZlIFdH Lg0KDQogICAgSWdvcg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICBSdGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3QNCiAgICBSdGcteWFu Zy1jb29yZEBpZXRmLm9yZzxtYWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc+IDxtYWlsdG86 UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPj4N CiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5nLWNvb3Jk DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VGVhcyBtYWlsaW5nIGxpc3QNClRlYXNAaWV0Zi5vcmc8bWFpbHRvOlRlYXNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlYXMNCg0KLS0NCg0KDQpMb2Eg QW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2Vp LmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPg0KU2VuaW9yIE1QTFMgRXhwZXJ0ICAg ICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCkh1YXdl aSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NDx0 ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQ+DQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B91C1B1eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YXJl IHlvdSBzdWdnZXN0aW5nIHRoYXQgYW4gTFNQLCBpLmUuIExhYmVsIFN3aXRjaGVkIFBhdGgsIGNh biBiZSByZWFsaXplZCBvdmVyIElQdjQgb3IgSVB2NiBkYXRhIHBsYW5lOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaGFzIG5vdGhpbmcg dG8gZG8gd2l0aCBkYXRhIHBsYW5lIHRvIHRoZSBleHRlbmQgb2YgYXZvaWRpbmcgbG9jay1pbiB0 byBtcGxzIG9yIGlwdjQgb3IgaXB2Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJyYXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1 a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5T ZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAwOCwgMjAxNSAxMjowMyBQTTxicj4NCjxiPlRvOjwvYj4g R3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8L2I+IEhpbWFuc2h1IFNoYWg7IHRlYXNAaWV0Zi5v cmc7IExvYSBBbmRlcnNzb247IG1wbHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtUZWFzXSBbbXBsc10gW1J0Zy15YW5nLWNvb3JkXSBHZW5lcmljIExTUCBZYW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cD5XaG93IC4uIGkgdGhpbmsgd2UgYXJlIGRpc2NvdmVyaW5nIHRoYXQgd2UgYWxsIGhhdmUg bm8gY2x1ZSB3aGF0IFlhbmcgbW9kZWwgaXMgOik8bzpwPjwvbzpwPjwvcD4NCjxwPlRoYXQgaXMg aW4gZmFjdCBJIHRoaW5rIGdyZWF0IGRpc2N1c3Npb24gdG8gaGF2ZSBzb29uZXIgdGhlbiBsYXRl ci48bzpwPjwvbzpwPjwvcD4NCjxwPlRvIG1lIFlhbmcgbW9kZWwgaXMgYSB3YXkgdG8gcmVwcmVz ZW50IHVuaWZpZWQgKGFjcm9zcyBpbnBsZW1lbnRhdGlvbnMpIHBpY3R1cmUgb2YgY29udHJvbCBw bGFuZSBmb3IgYSBnaXZlbiBuZXR3b3JrIGFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+ SXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBkYXRhIHBsYW5lIHRvIHRoZSBleHRlbmQgb2YgYXZv aWRpbmcgbG9jay1pbiB0byBtcGxzIG9yIGlwdjQgb3IgaXB2Ni48bzpwPjwvbzpwPjwvcD4NCjxw PlRoZSBhdHRlbXB0IHRvIGdlbmVyYWxpemUgTFNQIHdvdWxkIGJlIGVxdWl2YWxlbnQgdG8gZ2Vu ZXJhbGl6ZSBSb3V0aW5nIHJlZ2FyZGxlc3MgaWYgdGhpcyBpcyBJR1Agb3IgQkdQIG9yIFRSSUxM IC4uLiB0aGUgb3V0Y29tZSBvZiB0aGF0IHdvdWxkIGJlIHJhdGhlciBwb29yIEkgc3VwcG9zZSAu Li48bzpwPjwvbzpwPjwvcD4NCjxwPkNoZWVycyw8YnI+DQpSLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciA4LCAyMDE1IDc6NDggUE0sICZxdW90O0dy ZWdvcnkgTWlyc2t5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJp Y3Nzb24uY29tIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LCBldC4gYWwsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+aWYgSSBpbnRlcnByZXQgdGhlIOKAnExTUCBZ QU5HIG1vZGVs4oCdLCB0aGVuIGl0IHJlYWRzIGFzIFlBTkcgbW9kZWwgb2YgTVBMUyBkYXRhIHBs YW5lLCBub3QgY29udHJvbA0KIHByb3RvY29sLCBiZSBpdCBSU1ZQLVRFLCBMRFAsIFBDRVAsIG9y IElHUC1URSBvZiBTUFJJTkcuIEFuZCwgc2luY2UgdGhlIE1QTFMgZGF0YSBwbGFuZSBpcyBpbmRl ZWQgY29tbW9uIGFuZCBpbiBmYWN0IHRoZSBvbmUgYW5kIG9ubHksIHN1Y2ggTFNQIFlBTkcgbW9k ZWwgcmlnaHRmdWxseSBjYW4gYmUgY2hhcmFjdGVyaXplZCBhcyDigJxHZW5lcmlj4oCdLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCBpZiBhdXRob3JzIGludGVuZGVkIHRvIGRl c2NyaWJlIGNvbW1vbiBzZXQgYW1vbmcgbGlzdGVkIGFib3ZlIGNvbnRyb2wgcHJvdG9jb2xzIHBl cnRhaW5pbmcgdG8NCiBzaWduYWxpbmcgb2YgYW4gTVBMUyBMU1AsIHRoZW4sIElNTywgc3VjaCBj b21tb24gc2V0IGZpcnN0IG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBpZGVudGlmaWVkIHRvIGRlbW9u c3RyYXRlIHRoYXQgaXQgZG9lcyBleGlzdCBhbmQgaXMgc3VmZmljaWVudCB0byBoYXZlIFlBTkcg bW9kZWwgb2YgaXRzIG93biByYXRoZXIgdGhhbiBZQU5HIG1vZGVscyB0aGF0IGRlc2NyaWJlIExT UCBjb250cm9sIGJ5IGVhY2ggc2lnbmFsaW5nIHByb3RvY29scy4gVGhhdA0KIHRvIG1lIGxvb2tz IHZlcnkgbXVjaCBsaWtlIHdoYXQgTElNRSBXRyBpcyB3b3JraW5nIG9uLCBpbnZlc3RpZ2F0aW5n IHdoZXRoZXIgY29tbW9uIG1vZGVsIG9mIElQLCBJUC9NUExTLCBNUExTLVRQLCBhbmQgVFJJTEwg T0FNIGV4aXN0cyBhbmQgaXRzIGV4dGVudCBpcyBzdWZmaWNpZW50IHRvIGJlIG9mIGludGVyZXN0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50 ZWFzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFz enVrPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWFyY2ggMDgsIDIwMTUgMzo1OCBBTTxicj4N CjxiPlRvOjwvYj4gTG9hIEFuZGVyc3Nvbjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRv Om1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRlYXNAaWV0Zi5vcmc8 L2E+OyBTaGFoLCBIaW1hbnNodTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNdIFttcGxz XSBbUnRnLXlhbmctY29vcmRdIEdlbmVyaWMgTFNQIFlhbmc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgTG9hLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIHdheSBJIHJlYWQgSWdvciBzdGF0ZW1l bnQgYW5kIGFncmVlZCB3aXRoIGl0IGluIGEgc2Vuc2Ugb2YgJnF1b3Q7bm90aGluZyBpbiBjb21t b24mcXVvdDsgd2FzIHRoYXQgaXQgd2FzIHJlZmVycmluZyB0byB0aGUgY29udHJvbCBwbGFuZS4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPlRoZSBzdWJqZWN0IG9mIHRoaXMgdGhyZWFkIGlzICZxdW90O0dlbmVyaWMgTFNQIFlB TkcmcXVvdDsgYW5kIHRvIG1lIFlhbmcgbW9kZWwgZGVzY3JpYmVzIGNvbnRyb2wgYXNwZWN0IG9m IHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbm90IHRoZSBjaG9pY2UNCiBvZiBmb3J3YXJkaW5n IGhlYWRlciBpbiB0aGUgZGF0YSBwbGFuZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNvIGlmIHlvdSBhbmQgb3RoZXJzIGFn cmVlIHdlIHNob3VsZCBiZSBhbGwgaW4gc3luYyBhbmQgcGVyaGFwcyB3ZSBjb3VsZCBjb25zaWRl ciBhcyBwcm9wb3NlZCBiZWZvcmUgR2VuZXJpYyBFbmdpbmVlcmVkIFBhdGggbW9kZWwgYnJhbmNo aW5nDQogYXQgdGhlIGxvd2VyIGxheWVyIGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0LiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+SG93ZXZlciBpZiB5b3Ugc3RpbGwgdGhpbmsgdGhhdCBZYW5nIGlzIGFib3V0IGRhdGEg cGxhbmUgYW5kIE9BTSB0aGVuIHBlcmhhcHMgd2UgaGF2ZSBhIGJpZ2dlciBpc3N1ZSBoZXJlIC4u Li48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkNoZWVycyw8YnI+DQpSLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFN1biwgTWFyIDgsIDIw MTUgYXQgMTA6MjcgQU0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGku bnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGltYW5zaHUsDQo8YSBocmVmPSJodHRwOi8vZXQu YWwiIHRhcmdldD0iX2JsYW5rIj5ldC5hbDwvYT4uLDxicj4NCjxicj4NCkkgdGhpbmsgdGhlcmUg YXJlIHR3byBpc3N1ZXMgaGVyZSBhbmQgaWYgc29ydGluZyB0aGVtIG91dCBjb3JycmVjdGx5PGJy Pg0Kd2UgYXJlIHZlcnkgY2xvc2UuPGJyPg0KPGJyPg0KVGhlIGZpcnN0IGlzc3VlIGlzIHNpbWls YXJpdGllcyBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZiBMU1BzLjxicj4NCjxicj4NCkhlcmUg SSBzYWlkIHRoYXQsIGF0IGxlYXN0IGZvciBhIE1QTFMgUFNOLCB0aGVyZSBhcmUgc2ltaWxhcml0 aWVzLDxicj4NCmUuZy4gdGhlIGRhdGEgcGxhbmUgaXMgKG5lYXJseSkgdGhlIHNhbWUuIFRoaXMg d2FzIHNhaWQgaW4gcmVhY3Rpb248YnI+DQp0byBJZ29yJ3Mgc3RhdGVtZW50ICZxdW90O0lNSE8g VEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZzxicj4NCmluIGNvbW1v bi4mcXVvdDsgSSBzdGlsbCBkb24ndCB0aGluayB0aGF0IElnb3IncyBzdGF0ZW1lbnQgaXMgcmVh bGx5IGNvcnJlY3QuPGJyPg0KSWYgaGUgaGFkIHNhaWQgJnF1b3Q7SU1ITyB0aGVyZSBhcmUgbm90 IGVub3VnaCBzaW1pbGFyaXRlcyBiZXR3ZWVuIFRFLUxTUCw8YnI+DQpMRFAtTFNQIGFuZCBTUFJJ TkctTFNQIHRvIG1vdGl2YXRlIGEgY29tbW9uIG1vZGVsJnF1b3Q7LiBJIHRoaW5rIHRoYXQgd2Ug YmU8YnI+DQphIG11Y2ggbW9yZSBhY2N1cmF0ZSBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KQW5kIHRo YXQgaXMgdGhlIG90aGVyIGlzc3VlIC0gSXMgaXQgcmVhc29uYWJsZSB0byBtb2RlbCBURS1MU1As PGJyPg0KTERQLUxTUCBhbmQgU1BSSU5HLUxTUCBpbiB0aGUgc2FtZSBtb2RlbD8gSSBkb24ndCBu b3QgdGhpbmsgaXQgaXMsPGJyPg0KYnV0IHRoYXQgd2UgbmVlZCBhbiBvdmVybGFwIG9mIHBlb3Bs ZSB3b3JraW5nIHdpdGggdGhlIGRpZmZlcmVudCBtb2RlbHMuPGJyPg0KPGJyPg0KSG9wZSB0aGlz IGlzIGNsZWFyIGVub3VnaC48YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAx NS0wMy0wNyAyMzoxOSwgU2hhaCwgSGltYW5zaHUgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPi9JIGFncmVlIHdpdGggUm9iZXJ0IGFuZCBJZ29yLCBwdXR0aW5nIGV2ZXJ5 dGhpbmcgaW4gdGhlIHNhbWUgYnVja2V0PGJyPg0KYmVjYXVzZSBvZiBjb21tb24gZGF0YSBwbGFu ZSAmYW1wOyBPQU0gZG9lcyBub3QganVzdGlmeS4vPGJyPg0KPGJyPg0KL1dlIHdvdWxkbuKAmXQg Y29uc2lkZXIgZG9pbmcgc2FtZSBmb3IgSVAgZGF0YSBwbGFuZS4uLzxicj4NCjxicj4NCi9JIHRo aW5rIHdlIG5lZWQgdG8gc2VwYXJhdGUgdGhlc2UgbW9kZWxzIGFuZCBhcyBtZW50aW9uZWQgZWFy bGllciw8YnI+DQp0aGVyZSBpcyBhbHJlYWR5IHdvcmsgZ29pbmcgb24gaW4gcmVzcGVjdGl2ZSBX R3MuLzxicj4NCjxicj4NCi8vPGJyPg0KPGJyPg0KL1RoYW5rcywvPGJyPg0KPGJyPg0KL2hpbWFu c2h1Lzxicj4NCjxicj4NCi8vPGJyPg0KPGJyPg0KLy88YnI+DQo8YnI+DQovLzxicj4NCjxicj4N CipGcm9tOiptcGxzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYg T2YgKkxvYSBBbmRlcnNzb248YnI+DQoqU2VudDoqIFNhdHVyZGF5LCBNYXJjaCAwNywgMjAxNSA4 OjE4IEFNPGJyPg0KKlRvOiogPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50ZWFzQGlldGYub3JnPC9hPiwgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4NCm1wbHNAaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86cm9i ZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT48YnI+ DQoqU3ViamVjdDoqIFJlOiBbbXBsc10gW1J0Zy15YW5nLWNvb3JkXSBbVGVhc10gR2VuZXJpYyBM U1AgWWFuZzxicj4NCjxicj4NClJvYmVydCw8YnI+DQo8YnI+DQombmJzcDtGcm9tIG9uZSBwZXJz cGVjdGl2ZSBJIGFncmVlIHdpdGggeW91IGFuZCBJZ29yLCBob3dldmVyIGlmIHlvdSB0aGluazxi cj4NCmFib3V0IE1QTFMgTFNQcywgZnJvbSBhIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUgLSBhbmQg dGhhdCBpcyB3aGVyZSBPQU08YnI+DQpvcGVyYXRlcywgdGhlcmUgYWxtb3N0IG5vIGRpZmZlcmVu Y2UgYmV0d2VlbiBhIFRFLUxTUCBhIExEUC1MU1AgYW5kIGE8YnI+DQpTUFJJTkcgTVBMUyBMU1Ag Y29tZSB2ZXJ5IGNsb3NlLjxicj4NCjxicj4NCklmIHlvdSB0aGUgb3RoZXIgaGFuZCB0aGluayBv ZiBMU1BzIGZvciBvdGhlciBkYXRhIHBsYW5lcyB0aGUgJnF1b3Q7bm90aGluZzxicj4NCmluIGNv bW1vbiZxdW90OyBpcyBhbiBhbG1vc3QgdHJ1ZSBzdGF0ZW1lbnQuIEZyb20gdGhhdCBwb2ludCBv ZiB2aWV3IEkgdGhpbms8YnI+DQpkaWZmZXJlbnQgbW9kZWxzIGFyZSB3aGVyZSB3ZSB3aWxsIGVu ZCB1cCwgYnV0IEkgYWxzbyB0aGluayB0aGF0IHdlIG5lZWQ8YnI+DQomcXVvdDtzZXBhcmF0aW9u IHdpdGggbW9kZXJhdGlvbiZxdW90Oy48YnI+DQo8YnI+DQombmJzcDsgQnV0IG5vdGhpbmcgaXMg c28gc2ltcGxlIHRoYXQgd2UgY2FuIGNhcHR1cmUgaXQgaW4gb25lIHZlcnkgc2ltcGxlPGJyPg0K c3RhdGVtZW50LCB3ZSBoYXZlIGhhY2tpbmcgYXdheSBvbiB0aGlzIGZvciAzMCB5ZWFycyBub3cs IEknZCBhZHZpY2U8YnI+DQp0YWtpbmcgYXJjaGl0ZWN0dXJlIGFuZCBoaXN0b3J5IGludG8gY29u c2lkZXJhdGlvbiwgYXMgd2VsbCBhcyB2aWV3aW5nPGJyPg0KdGhlIHNreSBmcm9tIGEgZGlmZmVy ZW50IHBlcnNwZWN0aXZlIHRoYW4gZnJvbSB0aGUgYm90dG9tIG9mIGEgZGVlcCB3ZWxsLjxicj4N Cjxicj4NCkxldCBtZSBhbHNvIHNheSB0aGF0IEknbSB2ZXJ5IHN1cHBvcnRpdmUgb2YgYWxsIHRo ZSBnb29kIHdvcmsgZ29pbmcgb248YnI+DQppbiB0aGlzIGFyZWEuPGJyPg0KPGJyPg0KL0xvYTxi cj4NCjxicj4NClNlbnQgZnJvbSBteSBpUGFkPGJyPg0KPGJyPg0KPGJyPg0KT24gMDcgTWFyIDIw MTUsIGF0IDE5OjQ3LCBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJh c3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT48YnI+DQombHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsi PnJvYmVydEByYXN6dWsubmV0PC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgSSB3b3VsZCBhZ3JlZSB3aXRoIElnb3IuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBP dGhlciB0aGVuIG5hbWUgb3ZlcmxhcCB0aG9zZSBhcmUgY29tcGxldGVseSBkaWZmZXJlbnQgdGVj aG5vbG9naWVzPGJyPg0KJm5ic3A7ICZuYnNwOyBhbmQgYXJ0aWZpY2lhbGx5IHB1dHRpbmcgdGhl bSB1bmRlciAmcXVvdDtMU1AmcXVvdDsgdW1icmVsbGEganVzdCBkb2VzIG5vdDxicj4NCiZuYnNw OyAmbmJzcDsgYnJpbmcgYW55IHZhbHVlLCBidXQgb25seSBjb25mdXNlcyB0aGluZ3MgZXZlbiBt b3JlLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUTogV2hhdCBTUFJJTkctTFNQIGhhcyBhbnl0 aGluZyBpbiBjb21tb24gd2l0aCAmcXVvdDtsYWJlbCZxdW90OyB3aGVuIHlvdSB1c2U8YnI+DQom bmJzcDsgJm5ic3A7IHY2IGhlYWRlciA/PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJZiB5b3Ug d2FudCB0byBzZWFyY2ggZm9yIHNvbWUgY29tbW9uYWxpdGllcyBsZXQncyByZW1vdmUgTERQLUxT UHM8YnI+DQombmJzcDsgJm5ic3A7IGZyb20gdGhpcyBtaXggKGFzIHRoZSBpcyBub3QgcmVsZXZh bnQpIGFuZCBsZWF2ZSBURS1MU1AgJmFtcDsgU1BSSU5HICYjNDM7PGJyPg0KJm5ic3A7ICZuYnNw OyBtYXliZSBhbHNvIGFkZCBCSUVSIGFzIHdlbGwgYXMgY2hhbmdlIHRoZSBuYW1lIHRvIEdlbmVy aWMtRVA8YnI+DQombmJzcDsgJm5ic3A7IChFbmdpbmVlcmVkIFBhdGhzKS48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IEkgc2VlIG5vIHZhbHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRoZSBmYWN0 IHRoYXQgZGF0YSBwbGFuZSB1c2VzPGJyPg0KJm5ic3A7ICZuYnNwOyBtcGxzIGxhYmVscywgYnV0 IHJhdGhlciBJIHdvdWxkIHNlZSByZWFzb25hYmxlIHRvIHByb3ZpZGUgbW9kZWxzPGJyPg0KJm5i c3A7ICZuYnNwOyBiYXNlZCBvbiB0aGUgdHJhbnNwb3J0IHBhdGggY2hhcmFjdGVyaXN0aWNzIGZv ciB0aGUgdHJhZmZpYyBpdCBpcyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgY2FycnkuPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBCZXN0LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgci48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IE9uIEZyaSwgTWFyIDYsIDIwMTUgYXQgMjoxMSBQTSwgSWdvciBC cnlza2luPGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOklCcnlza2luQGFk dmFvcHRpY2FsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPklCcnlza2luQGFkdmFvcHRpY2FsLmNvbTwv YT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPC9hPiZndDsmZ3Q7IHdyb3Rl Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgRHJ1diw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IElNSE8gVEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZyBpbiBjb21t b24uIFRoZXk8YnI+DQombmJzcDsgJm5ic3A7IHNob3VsZCBoYXZlIHRvdGFsbHkgaW5kZXBlbmRl bnQgbW9kZWxzIGVhY2ggYmVpbmcgZGV2ZWxvcGVkIGluPGJyPg0KJm5ic3A7ICZuYnNwOyByZXNw ZWN0aXZlIFdHLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSWdvcjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQombmJzcDsgJm5ic3A7IFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdDxicj4NCiZuYnNw OyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmct Y29vcmRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1j b29yZDwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOlRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UZWFzQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVh cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dGVhczwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNz b24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBt YWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5odWF3ZWkuY29t PC9hPjxicj4NClNlbmlvciBNUExTIEV4cGVydCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGku bnU8L2E+PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7 ICZuYnNwO3Bob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRh cmdldD0iX2JsYW5rIj4NCiYjNDM7NDYgNzM5IDgxIDIxIDY0PC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B91C1B1eusaamb103erics_-- From nobody Sun Mar 8 12:40:21 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D781A00D8; Sun, 8 Mar 2015 12:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zw4JSp7yQvl; Sun, 8 Mar 2015 12:40:15 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1C51A010F; Sun, 8 Mar 2015 12:40:12 -0700 (PDT) Received: by iebtr6 with SMTP id tr6so24642829ieb.2; Sun, 08 Mar 2015 12:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xAW9GGMlVpm2qbE9jSY0vHsSJum2j3dWzwoMIokffl4=; b=CyV4Hj1yLrCZ61B1WKG+D5MWNSql/3BlK340np+FfPo47o76vQ9LYGAjj4OnhMi2HZ Vm43O+hY8s0IuD0ykETPigblYqewD6YqJuJFom1mozR18gdP5n/sNUeoO2kKjPdUCN9c GPYR8/mBIP3/Qb5cAAy10RN3YUknl55q8TTQbOATIUz4LNlcjrz26es9eUZXKv9qjed3 oneIeVTCSPnoLH9FWbOmY4c+J0kWUM1/qrcJNSv+LbWpUopia3Lf73+uVdoe2qEwwu1w zdU2+nWrKiReIPdcKyee3A4L5IDBoJjc45DVJ2c2zdHMKsVglumUbgVO/gsZIqQkSsrE KMfg== MIME-Version: 1.0 X-Received: by 10.107.138.232 with SMTP id c101mr15079154ioj.47.1425843611777; Sun, 08 Mar 2015 12:40:11 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 12:40:11 -0700 (PDT) Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 12:40:11 -0700 (PDT) In-Reply-To: References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B91C18D@eusaamb103.ericsson.se> Date: Sun, 8 Mar 2015 20:40:11 +0100 X-Google-Sender-Auth: 7kdIOLnG2Lxsgv4VlJ9yygGitYc Message-ID: From: Robert Raszuk To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a113ed3f8fc47350510cc158e Archived-At: Cc: "mpls@ietf.org" , Himanshu Shah , teas@ietf.org, Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:40:18 -0000 --001a113ed3f8fc47350510cc158e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I beg you pardon but i have never seen static LSPs really in production use .. that means being configured hop by hop by cli. For the recird I have started my MPLS days with TDP in around 1997 :) So what it means for this duscussion? Are you proposing say for RSVP-TE to push labels hop by hop or you would rather see Yang representing ERO as part of it ? I think no one says we can not have Yang model for static labels and centralize everything but the question is this all we need to have here .... i do not think so. Best, R. On Mar 8, 2015 8:06 PM, "Gregory Mirsky" wrote: Hi Robert, early in MPLS, I think, we all played with what=E2=80=99s called Static LSP= . Later they came back as LSP in MPLS-TP without a control plane. To me that is how one sets the MPLS data plane without any control protocol but configuring cross-connects LSR by LSR. Regards, Greg *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert Raszuk *Sent:* Sunday, March 08, 2015 12:03 PM *To:* Gregory Mirsky *Cc:* Himanshu Shah; teas@ietf.org; Loa Andersson; mpls@ietf.org *Subject:* RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang Whow .. i think we are discovering that we all have no clue what Yang model is :) That is in fact I think great discussion to have sooner then later. To me Yang model is a way to represent unified (across inplementations) picture of control plane for a given network application. It has nothing to do with data plane to the extend of avoiding lock-in to mpls or ipv4 or ipv6. The attempt to generalize LSP would be equivalent to generalize Routing regardless if this is IGP or BGP or TRILL ... the outcome of that would be rather poor I suppose ... Cheers, R. On Mar 8, 2015 7:48 PM, "Gregory Mirsky" wrote: Hi Robert, et. al, if I interpret the =E2=80=9CLSP YANG model=E2=80=9D, then it reads as YANG = model of MPLS data plane, not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of SPRING. And, since the MPLS data plane is indeed common and in fact the one and only, such LSP YANG model rightfully can be characterized as =E2=80=9CG= eneric=E2=80=9D. But if authors intended to describe common set among listed above control protocols pertaining to signaling of an MPLS LSP, then, IMO, such common set first must be discussed and identified to demonstrate that it does exist and is sufficient to have YANG model of its own rather than YANG models that describe LSP control by each signaling protocols. That to me looks very much like what LIME WG is working on, investigating whether common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its extent is sufficient to be of interest. Regards, Greg *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Robert Raszuk *Sent:* Sunday, March 08, 2015 3:58 AM *To:* Loa Andersson *Cc:* mpls@ietf.org; teas@ietf.org; Shah, Himanshu *Subject:* Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang Hi Loa, The way I read Igor statement and agreed with it in a sense of "nothing in common" was that it was referring to the control plane. The subject of this thread is "Generic LSP YANG" and to me Yang model describes control aspect of protocol or functionality not the choice of forwarding header in the data plane. So if you and others agree we should be all in sync and perhaps we could consider as proposed before Generic Engineered Path model branching at the lower layer between unicast and multicast. However if you still think that Yang is about data plane and OAM then perhaps we have a bigger issue here .... Cheers, R. On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson wrote: Himanshu, et.al., I think there are two issues here and if sorting them out corrrectly we are very close. The first issue is similarities between different types of LSPs. Here I said that, at least for a MPLS PSN, there are similarities, e.g. the data plane is (nearly) the same. This was said in reaction to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common." I still don't think that Igor's statement is really correct. If he had said "IMHO there are not enough similarites between TE-LSP, LDP-LSP and SPRING-LSP to motivate a common model". I think that we be a much more accurate statement. And that is the other issue - Is it reasonable to model TE-LSP, LDP-LSP and SPRING-LSP in the same model? I don't not think it is, but that we need an overlap of people working with the different models. Hope this is clear enough. /Loa On 2015-03-07 23:19, Shah, Himanshu wrote: /I agree with Robert and Igor, putting everything in the same bucket because of common data plane & OAM does not justify./ /We wouldn=E2=80=99t consider doing same for IP data plane../ /I think we need to separate these models and as mentioned earlier, there is already work going on in respective WGs./ // /Thanks,/ /himanshu/ // // // *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson *Sent:* Saturday, March 07, 2015 8:18 AM *To:* teas@ietf.org, mpls@ietf.org, robert@raszuk.net *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang Robert, From one perspective I agree with you and Igor, however if you think about MPLS LSPs, from a data plane perspective - and that is where OAM operates, there almost no difference between a TE-LSP a LDP-LSP and a SPRING MPLS LSP come very close. If you the other hand think of LSPs for other data planes the "nothing in common" is an almost true statement. From that point of view I think different models are where we will end up, but I also think that we need "separation with moderation". But nothing is so simple that we can capture it in one very simple statement, we have hacking away on this for 30 years now, I'd advice taking architecture and history into consideration, as well as viewing the sky from a different perspective than from the bottom of a deep well. Let me also say that I'm very supportive of all the good work going on in this area. /Loa Sent from my iPad On 07 Mar 2015, at 19:47, Robert Raszuk > wrote: I would agree with Igor. Other then name overlap those are completely different technologies and artificially putting them under "LSP" umbrella just does not bring any value, but only confuses things even more. Q: What SPRING-LSP has anything in common with "label" when you use v6 header ? If you want to search for some commonalities let's remove LDP-LSPs from this mix (as the is not relevant) and leave TE-LSP & SPRING + maybe also add BIER as well as change the name to Generic-EP (Engineered Paths). I see no value of goruping based on the fact that data plane uses mpls labels, but rather I would see reasonable to provide models based on the transport path characteristics for the traffic it is to carry. Best, r. On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin > wrote: Druv, IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They should have totally independent models each being developed in respective WG. Igor _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --001a113ed3f8fc47350510cc158e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I beg you pardon but i have never seen static LSPs really in= production use .. that means being configured hop by hop by cli.

For the recird I have started my MPLS days with TDP in aroun= d 1997 :)

So what it means for this duscussion? Are you proposing say = for RSVP-TE to push labels hop by hop or you would rather see Yang represen= ting ERO as part of it ?

I think no one says we can not have Yang model for static la= bels and centralize everything but the question is this all we need to have= here .... i do not think so.

Best,
R.

On Mar 8, 2015 8:06 PM, "Gregory Mirsky&quo= t; <gregory.mirsky@ericss= on.com> wrote:

Hi Robert,<= /span>

early in MPLS, I think, w= e all played with what=E2=80=99s called Static LSP. Later they came back as= LSP in MPLS-TP without a control plane. To me that is how one sets the MPLS data plane without any control protocol but configuring cross-con= nects LSR by LSR.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 12:03 PM
To: Gregory Mirsky
Cc: Himanshu Shah; teas@ietf.org; Loa Andersson; mpls@ietf.org
Subject: RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

Whow .. i think we are discovering that we all have no clue what Yang mo= del is :)

That is in fact I think great discussion to have sooner then later.

To me Yang model is a way to represent unified (across inplementations) = picture of control plane for a given network application.

It has nothing to do with data plane to the extend of avoiding lock-in t= o mpls or ipv4 or ipv6.

The attempt to generalize LSP would be equivalent to generalize Routing = regardless if this is IGP or BGP or TRILL ... the outcome of that would be = rather poor I suppose ...

Cheers,
R.

On Mar 8, 2015 7:48 PM, "Gregory Mirsky" &= lt;gregory= .mirsky@ericsson.com> wrote:

Hi Robert, et. al,=

if I interpret the =E2=80= =9CLSP YANG model=E2=80=9D, then it reads as YANG model of MPLS data plane,= not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of SPRING. And, since the MP= LS data plane is indeed common and in fact the one and only, such LSP YANG = model rightfully can be characterized as =E2=80=9CGeneric=E2=80=9D.<= u>

But if authors intended t= o describe common set among listed above control protocols pertaining to signaling of an MPLS LSP, then, IMO, such common set first must be discuss= ed and identified to demonstrate that it does exist and is sufficient to ha= ve YANG model of its own rather than YANG models that describe LSP control = by each signaling protocols. That to me looks very much like what LIME WG is working on, investigating wheth= er common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its exten= t is sufficient to be of interest.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Teas [ma= ilto:teas-bounce= s@ietf.org] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 3:58 AM
To: Loa Andersson
Cc: mpls@ietf.org= ; teas@ietf.org; Shah, Himanshu
Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

= Hi Loa,

= =C2=A0

= The way I read Igor statement and agreed with it in a sense of "nothin= g in common" was that it was referring to the control plane.=C2=A0

= =C2=A0

= The subject of this thread is "Generic LSP YANG" and to me Yang m= odel describes control aspect of protocol or functionality not the choice of forwarding header in the data plane.=C2=A0

= =C2=A0

= So if you and others agree we should be all in sync and perhaps we could co= nsider as proposed before Generic Engineered Path model branching at the lower layer between unicast and multicast.=C2=A0

= =C2=A0

= However if you still think that Yang is about data plane and OAM then perha= ps we have a bigger issue here ....

= =C2=A0

= Cheers,
R.

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrote:

Himanshu, et.al.,

I think there are two issues here and if sorting them out corrrectly
we are very close.

The first issue is similarities between different types of LSPs.

Here I said that, at least for a MPLS PSN, there are similarities,
e.g. the data plane is (nearly) the same. This was said in reaction
to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have noth= ing
in common." I still don't think that Igor's statement is reall= y correct.
If he had said "IMHO there are not enough similarites between TE-LSP,<= br> LDP-LSP and SPRING-LSP to motivate a common model". I think that we be=
a much more accurate statement.

And that is the other issue - Is it reasonable to model TE-LSP,
LDP-LSP and SPRING-LSP in the same model? I don't not think it is,
but that we need an overlap of people working with the different models.
Hope this is clear enough.

/Loa


On 2015-03-07 23:19, Shah, Himanshu wrote:

/I agree with Robert = and Igor, putting everything in the same bucket
because of common data plane & OAM does not justify./

/We wouldn=E2=80=99t consider doing same for IP data plane../

/I think we need to separate these models and as mentioned earlier,
there is already work going on in respective WGs./

//

/Thanks,/

/himanshu/

//

//

//

*From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson
*Sent:* Saturday, March 07, 2015 8:18 AM
*To:* teas@ietf.org,= mpls@ietf.org, r= obert@raszuk.net
*Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang

Robert,

=C2=A0From one perspective I agree with you and Igor, however if you think<= br> about MPLS LSPs, from a data plane perspective - and that is where OAM
operates, there almost no difference between a TE-LSP a LDP-LSP and a
SPRING MPLS LSP come very close.

If you the other hand think of LSPs for other data planes the "nothing=
in common" is an almost true statement. From that point of view I thin= k
different models are where we will end up, but I also think that we need "separation with moderation".

=C2=A0 But nothing is so simple that we can capture it in one very simple statement, we have hacking away on this for 30 years now, I'd advice taking architecture and history into consideration, as well as viewing
the sky from a different perspective than from the bottom of a deep well.
Let me also say that I'm very supportive of all the good work going on<= br> in this area.

/Loa

Sent from my iPad


On 07 Mar 2015, at 19:47, Robert Raszuk <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

=C2=A0 =C2=A0 I would agree with Igor.

=C2=A0 =C2=A0 Other then name overlap those are completely different techno= logies
=C2=A0 =C2=A0 and artificially putting them under "LSP" umbrella = just does not
=C2=A0 =C2=A0 bring any value, but only confuses things even more.

=C2=A0 =C2=A0 Q: What SPRING-LSP has anything in common with "label&qu= ot; when you use
=C2=A0 =C2=A0 v6 header ?

=C2=A0 =C2=A0 If you want to search for some commonalities let's remove= LDP-LSPs
=C2=A0 =C2=A0 from this mix (as the is not relevant) and leave TE-LSP &= SPRING +
=C2=A0 =C2=A0 maybe also add BIER as well as change the name to Generic-EP<= br> =C2=A0 =C2=A0 (Engineered Paths).

=C2=A0 =C2=A0 I see no value of goruping based on the fact that data plane = uses
=C2=A0 =C2=A0 mpls labels, but rather I would see reasonable to provide mod= els
=C2=A0 =C2=A0 based on the transport path characteristics for the traffic i= t is to
=C2=A0 =C2=A0 carry.

=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 r.

=C2=A0 =C2=A0 On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin
=C2=A0 =C2=A0 <IBryskin@advaoptical.com <mailto:IBryskin@advaoptical.com>> wrote:=

=C2=A0 =C2=A0 Druv,

=C2=A0 =C2=A0 IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. T= hey
=C2=A0 =C2=A0 should have totally independent models each being developed i= n
=C2=A0 =C2=A0 respective WG.

=C2=A0 =C2=A0 Igor

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Rtg-yang-coord mailing list
=C2=A0 =C2=A0 = Rtg-yang-coord@ietf.org <mailto:Rtg-yang-coord@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtg-yang-coord



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0

--001a113ed3f8fc47350510cc158e-- From nobody Sun Mar 8 12:42:09 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9241A00FA; Sun, 8 Mar 2015 12:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKRxrHwzH25k; Sun, 8 Mar 2015 12:42:02 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E201A00F3; Sun, 8 Mar 2015 12:42:02 -0700 (PDT) Received: by iecrd18 with SMTP id rd18so7050839iec.12; Sun, 08 Mar 2015 12:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HdZ9kAc/f6SMhF/cbkM9sk37+HxVHnosvm3yaf0PGBo=; b=l+y7raX2Z9dL0tkmbBydMci5HPG7BdcXNBqGn1rzRkEuz5eGSVnVYUdREScP4jmR4j UYUI1sq83FDvP3kxnHxw7RrQH9Ji2QLP+TrQhufhNhfkBO8CAEVV6VI69ebcZ84owCou ry0hXHJC2hHy1juc2OmD+USKrbwPgCTm23T8M0g1nesfHDqCWgBMEN0vXKq4ISURpLMx LeeQLuxmBeWDFg/vcxHweDBLbuk7yUtw/w8VOr9uSrpG2/vFpZnaQwSxq/VQMyN/cwHF k3ysqVLLWUF6bev2V0a82WW+GcytLNZEwxJogHk/1wnEqa7J2K5+v+9yxZhWbJ6zivh4 vWug== MIME-Version: 1.0 X-Received: by 10.107.47.90 with SMTP id j87mr40464345ioo.33.1425843722181; Sun, 08 Mar 2015 12:42:02 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 12:42:02 -0700 (PDT) Received: by 10.107.136.156 with HTTP; Sun, 8 Mar 2015 12:42:02 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91C1B1@eusaamb103.ericsson.se> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B91C1B1@eusaamb103.ericsson.se> Date: Sun, 8 Mar 2015 20:42:02 +0100 X-Google-Sender-Auth: PBeaoKpmQwUmiAoNWlxYrlpEB6o Message-ID: From: Robert Raszuk To: Gregory Mirsky Content-Type: multipart/alternative; boundary=001a11c158a890e7950510cc1c7e Archived-At: Cc: "mpls@ietf.org" , Himanshu Shah , teas@ietf.org, Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 19:42:06 -0000 --001a11c158a890e7950510cc1c7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I suggest that today we know (well we knew even in 2000) how to do TE with IP without MPLS ... Thx, R. On Mar 8, 2015 8:34 PM, "Gregory Mirsky" wrote: > Hi Robert, > > are you suggesting that an LSP, i.e. Label Switched Path, can be realized > over IPv4 or IPv6 data plane: > > It has nothing to do with data plane to the extend of avoiding lock-in to > mpls or ipv4 or ipv6. > > > > Regards, > > Greg > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Sunday, March 08, 2015 12:03 PM > *To:* Gregory Mirsky > *Cc:* Himanshu Shah; teas@ietf.org; Loa Andersson; mpls@ietf.org > *Subject:* RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang > > > > Whow .. i think we are discovering that we all have no clue what Yang > model is :) > > That is in fact I think great discussion to have sooner then later. > > To me Yang model is a way to represent unified (across inplementations) > picture of control plane for a given network application. > > It has nothing to do with data plane to the extend of avoiding lock-in to > mpls or ipv4 or ipv6. > > The attempt to generalize LSP would be equivalent to generalize Routing > regardless if this is IGP or BGP or TRILL ... the outcome of that would b= e > rather poor I suppose ... > > Cheers, > R. > > On Mar 8, 2015 7:48 PM, "Gregory Mirsky" > wrote: > > Hi Robert, et. al, > > if I interpret the =E2=80=9CLSP YANG model=E2=80=9D, then it reads as YAN= G model of MPLS > data plane, not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of > SPRING. And, since the MPLS data plane is indeed common and in fact the o= ne > and only, such LSP YANG model rightfully can be characterized as =E2=80= =9CGeneric=E2=80=9D. > > But if authors intended to describe common set among listed above control > protocols pertaining to signaling of an MPLS LSP, then, IMO, such common > set first must be discussed and identified to demonstrate that it does > exist and is sufficient to have YANG model of its own rather than YANG > models that describe LSP control by each signaling protocols. That to me > looks very much like what LIME WG is working on, investigating whether > common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its extent > is sufficient to be of interest. > > > > Regards, > > Greg > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Sunday, March 08, 2015 3:58 AM > *To:* Loa Andersson > *Cc:* mpls@ietf.org; teas@ietf.org; Shah, Himanshu > *Subject:* Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang > > > > Hi Loa, > > > > The way I read Igor statement and agreed with it in a sense of "nothing i= n > common" was that it was referring to the control plane. > > > > The subject of this thread is "Generic LSP YANG" and to me Yang model > describes control aspect of protocol or functionality not the choice of > forwarding header in the data plane. > > > > So if you and others agree we should be all in sync and perhaps we could > consider as proposed before Generic Engineered Path model branching at th= e > lower layer between unicast and multicast. > > > > However if you still think that Yang is about data plane and OAM then > perhaps we have a bigger issue here .... > > > > Cheers, > R. > > > > > > > > > > On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson wrote: > > Himanshu, et.al., > > I think there are two issues here and if sorting them out corrrectly > we are very close. > > The first issue is similarities between different types of LSPs. > > Here I said that, at least for a MPLS PSN, there are similarities, > e.g. the data plane is (nearly) the same. This was said in reaction > to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing > in common." I still don't think that Igor's statement is really correct. > If he had said "IMHO there are not enough similarites between TE-LSP, > LDP-LSP and SPRING-LSP to motivate a common model". I think that we be > a much more accurate statement. > > And that is the other issue - Is it reasonable to model TE-LSP, > LDP-LSP and SPRING-LSP in the same model? I don't not think it is, > but that we need an overlap of people working with the different models. > > Hope this is clear enough. > > /Loa > > > On 2015-03-07 23:19, Shah, Himanshu wrote: > > /I agree with Robert and Igor, putting everything in the same bucket > because of common data plane & OAM does not justify./ > > /We wouldn=E2=80=99t consider doing same for IP data plane../ > > /I think we need to separate these models and as mentioned earlier, > there is already work going on in respective WGs./ > > // > > /Thanks,/ > > /himanshu/ > > // > > // > > // > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson > *Sent:* Saturday, March 07, 2015 8:18 AM > *To:* teas@ietf.org, mpls@ietf.org, robert@raszuk.net > *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang > > Robert, > > From one perspective I agree with you and Igor, however if you think > about MPLS LSPs, from a data plane perspective - and that is where OAM > operates, there almost no difference between a TE-LSP a LDP-LSP and a > SPRING MPLS LSP come very close. > > If you the other hand think of LSPs for other data planes the "nothing > in common" is an almost true statement. From that point of view I think > different models are where we will end up, but I also think that we need > "separation with moderation". > > But nothing is so simple that we can capture it in one very simple > statement, we have hacking away on this for 30 years now, I'd advice > taking architecture and history into consideration, as well as viewing > the sky from a different perspective than from the bottom of a deep well. > > Let me also say that I'm very supportive of all the good work going on > in this area. > > /Loa > > Sent from my iPad > > > On 07 Mar 2015, at 19:47, Robert Raszuk > wrote: > > I would agree with Igor. > > Other then name overlap those are completely different technologies > and artificially putting them under "LSP" umbrella just does not > bring any value, but only confuses things even more. > > Q: What SPRING-LSP has anything in common with "label" when you use > v6 header ? > > If you want to search for some commonalities let's remove LDP-LSPs > from this mix (as the is not relevant) and leave TE-LSP & SPRING + > maybe also add BIER as well as change the name to Generic-EP > (Engineered Paths). > > I see no value of goruping based on the fact that data plane uses > mpls labels, but rather I would see reasonable to provide models > based on the transport path characteristics for the traffic it is to > carry. > > Best, > > r. > > On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin > > wrote: > > Druv, > > IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They > should have totally independent models each being developed in > respective WG. > > Igor > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --001a11c158a890e7950510cc1c7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I suggest that today we know (well we knew even in 2000) how= to do TE with IP without MPLS ...

Thx,
R.

On Mar 8, 2015 8:34 PM, "Gregory Mirsky&quo= t; <gregory.mirsky@ericss= on.com> wrote:

Hi Robert,<= /span>

are you suggesting that a= n LSP, i.e. Label Switched Path, can be realized over IPv4 or IPv6 data pla= ne:

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 12:03 PM
To: Gregory Mirsky
Cc: Himanshu Shah; teas@ietf.org; Loa Andersson; mpls@ietf.org
Subject: RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

Whow .. i think we are discovering that we all have no clue what Yang mo= del is :)

That is in fact I think great discussion to have sooner then later.

To me Yang model is a way to represent unified (across inplementations) = picture of control plane for a given network application.

It has nothing to do with data plane to the extend of avoiding lock-in t= o mpls or ipv4 or ipv6.

The attempt to generalize LSP would be equivalent to generalize Routing = regardless if this is IGP or BGP or TRILL ... the outcome of that would be = rather poor I suppose ...

Cheers,
R.

On Mar 8, 2015 7:48 PM, "Gregory Mirsky" &= lt;gregory= .mirsky@ericsson.com> wrote:

Hi Robert, et. al,=

if I interpret the =E2=80= =9CLSP YANG model=E2=80=9D, then it reads as YANG model of MPLS data plane,= not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of SPRING. And, since the MP= LS data plane is indeed common and in fact the one and only, such LSP YANG = model rightfully can be characterized as =E2=80=9CGeneric=E2=80=9D.<= u>

But if authors intended t= o describe common set among listed above control protocols pertaining to signaling of an MPLS LSP, then, IMO, such common set first must be discuss= ed and identified to demonstrate that it does exist and is sufficient to ha= ve YANG model of its own rather than YANG models that describe LSP control = by each signaling protocols. That to me looks very much like what LIME WG is working on, investigating wheth= er common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its exten= t is sufficient to be of interest.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Teas [ma= ilto:teas-bounce= s@ietf.org] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 3:58 AM
To: Loa Andersson
Cc: mpls@ietf.org= ; teas@ietf.org; Shah, Himanshu
Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

= Hi Loa,

= =C2=A0

= The way I read Igor statement and agreed with it in a sense of "nothin= g in common" was that it was referring to the control plane.=C2=A0

= =C2=A0

= The subject of this thread is "Generic LSP YANG" and to me Yang m= odel describes control aspect of protocol or functionality not the choice of forwarding header in the data plane.=C2=A0

= =C2=A0

= So if you and others agree we should be all in sync and perhaps we could co= nsider as proposed before Generic Engineered Path model branching at the lower layer between unicast and multicast.=C2=A0

= =C2=A0

= However if you still think that Yang is about data plane and OAM then perha= ps we have a bigger issue here ....

= =C2=A0

= Cheers,
R.

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrote:

Himanshu, et.al.,

I think there are two issues here and if sorting them out corrrectly
we are very close.

The first issue is similarities between different types of LSPs.

Here I said that, at least for a MPLS PSN, there are similarities,
e.g. the data plane is (nearly) the same. This was said in reaction
to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have noth= ing
in common." I still don't think that Igor's statement is reall= y correct.
If he had said "IMHO there are not enough similarites between TE-LSP,<= br> LDP-LSP and SPRING-LSP to motivate a common model". I think that we be=
a much more accurate statement.

And that is the other issue - Is it reasonable to model TE-LSP,
LDP-LSP and SPRING-LSP in the same model? I don't not think it is,
but that we need an overlap of people working with the different models.
Hope this is clear enough.

/Loa


On 2015-03-07 23:19, Shah, Himanshu wrote:

/I agree with Robert = and Igor, putting everything in the same bucket
because of common data plane & OAM does not justify./

/We wouldn=E2=80=99t consider doing same for IP data plane../

/I think we need to separate these models and as mentioned earlier,
there is already work going on in respective WGs./

//

/Thanks,/

/himanshu/

//

//

//

*From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson
*Sent:* Saturday, March 07, 2015 8:18 AM
*To:* teas@ietf.org,= mpls@ietf.org, r= obert@raszuk.net
*Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang

Robert,

=C2=A0From one perspective I agree with you and Igor, however if you think<= br> about MPLS LSPs, from a data plane perspective - and that is where OAM
operates, there almost no difference between a TE-LSP a LDP-LSP and a
SPRING MPLS LSP come very close.

If you the other hand think of LSPs for other data planes the "nothing=
in common" is an almost true statement. From that point of view I thin= k
different models are where we will end up, but I also think that we need "separation with moderation".

=C2=A0 But nothing is so simple that we can capture it in one very simple statement, we have hacking away on this for 30 years now, I'd advice taking architecture and history into consideration, as well as viewing
the sky from a different perspective than from the bottom of a deep well.
Let me also say that I'm very supportive of all the good work going on<= br> in this area.

/Loa

Sent from my iPad


On 07 Mar 2015, at 19:47, Robert Raszuk <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

=C2=A0 =C2=A0 I would agree with Igor.

=C2=A0 =C2=A0 Other then name overlap those are completely different techno= logies
=C2=A0 =C2=A0 and artificially putting them under "LSP" umbrella = just does not
=C2=A0 =C2=A0 bring any value, but only confuses things even more.

=C2=A0 =C2=A0 Q: What SPRING-LSP has anything in common with "label&qu= ot; when you use
=C2=A0 =C2=A0 v6 header ?

=C2=A0 =C2=A0 If you want to search for some commonalities let's remove= LDP-LSPs
=C2=A0 =C2=A0 from this mix (as the is not relevant) and leave TE-LSP &= SPRING +
=C2=A0 =C2=A0 maybe also add BIER as well as change the name to Generic-EP<= br> =C2=A0 =C2=A0 (Engineered Paths).

=C2=A0 =C2=A0 I see no value of goruping based on the fact that data plane = uses
=C2=A0 =C2=A0 mpls labels, but rather I would see reasonable to provide mod= els
=C2=A0 =C2=A0 based on the transport path characteristics for the traffic i= t is to
=C2=A0 =C2=A0 carry.

=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 r.

=C2=A0 =C2=A0 On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin
=C2=A0 =C2=A0 <IBryskin@advaoptical.com <mailto:IBryskin@advaoptical.com>> wrote:=

=C2=A0 =C2=A0 Druv,

=C2=A0 =C2=A0 IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. T= hey
=C2=A0 =C2=A0 should have totally independent models each being developed i= n
=C2=A0 =C2=A0 respective WG.

=C2=A0 =C2=A0 Igor

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Rtg-yang-coord mailing list
=C2=A0 =C2=A0 = Rtg-yang-coord@ietf.org <mailto:Rtg-yang-coord@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtg-yang-coord



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0

--001a11c158a890e7950510cc1c7e-- From nobody Sun Mar 8 13:11:46 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30DE1A012D; Sun, 8 Mar 2015 13:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFFyp2m_vypG; Sun, 8 Mar 2015 13:11:41 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B9B1A00FA; Sun, 8 Mar 2015 13:11:41 -0700 (PDT) X-AuditID: c6180641-f796f6d000004ccc-f7-54fc4be544fb Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2A.01.19660.5EB4CF45; Sun, 8 Mar 2015 14:17:26 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Sun, 8 Mar 2015 16:11:38 -0400 From: Gregory Mirsky To: Robert Raszuk Thread-Topic: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWY7Le4cVv75dNkqZzU3p3HVhN50S6nlAgABKdQD//8UFYIAAReMA///El/A= Date: Sun, 8 Mar 2015 20:11:37 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91C1E8@eusaamb103.ericsson.se> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B91C1B1@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B91C1E8eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXSPn+4z7z8hBv8nclns2ria0eLf3DnM FreWrmS1aFrYxGzR+mMHiwOrx9mb/1g8liz5yeQxa3obm8fujQuYAliiuGxSUnMyy1KL9O0S uDKebp/KUrDnBFPF5H+XmRoYP+xn6mLk5JAQMJGYdnwvlC0mceHeerYuRi4OIYEjjBI71kxi gXCWMUpcPLmCGaSKTcBI4sXGHnYQW0RAVaLzxCNmkCJmgRZGiQenNzCCJIQFbCTOvZnBCFFk K7Gv+T0zhO0ncWzmQbB1LAIqEo93fwEbxCvgK7Fk/yVmiG3r2CROr/kA1MzBwSkQKHFhhRJI DSPQed9PrQHrZRYQl7j1ZD7U2QISS/acZ4awRSVePv7HCmErScx5fY0Zoj5fYteMrYwQuwQl Ts58wjKBUXQWklGzkJTNQlI2C+gKZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KkaO0 OLUsN93IcBMjMBqPSbA57mBc8MnyEKMAB6MSD6/B7t8hQqyJZcWVuYcYpTlYlMR5y64cDBES SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAKKW5e07IpjPZ0/+Z/bmvNbf5XUKXtIzh4ZdvG5Z8 Pfi1+4f7zNNrdzSfu6JZqhPpOHHXp+C4k8t/66c3vfonHrdmzYeAizzCXIu3bji0cJ/1ydsL V+WuE33lt6J2/+91XPzs7ul/2zY3uDCUVykpJ1csvHueeaFv9gnF4yJBSf9ynBhfPnZdYqLE UpyRaKjFXFScCAAUbskMpwIAAA== Archived-At: Cc: "mpls@ietf.org" , Himanshu Shah , "teas@ietf.org" , Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 20:11:44 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B91C1E8eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGluIFNQUklORyB3ZeKAmXZlIGJlZW4gYXJvdW5kIHRoYXQgZGlzY3Vzc2lv biBhbmQgaGFkIGNvbmNsdWRlZCB0aGF0IElQdjQgaXMgb3V0IG9mIHNjb3BlIGZvciBhbiBleHBs aWNpdGx5IHJvdXRlZCBwYXRoLiBZb3UgcHJvcG9zZSB0byByZS1vcGVuIHRoYXQgZGlzY3Vzc2lv bj8NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEdyZWcNCg0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdt YWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFN1bmRheSwgTWFyY2gg MDgsIDIwMTUgMTI6NDIgUE0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IHRlYXNAaWV0Zi5vcmc7 IEhpbWFuc2h1IFNoYWg7IExvYSBBbmRlcnNzb247IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbVGVhc10gW21wbHNdIFtSdGcteWFuZy1jb29yZF0gR2VuZXJpYyBMU1AgWWFuZw0KDQoNCkkg c3VnZ2VzdCB0aGF0IHRvZGF5IHdlIGtub3cgKHdlbGwgd2Uga25ldyBldmVuIGluIDIwMDApIGhv dyB0byBkbyBURSB3aXRoIElQIHdpdGhvdXQgTVBMUyAuLi4NCg0KVGh4LA0KUi4NCk9uIE1hciA4 LCAyMDE1IDg6MzQgUE0sICJHcmVnb3J5IE1pcnNreSIgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29u LmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBSb2Jl cnQsDQphcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCBhbiBMU1AsIGkuZS4gTGFiZWwgU3dpdGNoZWQg UGF0aCwgY2FuIGJlIHJlYWxpemVkIG92ZXIgSVB2NCBvciBJUHY2IGRhdGEgcGxhbmU6DQpJdCBo YXMgbm90aGluZyB0byBkbyB3aXRoIGRhdGEgcGxhbmUgdG8gdGhlIGV4dGVuZCBvZiBhdm9pZGlu ZyBsb2NrLWluIHRvIG1wbHMgb3IgaXB2NCBvciBpcHY2Lg0KDQogICAgICAgICAgICAgICAgUmVn YXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBycmFz enVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IFttYWlsdG86cnJhc3p1a0Bn bWFpbC5jb208bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tPl0gT24gQmVoYWxmIE9mIFJvYmVydCBS YXN6dWsNClNlbnQ6IFN1bmRheSwgTWFyY2ggMDgsIDIwMTUgMTI6MDMgUE0NClRvOiBHcmVnb3J5 IE1pcnNreQ0KQ2M6IEhpbWFuc2h1IFNoYWg7IHRlYXNAaWV0Zi5vcmc8bWFpbHRvOnRlYXNAaWV0 Zi5vcmc+OyBMb2EgQW5kZXJzc29uOyBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3Jn Pg0KU3ViamVjdDogUkU6IFtUZWFzXSBbbXBsc10gW1J0Zy15YW5nLWNvb3JkXSBHZW5lcmljIExT UCBZYW5nDQoNCg0KV2hvdyAuLiBpIHRoaW5rIHdlIGFyZSBkaXNjb3ZlcmluZyB0aGF0IHdlIGFs bCBoYXZlIG5vIGNsdWUgd2hhdCBZYW5nIG1vZGVsIGlzIDopDQoNClRoYXQgaXMgaW4gZmFjdCBJ IHRoaW5rIGdyZWF0IGRpc2N1c3Npb24gdG8gaGF2ZSBzb29uZXIgdGhlbiBsYXRlci4NCg0KVG8g bWUgWWFuZyBtb2RlbCBpcyBhIHdheSB0byByZXByZXNlbnQgdW5pZmllZCAoYWNyb3NzIGlucGxl bWVudGF0aW9ucykgcGljdHVyZSBvZiBjb250cm9sIHBsYW5lIGZvciBhIGdpdmVuIG5ldHdvcmsg YXBwbGljYXRpb24uDQoNCkl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggZGF0YSBwbGFuZSB0byB0 aGUgZXh0ZW5kIG9mIGF2b2lkaW5nIGxvY2staW4gdG8gbXBscyBvciBpcHY0IG9yIGlwdjYuDQoN ClRoZSBhdHRlbXB0IHRvIGdlbmVyYWxpemUgTFNQIHdvdWxkIGJlIGVxdWl2YWxlbnQgdG8gZ2Vu ZXJhbGl6ZSBSb3V0aW5nIHJlZ2FyZGxlc3MgaWYgdGhpcyBpcyBJR1Agb3IgQkdQIG9yIFRSSUxM IC4uLiB0aGUgb3V0Y29tZSBvZiB0aGF0IHdvdWxkIGJlIHJhdGhlciBwb29yIEkgc3VwcG9zZSAu Li4NCg0KQ2hlZXJzLA0KUi4NCk9uIE1hciA4LCAyMDE1IDc6NDggUE0sICJHcmVnb3J5IE1pcnNr eSIgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQpIaSBSb2JlcnQsIGV0LiBhbCwNCmlmIEkgaW50ZXJwcmV0IHRo ZSDigJxMU1AgWUFORyBtb2RlbOKAnSwgdGhlbiBpdCByZWFkcyBhcyBZQU5HIG1vZGVsIG9mIE1Q TFMgZGF0YSBwbGFuZSwgbm90IGNvbnRyb2wgcHJvdG9jb2wsIGJlIGl0IFJTVlAtVEUsIExEUCwg UENFUCwgb3IgSUdQLVRFIG9mIFNQUklORy4gQW5kLCBzaW5jZSB0aGUgTVBMUyBkYXRhIHBsYW5l IGlzIGluZGVlZCBjb21tb24gYW5kIGluIGZhY3QgdGhlIG9uZSBhbmQgb25seSwgc3VjaCBMU1Ag WUFORyBtb2RlbCByaWdodGZ1bGx5IGNhbiBiZSBjaGFyYWN0ZXJpemVkIGFzIOKAnEdlbmVyaWPi gJ0uDQpCdXQgaWYgYXV0aG9ycyBpbnRlbmRlZCB0byBkZXNjcmliZSBjb21tb24gc2V0IGFtb25n IGxpc3RlZCBhYm92ZSBjb250cm9sIHByb3RvY29scyBwZXJ0YWluaW5nIHRvIHNpZ25hbGluZyBv ZiBhbiBNUExTIExTUCwgdGhlbiwgSU1PLCBzdWNoIGNvbW1vbiBzZXQgZmlyc3QgbXVzdCBiZSBk aXNjdXNzZWQgYW5kIGlkZW50aWZpZWQgdG8gZGVtb25zdHJhdGUgdGhhdCBpdCBkb2VzIGV4aXN0 IGFuZCBpcyBzdWZmaWNpZW50IHRvIGhhdmUgWUFORyBtb2RlbCBvZiBpdHMgb3duIHJhdGhlciB0 aGFuIFlBTkcgbW9kZWxzIHRoYXQgZGVzY3JpYmUgTFNQIGNvbnRyb2wgYnkgZWFjaCBzaWduYWxp bmcgcHJvdG9jb2xzLiBUaGF0IHRvIG1lIGxvb2tzIHZlcnkgbXVjaCBsaWtlIHdoYXQgTElNRSBX RyBpcyB3b3JraW5nIG9uLCBpbnZlc3RpZ2F0aW5nIHdoZXRoZXIgY29tbW9uIG1vZGVsIG9mIElQ LCBJUC9NUExTLCBNUExTLVRQLCBhbmQgVFJJTEwgT0FNIGV4aXN0cyBhbmQgaXRzIGV4dGVudCBp cyBzdWZmaWNpZW50IHRvIGJlIG9mIGludGVyZXN0Lg0KDQogICAgICAgICAgICAgICAgUmVnYXJk cywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpGcm9tOiBUZWFzIFtt YWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogU3VuZGF5LCBNYXJjaCAwOCwgMjAx NSAzOjU4IEFNDQpUbzogTG9hIEFuZGVyc3Nvbg0KQ2M6IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+OyB0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3JnPjsgU2hhaCwg SGltYW5zaHUNClN1YmplY3Q6IFJlOiBbVGVhc10gW21wbHNdIFtSdGcteWFuZy1jb29yZF0gR2Vu ZXJpYyBMU1AgWWFuZw0KDQpIaSBMb2EsDQoNClRoZSB3YXkgSSByZWFkIElnb3Igc3RhdGVtZW50 IGFuZCBhZ3JlZWQgd2l0aCBpdCBpbiBhIHNlbnNlIG9mICJub3RoaW5nIGluIGNvbW1vbiIgd2Fz IHRoYXQgaXQgd2FzIHJlZmVycmluZyB0byB0aGUgY29udHJvbCBwbGFuZS4NCg0KVGhlIHN1Ympl Y3Qgb2YgdGhpcyB0aHJlYWQgaXMgIkdlbmVyaWMgTFNQIFlBTkciIGFuZCB0byBtZSBZYW5nIG1v ZGVsIGRlc2NyaWJlcyBjb250cm9sIGFzcGVjdCBvZiBwcm90b2NvbCBvciBmdW5jdGlvbmFsaXR5 IG5vdCB0aGUgY2hvaWNlIG9mIGZvcndhcmRpbmcgaGVhZGVyIGluIHRoZSBkYXRhIHBsYW5lLg0K DQpTbyBpZiB5b3UgYW5kIG90aGVycyBhZ3JlZSB3ZSBzaG91bGQgYmUgYWxsIGluIHN5bmMgYW5k IHBlcmhhcHMgd2UgY291bGQgY29uc2lkZXIgYXMgcHJvcG9zZWQgYmVmb3JlIEdlbmVyaWMgRW5n aW5lZXJlZCBQYXRoIG1vZGVsIGJyYW5jaGluZyBhdCB0aGUgbG93ZXIgbGF5ZXIgYmV0d2VlbiB1 bmljYXN0IGFuZCBtdWx0aWNhc3QuDQoNCkhvd2V2ZXIgaWYgeW91IHN0aWxsIHRoaW5rIHRoYXQg WWFuZyBpcyBhYm91dCBkYXRhIHBsYW5lIGFuZCBPQU0gdGhlbiBwZXJoYXBzIHdlIGhhdmUgYSBi aWdnZXIgaXNzdWUgaGVyZSAuLi4uDQoNCkNoZWVycywNClIuDQoNCg0KDQoNCk9uIFN1biwgTWFy IDgsIDIwMTUgYXQgMTA6MjcgQU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9h QHBpLm51Pj4gd3JvdGU6DQpIaW1hbnNodSwgZXQuYWw8aHR0cDovL2V0LmFsPi4sDQoNCkkgdGhp bmsgdGhlcmUgYXJlIHR3byBpc3N1ZXMgaGVyZSBhbmQgaWYgc29ydGluZyB0aGVtIG91dCBjb3Jy cmVjdGx5DQp3ZSBhcmUgdmVyeSBjbG9zZS4NCg0KVGhlIGZpcnN0IGlzc3VlIGlzIHNpbWlsYXJp dGllcyBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZiBMU1BzLg0KDQpIZXJlIEkgc2FpZCB0aGF0 LCBhdCBsZWFzdCBmb3IgYSBNUExTIFBTTiwgdGhlcmUgYXJlIHNpbWlsYXJpdGllcywNCmUuZy4g dGhlIGRhdGEgcGxhbmUgaXMgKG5lYXJseSkgdGhlIHNhbWUuIFRoaXMgd2FzIHNhaWQgaW4gcmVh Y3Rpb24NCnRvIElnb3IncyBzdGF0ZW1lbnQgIklNSE8gVEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJ TkctTFNQIGhhdmUgbm90aGluZw0KaW4gY29tbW9uLiIgSSBzdGlsbCBkb24ndCB0aGluayB0aGF0 IElnb3IncyBzdGF0ZW1lbnQgaXMgcmVhbGx5IGNvcnJlY3QuDQpJZiBoZSBoYWQgc2FpZCAiSU1I TyB0aGVyZSBhcmUgbm90IGVub3VnaCBzaW1pbGFyaXRlcyBiZXR3ZWVuIFRFLUxTUCwNCkxEUC1M U1AgYW5kIFNQUklORy1MU1AgdG8gbW90aXZhdGUgYSBjb21tb24gbW9kZWwiLiBJIHRoaW5rIHRo YXQgd2UgYmUNCmEgbXVjaCBtb3JlIGFjY3VyYXRlIHN0YXRlbWVudC4NCg0KQW5kIHRoYXQgaXMg dGhlIG90aGVyIGlzc3VlIC0gSXMgaXQgcmVhc29uYWJsZSB0byBtb2RlbCBURS1MU1AsDQpMRFAt TFNQIGFuZCBTUFJJTkctTFNQIGluIHRoZSBzYW1lIG1vZGVsPyBJIGRvbid0IG5vdCB0aGluayBp dCBpcywNCmJ1dCB0aGF0IHdlIG5lZWQgYW4gb3ZlcmxhcCBvZiBwZW9wbGUgd29ya2luZyB3aXRo IHRoZSBkaWZmZXJlbnQgbW9kZWxzLg0KDQpIb3BlIHRoaXMgaXMgY2xlYXIgZW5vdWdoLg0KDQov TG9hDQoNCg0KT24gMjAxNS0wMy0wNyAyMzoxOSwgU2hhaCwgSGltYW5zaHUgd3JvdGU6DQovSSBh Z3JlZSB3aXRoIFJvYmVydCBhbmQgSWdvciwgcHV0dGluZyBldmVyeXRoaW5nIGluIHRoZSBzYW1l IGJ1Y2tldA0KYmVjYXVzZSBvZiBjb21tb24gZGF0YSBwbGFuZSAmIE9BTSBkb2VzIG5vdCBqdXN0 aWZ5Li8NCg0KL1dlIHdvdWxkbuKAmXQgY29uc2lkZXIgZG9pbmcgc2FtZSBmb3IgSVAgZGF0YSBw bGFuZS4uLw0KDQovSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFyYXRlIHRoZXNlIG1vZGVscyBhbmQg YXMgbWVudGlvbmVkIGVhcmxpZXIsDQp0aGVyZSBpcyBhbHJlYWR5IHdvcmsgZ29pbmcgb24gaW4g cmVzcGVjdGl2ZSBXR3MuLw0KDQovLw0KDQovVGhhbmtzLC8NCg0KL2hpbWFuc2h1Lw0KDQovLw0K DQovLw0KDQovLw0KDQoqRnJvbToqbXBscyBbbWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAqTG9hIEFuZGVyc3Nv bg0KKlNlbnQ6KiBTYXR1cmRheSwgTWFyY2ggMDcsIDIwMTUgODoxOCBBTQ0KKlRvOiogdGVhc0Bp ZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4sIG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+LCByb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+DQoq U3ViamVjdDoqIFJlOiBbbXBsc10gW1J0Zy15YW5nLWNvb3JkXSBbVGVhc10gR2VuZXJpYyBMU1Ag WWFuZw0KDQpSb2JlcnQsDQoNCiBGcm9tIG9uZSBwZXJzcGVjdGl2ZSBJIGFncmVlIHdpdGggeW91 IGFuZCBJZ29yLCBob3dldmVyIGlmIHlvdSB0aGluaw0KYWJvdXQgTVBMUyBMU1BzLCBmcm9tIGEg ZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSAtIGFuZCB0aGF0IGlzIHdoZXJlIE9BTQ0Kb3BlcmF0ZXMs IHRoZXJlIGFsbW9zdCBubyBkaWZmZXJlbmNlIGJldHdlZW4gYSBURS1MU1AgYSBMRFAtTFNQIGFu ZCBhDQpTUFJJTkcgTVBMUyBMU1AgY29tZSB2ZXJ5IGNsb3NlLg0KDQpJZiB5b3UgdGhlIG90aGVy IGhhbmQgdGhpbmsgb2YgTFNQcyBmb3Igb3RoZXIgZGF0YSBwbGFuZXMgdGhlICJub3RoaW5nDQpp biBjb21tb24iIGlzIGFuIGFsbW9zdCB0cnVlIHN0YXRlbWVudC4gRnJvbSB0aGF0IHBvaW50IG9m IHZpZXcgSSB0aGluaw0KZGlmZmVyZW50IG1vZGVscyBhcmUgd2hlcmUgd2Ugd2lsbCBlbmQgdXAs IGJ1dCBJIGFsc28gdGhpbmsgdGhhdCB3ZSBuZWVkDQoic2VwYXJhdGlvbiB3aXRoIG1vZGVyYXRp b24iLg0KDQogIEJ1dCBub3RoaW5nIGlzIHNvIHNpbXBsZSB0aGF0IHdlIGNhbiBjYXB0dXJlIGl0 IGluIG9uZSB2ZXJ5IHNpbXBsZQ0Kc3RhdGVtZW50LCB3ZSBoYXZlIGhhY2tpbmcgYXdheSBvbiB0 aGlzIGZvciAzMCB5ZWFycyBub3csIEknZCBhZHZpY2UNCnRha2luZyBhcmNoaXRlY3R1cmUgYW5k IGhpc3RvcnkgaW50byBjb25zaWRlcmF0aW9uLCBhcyB3ZWxsIGFzIHZpZXdpbmcNCnRoZSBza3kg ZnJvbSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSB0aGFuIGZyb20gdGhlIGJvdHRvbSBvZiBhIGRl ZXAgd2VsbC4NCg0KTGV0IG1lIGFsc28gc2F5IHRoYXQgSSdtIHZlcnkgc3VwcG9ydGl2ZSBvZiBh bGwgdGhlIGdvb2Qgd29yayBnb2luZyBvbg0KaW4gdGhpcyBhcmVhLg0KDQovTG9hDQoNClNlbnQg ZnJvbSBteSBpUGFkDQoNCg0KT24gMDcgTWFyIDIwMTUsIGF0IDE5OjQ3LCBSb2JlcnQgUmFzenVr IDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+DQo8bWFpbHRvOnJv YmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+PiB3cm90ZToNCg0KICAg IEkgd291bGQgYWdyZWUgd2l0aCBJZ29yLg0KDQogICAgT3RoZXIgdGhlbiBuYW1lIG92ZXJsYXAg dGhvc2UgYXJlIGNvbXBsZXRlbHkgZGlmZmVyZW50IHRlY2hub2xvZ2llcw0KICAgIGFuZCBhcnRp ZmljaWFsbHkgcHV0dGluZyB0aGVtIHVuZGVyICJMU1AiIHVtYnJlbGxhIGp1c3QgZG9lcyBub3QN CiAgICBicmluZyBhbnkgdmFsdWUsIGJ1dCBvbmx5IGNvbmZ1c2VzIHRoaW5ncyBldmVuIG1vcmUu DQoNCiAgICBROiBXaGF0IFNQUklORy1MU1AgaGFzIGFueXRoaW5nIGluIGNvbW1vbiB3aXRoICJs YWJlbCIgd2hlbiB5b3UgdXNlDQogICAgdjYgaGVhZGVyID8NCg0KICAgIElmIHlvdSB3YW50IHRv IHNlYXJjaCBmb3Igc29tZSBjb21tb25hbGl0aWVzIGxldCdzIHJlbW92ZSBMRFAtTFNQcw0KICAg IGZyb20gdGhpcyBtaXggKGFzIHRoZSBpcyBub3QgcmVsZXZhbnQpIGFuZCBsZWF2ZSBURS1MU1Ag JiBTUFJJTkcgKw0KICAgIG1heWJlIGFsc28gYWRkIEJJRVIgYXMgd2VsbCBhcyBjaGFuZ2UgdGhl IG5hbWUgdG8gR2VuZXJpYy1FUA0KICAgIChFbmdpbmVlcmVkIFBhdGhzKS4NCg0KICAgIEkgc2Vl IG5vIHZhbHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgZGF0YSBwbGFuZSB1 c2VzDQogICAgbXBscyBsYWJlbHMsIGJ1dCByYXRoZXIgSSB3b3VsZCBzZWUgcmVhc29uYWJsZSB0 byBwcm92aWRlIG1vZGVscw0KICAgIGJhc2VkIG9uIHRoZSB0cmFuc3BvcnQgcGF0aCBjaGFyYWN0 ZXJpc3RpY3MgZm9yIHRoZSB0cmFmZmljIGl0IGlzIHRvDQogICAgY2FycnkuDQoNCiAgICBCZXN0 LA0KDQogICAgci4NCg0KICAgIE9uIEZyaSwgTWFyIDYsIDIwMTUgYXQgMjoxMSBQTSwgSWdvciBC cnlza2luDQogICAgPElCcnlza2luQGFkdmFvcHRpY2FsLmNvbTxtYWlsdG86SUJyeXNraW5AYWR2 YW9wdGljYWwuY29tPiA8bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbTxtYWlsdG86SUJy eXNraW5AYWR2YW9wdGljYWwuY29tPj4+IHdyb3RlOg0KDQogICAgRHJ1diwNCg0KICAgIElNSE8g VEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZyBpbiBjb21tb24uIFRo ZXkNCiAgICBzaG91bGQgaGF2ZSB0b3RhbGx5IGluZGVwZW5kZW50IG1vZGVscyBlYWNoIGJlaW5n IGRldmVsb3BlZCBpbg0KICAgIHJlc3BlY3RpdmUgV0cuDQoNCiAgICBJZ29yDQoNCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFJ0Zy15YW5n LWNvb3JkIG1haWxpbmcgbGlzdA0KICAgIFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPG1haWx0bzpS dGcteWFuZy1jb29yZEBpZXRmLm9yZz4gPG1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZzxt YWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc+Pg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0Bp ZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGVhcw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAg ICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1 YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxv YUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFu dCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjEl MjA2ND4NCg0K --_000_7347100B5761DC41A166AC17F22DF1121B91C1E8eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCBpbiBTUFJJTkcgd2XigJl2ZSBiZWVuIGFyb3VuZCB0 aGF0IGRpc2N1c3Npb24gYW5kIGhhZCBjb25jbHVkZWQgdGhhdCBJUHY0IGlzIG91dCBvZiBzY29w ZSBmb3IgYW4gZXhwbGljaXRseSByb3V0ZWQgcGF0aC4gWW91IHByb3Bvc2UgdG8gcmUtb3BlbiB0 aGF0DQogZGlzY3Vzc2lvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnJhc3p1 a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1hcmNoIDA4LCAyMDE1 IDEyOjQyIFBNPGJyPg0KPGI+VG86PC9iPiBHcmVnb3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4g dGVhc0BpZXRmLm9yZzsgSGltYW5zaHUgU2hhaDsgTG9hIEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW1RlYXNdIFttcGxzXSBbUnRnLXlhbmctY29vcmRd IEdlbmVyaWMgTFNQIFlhbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkkgc3VnZ2VzdCB0aGF0IHRvZGF5IHdlIGtu b3cgKHdlbGwgd2Uga25ldyBldmVuIGluIDIwMDApIGhvdyB0byBkbyBURSB3aXRoIElQIHdpdGhv dXQgTVBMUyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwPlRoeCw8YnI+DQpSLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciA4LCAyMDE1IDg6MzQgUE0sICZx dW90O0dyZWdvcnkgTWlyc2t5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJz a3lAZXJpY3Nzb24uY29tIj5ncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IGFuIExT UCwgaS5lLiBMYWJlbCBTd2l0Y2hlZCBQYXRoLCBjYW4gYmUgcmVhbGl6ZWQgb3ZlciBJUHY0IG9y IElQdjYgZGF0YQ0KIHBsYW5lOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIGRhdGEgcGxhbmUgdG8gdGhl IGV4dGVuZCBvZiBhdm9pZGluZyBsb2NrLWluIHRvIG1wbHMgb3IgaXB2NCBvciBpcHY2Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFz enVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAwOCwg MjAxNSAxMjowMyBQTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBNaXJza3k8YnI+DQo8Yj5DYzo8 L2I+IEhpbWFuc2h1IFNoYWg7IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dGVhc0BpZXRmLm9yZzwvYT47IExvYSBBbmRlcnNzb247DQo8YSBocmVmPSJtYWls dG86bXBsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBbVGVhc10gW21wbHNdIFtSdGcteWFuZy1jb29yZF0gR2VuZXJp YyBMU1AgWWFuZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5XaG93IC4uIGkgdGhpbmsgd2UgYXJlIGRpc2NvdmVy aW5nIHRoYXQgd2UgYWxsIGhhdmUgbm8gY2x1ZSB3aGF0IFlhbmcgbW9kZWwgaXMgOik8bzpwPjwv bzpwPjwvcD4NCjxwPlRoYXQgaXMgaW4gZmFjdCBJIHRoaW5rIGdyZWF0IGRpc2N1c3Npb24gdG8g aGF2ZSBzb29uZXIgdGhlbiBsYXRlci48bzpwPjwvbzpwPjwvcD4NCjxwPlRvIG1lIFlhbmcgbW9k ZWwgaXMgYSB3YXkgdG8gcmVwcmVzZW50IHVuaWZpZWQgKGFjcm9zcyBpbnBsZW1lbnRhdGlvbnMp IHBpY3R1cmUgb2YgY29udHJvbCBwbGFuZSBmb3IgYSBnaXZlbiBuZXR3b3JrIGFwcGxpY2F0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPHA+SXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBkYXRhIHBsYW5l IHRvIHRoZSBleHRlbmQgb2YgYXZvaWRpbmcgbG9jay1pbiB0byBtcGxzIG9yIGlwdjQgb3IgaXB2 Ni48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBhdHRlbXB0IHRvIGdlbmVyYWxpemUgTFNQIHdvdWxk IGJlIGVxdWl2YWxlbnQgdG8gZ2VuZXJhbGl6ZSBSb3V0aW5nIHJlZ2FyZGxlc3MgaWYgdGhpcyBp cyBJR1Agb3IgQkdQIG9yIFRSSUxMIC4uLiB0aGUgb3V0Y29tZSBvZiB0aGF0IHdvdWxkIGJlIHJh dGhlciBwb29yIEkgc3VwcG9zZSAuLi48bzpwPjwvbzpwPjwvcD4NCjxwPkNoZWVycyw8YnI+DQpS LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTWFyIDgs IDIwMTUgNzo0OCBQTSwgJnF1b3Q7R3JlZ29yeSBNaXJza3kmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5ncmVnb3J5 Lm1pcnNreUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LCBldC4gYWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+aWYgSSBpbnRlcnByZXQgdGhlIOKAnExTUCBZQU5HIG1vZGVs4oCdLCB0aGVu IGl0IHJlYWRzIGFzIFlBTkcgbW9kZWwgb2YgTVBMUyBkYXRhIHBsYW5lLCBub3QgY29udHJvbA0K IHByb3RvY29sLCBiZSBpdCBSU1ZQLVRFLCBMRFAsIFBDRVAsIG9yIElHUC1URSBvZiBTUFJJTkcu IEFuZCwgc2luY2UgdGhlIE1QTFMgZGF0YSBwbGFuZSBpcyBpbmRlZWQgY29tbW9uIGFuZCBpbiBm YWN0IHRoZSBvbmUgYW5kIG9ubHksIHN1Y2ggTFNQIFlBTkcgbW9kZWwgcmlnaHRmdWxseSBjYW4g YmUgY2hhcmFjdGVyaXplZCBhcyDigJxHZW5lcmlj4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkJ1dCBpZiBhdXRob3JzIGludGVuZGVkIHRvIGRlc2NyaWJlIGNvbW1vbiBzZXQg YW1vbmcgbGlzdGVkIGFib3ZlIGNvbnRyb2wgcHJvdG9jb2xzIHBlcnRhaW5pbmcgdG8NCiBzaWdu YWxpbmcgb2YgYW4gTVBMUyBMU1AsIHRoZW4sIElNTywgc3VjaCBjb21tb24gc2V0IGZpcnN0IG11 c3QgYmUgZGlzY3Vzc2VkIGFuZCBpZGVudGlmaWVkIHRvIGRlbW9uc3RyYXRlIHRoYXQgaXQgZG9l cyBleGlzdCBhbmQgaXMgc3VmZmljaWVudCB0byBoYXZlIFlBTkcgbW9kZWwgb2YgaXRzIG93biBy YXRoZXIgdGhhbiBZQU5HIG1vZGVscyB0aGF0IGRlc2NyaWJlIExTUCBjb250cm9sIGJ5IGVhY2gg c2lnbmFsaW5nIHByb3RvY29scy4gVGhhdA0KIHRvIG1lIGxvb2tzIHZlcnkgbXVjaCBsaWtlIHdo YXQgTElNRSBXRyBpcyB3b3JraW5nIG9uLCBpbnZlc3RpZ2F0aW5nIHdoZXRoZXIgY29tbW9uIG1v ZGVsIG9mIElQLCBJUC9NUExTLCBNUExTLVRQLCBhbmQgVFJJTEwgT0FNIGV4aXN0cyBhbmQgaXRz IGV4dGVudCBpcyBzdWZmaWNpZW50IHRvIGJlIG9mIGludGVyZXN0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0 ZWFzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8 L2I+IFN1bmRheSwgTWFyY2ggMDgsIDIwMTUgMzo1OCBBTTxicj4NCjxiPlRvOjwvYj4gTG9hIEFu ZGVyc3Nvbjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRlYXNAaWV0Zi5vcmc8L2E+OyBTaGFoLCBIaW1hbnNo dTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNdIFttcGxzXSBbUnRnLXlhbmctY29vcmRd IEdlbmVyaWMgTFNQIFlhbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+SGkgTG9hLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+VGhlIHdheSBJIHJlYWQgSWdvciBzdGF0ZW1lbnQgYW5kIGFncmVlZCB3aXRo IGl0IGluIGEgc2Vuc2Ugb2YgJnF1b3Q7bm90aGluZyBpbiBjb21tb24mcXVvdDsgd2FzIHRoYXQg aXQgd2FzIHJlZmVycmluZyB0byB0aGUgY29udHJvbCBwbGFuZS4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBzdWJqZWN0 IG9mIHRoaXMgdGhyZWFkIGlzICZxdW90O0dlbmVyaWMgTFNQIFlBTkcmcXVvdDsgYW5kIHRvIG1l IFlhbmcgbW9kZWwgZGVzY3JpYmVzIGNvbnRyb2wgYXNwZWN0IG9mIHByb3RvY29sIG9yIGZ1bmN0 aW9uYWxpdHkgbm90IHRoZSBjaG9pY2UNCiBvZiBmb3J3YXJkaW5nIGhlYWRlciBpbiB0aGUgZGF0 YSBwbGFuZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlNvIGlmIHlvdSBhbmQgb3RoZXJzIGFncmVlIHdlIHNob3VsZCBiZSBh bGwgaW4gc3luYyBhbmQgcGVyaGFwcyB3ZSBjb3VsZCBjb25zaWRlciBhcyBwcm9wb3NlZCBiZWZv cmUgR2VuZXJpYyBFbmdpbmVlcmVkIFBhdGggbW9kZWwgYnJhbmNoaW5nDQogYXQgdGhlIGxvd2Vy IGxheWVyIGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0LiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SG93ZXZlciBpZiB5 b3Ugc3RpbGwgdGhpbmsgdGhhdCBZYW5nIGlzIGFib3V0IGRhdGEgcGxhbmUgYW5kIE9BTSB0aGVu IHBlcmhhcHMgd2UgaGF2ZSBhIGJpZ2dlciBpc3N1ZSBoZXJlIC4uLi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoZWVycyw8YnI+DQpS Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFN1biwgTWFyIDgsIDIwMTUgYXQgMTA6MjcgQU0sIExv YSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5r Ij5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+SGltYW5zaHUsDQo8YSBocmVmPSJodHRwOi8vZXQuYWwiIHRhcmdldD0iX2JsYW5r Ij5ldC5hbDwvYT4uLDxicj4NCjxicj4NCkkgdGhpbmsgdGhlcmUgYXJlIHR3byBpc3N1ZXMgaGVy ZSBhbmQgaWYgc29ydGluZyB0aGVtIG91dCBjb3JycmVjdGx5PGJyPg0Kd2UgYXJlIHZlcnkgY2xv c2UuPGJyPg0KPGJyPg0KVGhlIGZpcnN0IGlzc3VlIGlzIHNpbWlsYXJpdGllcyBiZXR3ZWVuIGRp ZmZlcmVudCB0eXBlcyBvZiBMU1BzLjxicj4NCjxicj4NCkhlcmUgSSBzYWlkIHRoYXQsIGF0IGxl YXN0IGZvciBhIE1QTFMgUFNOLCB0aGVyZSBhcmUgc2ltaWxhcml0aWVzLDxicj4NCmUuZy4gdGhl IGRhdGEgcGxhbmUgaXMgKG5lYXJseSkgdGhlIHNhbWUuIFRoaXMgd2FzIHNhaWQgaW4gcmVhY3Rp b248YnI+DQp0byBJZ29yJ3Mgc3RhdGVtZW50ICZxdW90O0lNSE8gVEUtTFNQLCBMRFAtTFNQIGFu ZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZzxicj4NCmluIGNvbW1vbi4mcXVvdDsgSSBzdGlsbCBk b24ndCB0aGluayB0aGF0IElnb3IncyBzdGF0ZW1lbnQgaXMgcmVhbGx5IGNvcnJlY3QuPGJyPg0K SWYgaGUgaGFkIHNhaWQgJnF1b3Q7SU1ITyB0aGVyZSBhcmUgbm90IGVub3VnaCBzaW1pbGFyaXRl cyBiZXR3ZWVuIFRFLUxTUCw8YnI+DQpMRFAtTFNQIGFuZCBTUFJJTkctTFNQIHRvIG1vdGl2YXRl IGEgY29tbW9uIG1vZGVsJnF1b3Q7LiBJIHRoaW5rIHRoYXQgd2UgYmU8YnI+DQphIG11Y2ggbW9y ZSBhY2N1cmF0ZSBzdGF0ZW1lbnQuPGJyPg0KPGJyPg0KQW5kIHRoYXQgaXMgdGhlIG90aGVyIGlz c3VlIC0gSXMgaXQgcmVhc29uYWJsZSB0byBtb2RlbCBURS1MU1AsPGJyPg0KTERQLUxTUCBhbmQg U1BSSU5HLUxTUCBpbiB0aGUgc2FtZSBtb2RlbD8gSSBkb24ndCBub3QgdGhpbmsgaXQgaXMsPGJy Pg0KYnV0IHRoYXQgd2UgbmVlZCBhbiBvdmVybGFwIG9mIHBlb3BsZSB3b3JraW5nIHdpdGggdGhl IGRpZmZlcmVudCBtb2RlbHMuPGJyPg0KPGJyPg0KSG9wZSB0aGlzIGlzIGNsZWFyIGVub3VnaC48 YnI+DQo8YnI+DQovTG9hPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxNS0wMy0wNyAyMzoxOSwgU2hh aCwgSGltYW5zaHUgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPi9JIGFn cmVlIHdpdGggUm9iZXJ0IGFuZCBJZ29yLCBwdXR0aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHNhbWUg YnVja2V0PGJyPg0KYmVjYXVzZSBvZiBjb21tb24gZGF0YSBwbGFuZSAmYW1wOyBPQU0gZG9lcyBu b3QganVzdGlmeS4vPGJyPg0KPGJyPg0KL1dlIHdvdWxkbuKAmXQgY29uc2lkZXIgZG9pbmcgc2Ft ZSBmb3IgSVAgZGF0YSBwbGFuZS4uLzxicj4NCjxicj4NCi9JIHRoaW5rIHdlIG5lZWQgdG8gc2Vw YXJhdGUgdGhlc2UgbW9kZWxzIGFuZCBhcyBtZW50aW9uZWQgZWFybGllciw8YnI+DQp0aGVyZSBp cyBhbHJlYWR5IHdvcmsgZ29pbmcgb24gaW4gcmVzcGVjdGl2ZSBXR3MuLzxicj4NCjxicj4NCi8v PGJyPg0KPGJyPg0KL1RoYW5rcywvPGJyPg0KPGJyPg0KL2hpbWFuc2h1Lzxicj4NCjxicj4NCi8v PGJyPg0KPGJyPg0KLy88YnI+DQo8YnI+DQovLzxicj4NCjxicj4NCipGcm9tOiptcGxzIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1wbHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2YgKkxvYSBBbmRlcnNzb248 YnI+DQoqU2VudDoqIFNhdHVyZGF5LCBNYXJjaCAwNywgMjAxNSA4OjE4IEFNPGJyPg0KKlRvOiog PGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzQGlldGYu b3JnPC9hPiwgPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N Cm1wbHNAaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRh cmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT48YnI+DQoqU3ViamVjdDoqIFJlOiBb bXBsc10gW1J0Zy15YW5nLWNvb3JkXSBbVGVhc10gR2VuZXJpYyBMU1AgWWFuZzxicj4NCjxicj4N ClJvYmVydCw8YnI+DQo8YnI+DQombmJzcDtGcm9tIG9uZSBwZXJzcGVjdGl2ZSBJIGFncmVlIHdp dGggeW91IGFuZCBJZ29yLCBob3dldmVyIGlmIHlvdSB0aGluazxicj4NCmFib3V0IE1QTFMgTFNQ cywgZnJvbSBhIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUgLSBhbmQgdGhhdCBpcyB3aGVyZSBPQU08 YnI+DQpvcGVyYXRlcywgdGhlcmUgYWxtb3N0IG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIFRFLUxT UCBhIExEUC1MU1AgYW5kIGE8YnI+DQpTUFJJTkcgTVBMUyBMU1AgY29tZSB2ZXJ5IGNsb3NlLjxi cj4NCjxicj4NCklmIHlvdSB0aGUgb3RoZXIgaGFuZCB0aGluayBvZiBMU1BzIGZvciBvdGhlciBk YXRhIHBsYW5lcyB0aGUgJnF1b3Q7bm90aGluZzxicj4NCmluIGNvbW1vbiZxdW90OyBpcyBhbiBh bG1vc3QgdHJ1ZSBzdGF0ZW1lbnQuIEZyb20gdGhhdCBwb2ludCBvZiB2aWV3IEkgdGhpbms8YnI+ DQpkaWZmZXJlbnQgbW9kZWxzIGFyZSB3aGVyZSB3ZSB3aWxsIGVuZCB1cCwgYnV0IEkgYWxzbyB0 aGluayB0aGF0IHdlIG5lZWQ8YnI+DQomcXVvdDtzZXBhcmF0aW9uIHdpdGggbW9kZXJhdGlvbiZx dW90Oy48YnI+DQo8YnI+DQombmJzcDsgQnV0IG5vdGhpbmcgaXMgc28gc2ltcGxlIHRoYXQgd2Ug Y2FuIGNhcHR1cmUgaXQgaW4gb25lIHZlcnkgc2ltcGxlPGJyPg0Kc3RhdGVtZW50LCB3ZSBoYXZl IGhhY2tpbmcgYXdheSBvbiB0aGlzIGZvciAzMCB5ZWFycyBub3csIEknZCBhZHZpY2U8YnI+DQp0 YWtpbmcgYXJjaGl0ZWN0dXJlIGFuZCBoaXN0b3J5IGludG8gY29uc2lkZXJhdGlvbiwgYXMgd2Vs bCBhcyB2aWV3aW5nPGJyPg0KdGhlIHNreSBmcm9tIGEgZGlmZmVyZW50IHBlcnNwZWN0aXZlIHRo YW4gZnJvbSB0aGUgYm90dG9tIG9mIGEgZGVlcCB3ZWxsLjxicj4NCjxicj4NCkxldCBtZSBhbHNv IHNheSB0aGF0IEknbSB2ZXJ5IHN1cHBvcnRpdmUgb2YgYWxsIHRoZSBnb29kIHdvcmsgZ29pbmcg b248YnI+DQppbiB0aGlzIGFyZWEuPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NClNlbnQgZnJv bSBteSBpUGFkPGJyPg0KPGJyPg0KPGJyPg0KT24gMDcgTWFyIDIwMTUsIGF0IDE5OjQ3LCBSb2Jl cnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0i X2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT48YnI+DQombHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpyb2JlcnRAcmFzenVrLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJvYmVydEByYXN6dWsubmV0 PC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSB3b3VsZCBhZ3Jl ZSB3aXRoIElnb3IuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPdGhlciB0aGVuIG5hbWUgb3Zl cmxhcCB0aG9zZSBhcmUgY29tcGxldGVseSBkaWZmZXJlbnQgdGVjaG5vbG9naWVzPGJyPg0KJm5i c3A7ICZuYnNwOyBhbmQgYXJ0aWZpY2lhbGx5IHB1dHRpbmcgdGhlbSB1bmRlciAmcXVvdDtMU1Am cXVvdDsgdW1icmVsbGEganVzdCBkb2VzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDsgYnJpbmcgYW55 IHZhbHVlLCBidXQgb25seSBjb25mdXNlcyB0aGluZ3MgZXZlbiBtb3JlLjxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgUTogV2hhdCBTUFJJTkctTFNQIGhhcyBhbnl0aGluZyBpbiBjb21tb24gd2l0 aCAmcXVvdDtsYWJlbCZxdW90OyB3aGVuIHlvdSB1c2U8YnI+DQombmJzcDsgJm5ic3A7IHY2IGhl YWRlciA/PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJZiB5b3Ugd2FudCB0byBzZWFyY2ggZm9y IHNvbWUgY29tbW9uYWxpdGllcyBsZXQncyByZW1vdmUgTERQLUxTUHM8YnI+DQombmJzcDsgJm5i c3A7IGZyb20gdGhpcyBtaXggKGFzIHRoZSBpcyBub3QgcmVsZXZhbnQpIGFuZCBsZWF2ZSBURS1M U1AgJmFtcDsgU1BSSU5HICYjNDM7PGJyPg0KJm5ic3A7ICZuYnNwOyBtYXliZSBhbHNvIGFkZCBC SUVSIGFzIHdlbGwgYXMgY2hhbmdlIHRoZSBuYW1lIHRvIEdlbmVyaWMtRVA8YnI+DQombmJzcDsg Jm5ic3A7IChFbmdpbmVlcmVkIFBhdGhzKS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgc2Vl IG5vIHZhbHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgZGF0YSBwbGFuZSB1 c2VzPGJyPg0KJm5ic3A7ICZuYnNwOyBtcGxzIGxhYmVscywgYnV0IHJhdGhlciBJIHdvdWxkIHNl ZSByZWFzb25hYmxlIHRvIHByb3ZpZGUgbW9kZWxzPGJyPg0KJm5ic3A7ICZuYnNwOyBiYXNlZCBv biB0aGUgdHJhbnNwb3J0IHBhdGggY2hhcmFjdGVyaXN0aWNzIGZvciB0aGUgdHJhZmZpYyBpdCBp cyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgY2FycnkuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBC ZXN0LDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgci48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IE9uIEZyaSwgTWFyIDYsIDIwMTUgYXQgMjoxMSBQTSwgSWdvciBCcnlza2luPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPklCcnlza2luQGFkdmFvcHRpY2FsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+SUJy eXNraW5AYWR2YW9wdGljYWwuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgRHJ1diw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElNSE8gVEUtTFNQLCBMRFAt TFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZyBpbiBjb21tb24uIFRoZXk8YnI+DQombmJz cDsgJm5ic3A7IHNob3VsZCBoYXZlIHRvdGFsbHkgaW5kZXBlbmRlbnQgbW9kZWxzIGVhY2ggYmVp bmcgZGV2ZWxvcGVkIGluPGJyPg0KJm5ic3A7ICZuYnNwOyByZXNwZWN0aXZlIFdHLjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgSWdvcjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7 IFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0i bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmct Y29vcmRAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5nLWNv b3JkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZDwvYT48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRlYXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UZWFzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhczwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi Pjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4NCkxvYSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5odWF3ZWkuY29tPC9hPjxicj4NClNlbmlvciBN UExTIEV4cGVydCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWls dG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGkubnU8L2E+PGJyPg0KSHVhd2Vp IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBo cmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYj NDM7NDYgNzM5IDgxIDIxIDY0PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B91C1E8eusaamb103erics_-- From nobody Mon Mar 9 01:34:10 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3581A1B1C; Mon, 9 Mar 2015 01:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzjz4g1ALX2a; Mon, 9 Mar 2015 01:34:05 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80FF1A1A88; Mon, 9 Mar 2015 01:34:04 -0700 (PDT) Received: by iecat20 with SMTP id at20so47494072iec.6; Mon, 09 Mar 2015 01:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ICWrIHfh4saNU9qYH57OmjQlH2rIbYKgcqynnCTvm4E=; b=g2O72mj7UjEq3qUN3nuA4BYQiWAzJEm72lT5cvrR3LCme0hlkvW6+EzVkEAd2VrS/g EOHMGqTQLZCgHkW1W4lN5624CnFHKWE3/Zj/Tg1DMMew1yorSCea68/5DdxzSQZVhW5K kmLxp4fJa9zPAWQH/KZC6ciDgylXoyrW86qT32wW0Y55snlTZuE9268qOKXy06NEFUKi q989/qao+hKnGLFkmnW74nDpjeZGiB+dI0l9nsY9Mc/NweB94K2B7NpZplM1fvQqpNb7 ZKRRYBBerNN08zvUmIgL0hZwxOqjt1N/mu88PfbEPPnJODpTrb8TgUDzNyWFCjEaPQOz O9rQ== MIME-Version: 1.0 X-Received: by 10.42.123.135 with SMTP id s7mr24881495icr.55.1425890044223; Mon, 09 Mar 2015 01:34:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.137.70 with HTTP; Mon, 9 Mar 2015 01:34:04 -0700 (PDT) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91C1E8@eusaamb103.ericsson.se> References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B91C1B1@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B91C1E8@eusaamb103.ericsson.se> Date: Mon, 9 Mar 2015 09:34:04 +0100 X-Google-Sender-Auth: lJRablBMvtqlpWbJROc19LUl1Gs Message-ID: From: Robert Raszuk To: Gregory Mirsky Content-Type: multipart/alternative; boundary=20cf3010e7a993282a0510d6e5f8 Archived-At: Cc: "mpls@ietf.org" , Himanshu Shah , "teas@ietf.org" , Loa Andersson Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 08:34:08 -0000 --20cf3010e7a993282a0510d6e5f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gregory, > I think that in SPRING we=E2=80=99ve been around that discussion and > had concluded that IPv4 is out of scope for an explicitly routed > path. You propose to re-open that discussion? Who says anything of SPRING and IPv4 ? I can use IPv4 for path engneering with: A) automated metric tuning B) BGP Vector Routing https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-04 C) BGP SDN https://tools.ietf.org/html/draft-lapukhov-bgp-sdn-00 Those are neither SPRING nor TE-LSP nor LDP related. Are those technologies out of scope of general idea of "Engineered Paths" ? Thx, R. On Sun, Mar 8, 2015 at 9:11 PM, Gregory Mirsky wrote: > I think that in SPRING we=E2=80=99ve been around that discussion and had > concluded that IPv4 is out of scope for an explicitly routed path. You > propose to re-open that discussion? > > > > Regards, > > Greg > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Sunday, March 08, 2015 12:42 PM > *To:* Gregory Mirsky > *Cc:* teas@ietf.org; Himanshu Shah; Loa Andersson; mpls@ietf.org > > *Subject:* RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang > > > > I suggest that today we know (well we knew even in 2000) how to do TE wit= h > IP without MPLS ... > > Thx, > R. > > On Mar 8, 2015 8:34 PM, "Gregory Mirsky" > wrote: > > Hi Robert, > > are you suggesting that an LSP, i.e. Label Switched Path, can be realized > over IPv4 or IPv6 data plane: > > It has nothing to do with data plane to the extend of avoiding lock-in to > mpls or ipv4 or ipv6. > > > > Regards, > > Greg > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Sunday, March 08, 2015 12:03 PM > *To:* Gregory Mirsky > *Cc:* Himanshu Shah; teas@ietf.org; Loa Andersson; mpls@ietf.org > *Subject:* RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang > > > > Whow .. i think we are discovering that we all have no clue what Yang > model is :) > > That is in fact I think great discussion to have sooner then later. > > To me Yang model is a way to represent unified (across inplementations) > picture of control plane for a given network application. > > It has nothing to do with data plane to the extend of avoiding lock-in to > mpls or ipv4 or ipv6. > > The attempt to generalize LSP would be equivalent to generalize Routing > regardless if this is IGP or BGP or TRILL ... the outcome of that would b= e > rather poor I suppose ... > > Cheers, > R. > > On Mar 8, 2015 7:48 PM, "Gregory Mirsky" > wrote: > > Hi Robert, et. al, > > if I interpret the =E2=80=9CLSP YANG model=E2=80=9D, then it reads as YAN= G model of MPLS > data plane, not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of > SPRING. And, since the MPLS data plane is indeed common and in fact the o= ne > and only, such LSP YANG model rightfully can be characterized as =E2=80= =9CGeneric=E2=80=9D. > > But if authors intended to describe common set among listed above control > protocols pertaining to signaling of an MPLS LSP, then, IMO, such common > set first must be discussed and identified to demonstrate that it does > exist and is sufficient to have YANG model of its own rather than YANG > models that describe LSP control by each signaling protocols. That to me > looks very much like what LIME WG is working on, investigating whether > common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its extent > is sufficient to be of interest. > > > > Regards, > > Greg > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Sunday, March 08, 2015 3:58 AM > *To:* Loa Andersson > *Cc:* mpls@ietf.org; teas@ietf.org; Shah, Himanshu > *Subject:* Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang > > > > Hi Loa, > > > > The way I read Igor statement and agreed with it in a sense of "nothing i= n > common" was that it was referring to the control plane. > > > > The subject of this thread is "Generic LSP YANG" and to me Yang model > describes control aspect of protocol or functionality not the choice of > forwarding header in the data plane. > > > > So if you and others agree we should be all in sync and perhaps we could > consider as proposed before Generic Engineered Path model branching at th= e > lower layer between unicast and multicast. > > > > However if you still think that Yang is about data plane and OAM then > perhaps we have a bigger issue here .... > > > > Cheers, > R. > > > > > > > > > > On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson wrote: > > Himanshu, et.al., > > I think there are two issues here and if sorting them out corrrectly > we are very close. > > The first issue is similarities between different types of LSPs. > > Here I said that, at least for a MPLS PSN, there are similarities, > e.g. the data plane is (nearly) the same. This was said in reaction > to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing > in common." I still don't think that Igor's statement is really correct. > If he had said "IMHO there are not enough similarites between TE-LSP, > LDP-LSP and SPRING-LSP to motivate a common model". I think that we be > a much more accurate statement. > > And that is the other issue - Is it reasonable to model TE-LSP, > LDP-LSP and SPRING-LSP in the same model? I don't not think it is, > but that we need an overlap of people working with the different models. > > Hope this is clear enough. > > /Loa > > > On 2015-03-07 23:19, Shah, Himanshu wrote: > > /I agree with Robert and Igor, putting everything in the same bucket > because of common data plane & OAM does not justify./ > > /We wouldn=E2=80=99t consider doing same for IP data plane../ > > /I think we need to separate these models and as mentioned earlier, > there is already work going on in respective WGs./ > > // > > /Thanks,/ > > /himanshu/ > > // > > // > > // > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson > *Sent:* Saturday, March 07, 2015 8:18 AM > *To:* teas@ietf.org, mpls@ietf.org, robert@raszuk.net > *Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang > > Robert, > > From one perspective I agree with you and Igor, however if you think > about MPLS LSPs, from a data plane perspective - and that is where OAM > operates, there almost no difference between a TE-LSP a LDP-LSP and a > SPRING MPLS LSP come very close. > > If you the other hand think of LSPs for other data planes the "nothing > in common" is an almost true statement. From that point of view I think > different models are where we will end up, but I also think that we need > "separation with moderation". > > But nothing is so simple that we can capture it in one very simple > statement, we have hacking away on this for 30 years now, I'd advice > taking architecture and history into consideration, as well as viewing > the sky from a different perspective than from the bottom of a deep well. > > Let me also say that I'm very supportive of all the good work going on > in this area. > > /Loa > > Sent from my iPad > > > On 07 Mar 2015, at 19:47, Robert Raszuk > wrote: > > I would agree with Igor. > > Other then name overlap those are completely different technologies > and artificially putting them under "LSP" umbrella just does not > bring any value, but only confuses things even more. > > Q: What SPRING-LSP has anything in common with "label" when you use > v6 header ? > > If you want to search for some commonalities let's remove LDP-LSPs > from this mix (as the is not relevant) and leave TE-LSP & SPRING + > maybe also add BIER as well as change the name to Generic-EP > (Engineered Paths). > > I see no value of goruping based on the fact that data plane uses > mpls labels, but rather I would see reasonable to provide models > based on the transport path characteristics for the traffic it is to > carry. > > Best, > > r. > > On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin > > wrote: > > Druv, > > IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. They > should have totally independent models each being developed in > respective WG. > > Igor > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --20cf3010e7a993282a0510d6e5f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gregory,

> I think th= at in SPRING we=E2=80=99ve been around that discussion and=C2=A0
> had concluded that IPv= 4 is out of scope for an explicitly routed=C2=A0
> path. You propose to re-open that disc= ussion?


Who says anything of SPRING and IP= v4 ?

I can u= se IPv4 for path engneering with:

=
A) automated metric tuning=C2=A0

B) BGP Vector Routing
https://tools.ietf.org/html/draft-patel-raszuk-b= gp-vector-routing-04

C) BGP SDN
https://tools.ietf.org/html/dr= aft-lapukhov-bgp-sdn-00

Those are neither SPRING nor TE-LSP nor LDP related. Are th= ose technologies out of scope of general idea of "Engineered Paths&quo= t; ?

Thx,
R.




On Sun, Mar 8, 2015 at 9:11 PM= , Gregory Mirsky <gregory.mirsky@ericsson.com> wro= te:

I think that in SPRING we=E2=80=99ve been ar= ound that discussion and had concluded that IPv4 is out of scope for an exp= licitly routed path. You propose to re-open that discussion?

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<= u>

=C2=A0

From: rrasz= uk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 12:42 PM
To: Gregory Mirsky
Cc: teas@ietf.org= ; Himanshu Shah; Loa Andersson; mpls@ietf.org


Subject: RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

I suggest that today we know (well we knew even in 2000) how to do TE wi= th IP without MPLS ...

Thx,
R.

On Mar 8, 2015 8:34 PM, "Gregory Mirsky" &= lt;gregory= .mirsky@ericsson.com> wrote:

Hi Robert,

are you suggesting that an LSP, i.e. Label S= witched Path, can be realized over IPv4 or IPv6 data plane:

It has nothing to do with data plane to the extend of avoiding lock= -in to mpls or ipv4 or ipv6.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<= /span>

=C2=A0

From: rraszuk@gmail.com [mailto:rraszuk@gm= ail.com] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 12:03 PM
To: Gregory Mirsky
Cc: Himanshu Shah; teas@ietf.org; Loa Andersson; mpls@ietf.org
Subject: RE: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

Whow .. i think we are discovering that we all have no clue what Yang mo= del is :)

That is in fact I think great discussion to have sooner then later.

To me Yang model is a way to represent unified (across inplementations) = picture of control plane for a given network application.

It has nothing to do with data plane to the extend of avoiding lock-in t= o mpls or ipv4 or ipv6.

The attempt to generalize LSP would be equivalent to generalize Routing = regardless if this is IGP or BGP or TRILL ... the outcome of that would be = rather poor I suppose ...

Cheers,
R.

On Mar 8, 2015 7:48 PM, "Gregory Mirsky" &= lt;gregory= .mirsky@ericsson.com> wrote:

Hi Robert, et. al,

if I interpret the =E2=80=9CLSP YANG model= =E2=80=9D, then it reads as YANG model of MPLS data plane, not control protocol, be it RSVP-TE, LDP, PCEP, or IGP-TE of SPRING. And, since the MP= LS data plane is indeed common and in fact the one and only, such LSP YANG = model rightfully can be characterized as =E2=80=9CGeneric=E2=80=9D.<= u>

But if authors intended to describe common s= et among listed above control protocols pertaining to signaling of an MPLS LSP, then, IMO, such common set first must be discuss= ed and identified to demonstrate that it does exist and is sufficient to ha= ve YANG model of its own rather than YANG models that describe LSP control = by each signaling protocols. That to me looks very much like what LIME WG is working on, investigating wheth= er common model of IP, IP/MPLS, MPLS-TP, and TRILL OAM exists and its exten= t is sufficient to be of interest.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Greg<= /span>

=C2=A0

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Sunday, March 08, 2015 3:58 AM
To: Loa Andersson
Cc: mpls@ietf.org= ; teas@ietf.org; Shah, Himanshu
Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang<= u>

=C2=A0

Hi= Loa,

= =C2=A0

Th= e way I read Igor statement and agreed with it in a sense of "nothing = in common" was that it was referring to the control plane.=C2=A0

= =C2=A0

Th= e subject of this thread is "Generic LSP YANG" and to me Yang mod= el describes control aspect of protocol or functionality not the choice of forwarding header in the data plane.=C2=A0

= =C2=A0

So= if you and others agree we should be all in sync and perhaps we could cons= ider as proposed before Generic Engineered Path model branching at the lower layer between unicast and multicast.=C2=A0

= =C2=A0

Ho= wever if you still think that Yang is about data plane and OAM then perhaps= we have a bigger issue here ....

= =C2=A0

Ch= eers,
R.

= =C2=A0

= =C2=A0

= =C2=A0

=C2=A0

On Sun, Mar 8, 2015 at 10:27 AM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrote:

Himanshu, et.al.,

I think there are two issues here and if sorting them out corrrectly
we are very close.

The first issue is similarities between different types of LSPs.

Here I said that, at least for a MPLS PSN, there are similarities,
e.g. the data plane is (nearly) the same. This was said in reaction
to Igor's statement "IMHO TE-LSP, LDP-LSP and SPRING-LSP have noth= ing
in common." I still don't think that Igor's statement is reall= y correct.
If he had said "IMHO there are not enough similarites between TE-LSP,<= br> LDP-LSP and SPRING-LSP to motivate a common model". I think that we be=
a much more accurate statement.

And that is the other issue - Is it reasonable to model TE-LSP,
LDP-LSP and SPRING-LSP in the same model? I don't not think it is,
but that we need an overlap of people working with the different models.
Hope this is clear enough.

/Loa


On 2015-03-07 23:19, Shah, Himanshu wrote:

/I agree with Robert an= d Igor, putting everything in the same bucket
because of common data plane & OAM does not justify./

/We wouldn=E2=80=99t consider doing same for IP data plane../

/I think we need to separate these models and as mentioned earlier,
there is already work going on in respective WGs./

//

/Thanks,/

/himanshu/

//

//

//

*From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Loa Andersson
*Sent:* Saturday, March 07, 2015 8:18 AM
*To:* teas@ietf.org,= mpls@ietf.org, r= obert@raszuk.net
*Subject:* Re: [mpls] [Rtg-yang-coord] [Teas] Generic LSP Yang

Robert,

=C2=A0From one perspective I agree with you and Igor, however if you think<= br> about MPLS LSPs, from a data plane perspective - and that is where OAM
operates, there almost no difference between a TE-LSP a LDP-LSP and a
SPRING MPLS LSP come very close.

If you the other hand think of LSPs for other data planes the "nothing=
in common" is an almost true statement. From that point of view I thin= k
different models are where we will end up, but I also think that we need "separation with moderation".

=C2=A0 But nothing is so simple that we can capture it in one very simple statement, we have hacking away on this for 30 years now, I'd advice taking architecture and history into consideration, as well as viewing
the sky from a different perspective than from the bottom of a deep well.
Let me also say that I'm very supportive of all the good work going on<= br> in this area.

/Loa

Sent from my iPad


On 07 Mar 2015, at 19:47, Robert Raszuk <robert@raszuk.net
<mailto:robert@ra= szuk.net>> wrote:

=C2=A0 =C2=A0 I would agree with Igor.

=C2=A0 =C2=A0 Other then name overlap those are completely different techno= logies
=C2=A0 =C2=A0 and artificially putting them under "LSP" umbrella = just does not
=C2=A0 =C2=A0 bring any value, but only confuses things even more.

=C2=A0 =C2=A0 Q: What SPRING-LSP has anything in common with "label&qu= ot; when you use
=C2=A0 =C2=A0 v6 header ?

=C2=A0 =C2=A0 If you want to search for some commonalities let's remove= LDP-LSPs
=C2=A0 =C2=A0 from this mix (as the is not relevant) and leave TE-LSP &= SPRING +
=C2=A0 =C2=A0 maybe also add BIER as well as change the name to Generic-EP<= br> =C2=A0 =C2=A0 (Engineered Paths).

=C2=A0 =C2=A0 I see no value of goruping based on the fact that data plane = uses
=C2=A0 =C2=A0 mpls labels, but rather I would see reasonable to provide mod= els
=C2=A0 =C2=A0 based on the transport path characteristics for the traffic i= t is to
=C2=A0 =C2=A0 carry.

=C2=A0 =C2=A0 Best,

=C2=A0 =C2=A0 r.

=C2=A0 =C2=A0 On Fri, Mar 6, 2015 at 2:11 PM, Igor Bryskin
=C2=A0 =C2=A0 <IBryskin@advaoptical.com <mailto:IBryskin@advaoptical.com>> wrote:=

=C2=A0 =C2=A0 Druv,

=C2=A0 =C2=A0 IMHO TE-LSP, LDP-LSP and SPRING-LSP have nothing in common. T= hey
=C2=A0 =C2=A0 should have totally independent models each being developed i= n
=C2=A0 =C2=A0 respective WG.

=C2=A0 =C2=A0 Igor

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Rtg-yang-coord mailing list
=C2=A0 =C2=A0 = Rtg-yang-coord@ietf.org <mailto:Rtg-yang-coord@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtg-yang-coord



_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0


--20cf3010e7a993282a0510d6e5f8-- From nobody Mon Mar 9 05:45:31 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533D21A88D4; Mon, 9 Mar 2015 05:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqkDXGdlaCQj; Mon, 9 Mar 2015 05:45:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B40441A7034; Mon, 9 Mar 2015 05:45:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309124527.26071.62576.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 05:45:27 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-p2mp-loose-path-reopt-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:45:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to Resource Reservation Protocol For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs Authors : Tarek Saad Rakesh Gandhi Zafar Ali Robert H. Venator Yuji Kamite Filename : draft-ietf-teas-p2mp-loose-path-reopt-02.txt Pages : 16 Date : 2015-03-09 Abstract: For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label Switched Path (LSP), it is preferable in some cases to re-evaluate and re-optimize the entire P2MP-TE LSP by re-signaling all its Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism for an ingress Label Switched Router (LSR) to trigger a new path re- evaluation request and a mechanism for a mid-point LSR to notify an availability of a preferred path, operate on an individual or a sub-group of S2L sub-LSP(s) basis only. This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the entire LSP tree containing one or more S2L sub-LSPs whose paths are loose (or abstract) hop expanded, and for a mid-point LSR to notify to the ingress node that a preferable tree exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to signal one or more S2L sub-LSPs in an RSVP message. This document defines markers to indicate beginning and end of an S2L sub-LSP descriptor list when the RSVP message needs to be fragmented due to large number of S2L sub-LSPs in the message when performing sub-group based re-optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-p2mp-loose-path-reopt-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 05:55:56 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947AE1A8864 for ; Mon, 9 Mar 2015 05:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDXq7wSwAa9G for ; Mon, 9 Mar 2015 05:55:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89B61A88B8 for ; Mon, 9 Mar 2015 05:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3156; q=dns/txt; s=iport; t=1425905717; x=1427115317; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Zfe7vZh1JxEZeI5UQ2npWIrvQjHQdbGoriSwUCqepPQ=; b=XFiww1RsSjaqR1M6qC+K49TqfZvHkM+4ez2hPvGO8fq/P+G0cfrxF1Am /2tBZOLf6YE+wNNbs/AdWV+Ugt+G9cvLZDM50NeDjE66PtPLapsv26I5N Ns/Wi+9gkh6QBgxVn/1j1nG/LSdu/Q2MJWiYoyjumQInjIu3GDgh93pi9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BDBQATl/1U/5tdJa1agwZSVQnAe4E9DIVuAoEnOBQBAQEBAQEBfIQQAQEEAQEBNzQLEgEIEiQ3CxcOAgQOBQmIJggFwTYBAQEBAQEBAwEBAQEBAQEBARmLEoQ7MweEKwWPdoNfhWaBGjmCZotegz4jggIcgVBvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,367,1422921600"; d="scan'208";a="130100018" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 09 Mar 2015 12:55:16 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t29CtGVE008746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Mar 2015 12:55:16 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 07:55:16 -0500 From: "Rakesh Gandhi (rgandhi)" To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-p2mp-loose-path-reopt-02.txt Thread-Index: AQHQWmbvu4/41W6Cskeu+KlygCsKRJ0UPUYA Date: Mon, 9 Mar 2015 12:55:15 +0000 Message-ID: In-Reply-To: <20150309124527.26071.62576.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.255.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C601D964DD4354F9C793B14CB5E6E3A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Vishnu Pavan Beeram , "y.kamite@ntt.com" , "Tarek Saad \(tsaad\)" , "robert.h.venator.civ@mail.mil" , "Matt Hartley \(mhartley\)" , Lou Berger , "Zafar Ali \(zali\)" Subject: Re: [Teas] I-D Action: draft-ietf-teas-p2mp-loose-path-reopt-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 12:55:54 -0000 Hi WG, We have made minor editorial changes and updated the Security section in this version.=20 We believe this document is ready for the WG LC. Welcome your review comments and suggestions. Thanks, Rakesh and authors. On 2015-03-09 8:45 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Traffic Engineering Architecture and >Signaling Working Group of the IETF. > > Title : Extensions to Resource Reservation Protocol For >Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering >LSPs > Authors : Tarek Saad > Rakesh Gandhi > Zafar Ali > Robert H. Venator > Yuji Kamite > Filename : draft-ietf-teas-p2mp-loose-path-reopt-02.txt > Pages : 16 > Date : 2015-03-09 > >Abstract: > For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label > Switched Path (LSP), it is preferable in some cases to re-evaluate > and re-optimize the entire P2MP-TE LSP by re-signaling all its > Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism > for an ingress Label Switched Router (LSR) to trigger a new path re- > evaluation request and a mechanism for a mid-point LSR to notify an > availability of a preferred path, operate on an individual or a > sub-group of S2L sub-LSP(s) basis only. > > This document defines RSVP-TE signaling extensions to allow an > ingress node of a P2MP-TE LSP to request the re-evaluation of the > entire LSP tree containing one or more S2L sub-LSPs whose paths are > loose (or abstract) hop expanded, and for a mid-point LSR to notify > to the ingress node that a preferable tree exists for the entire > P2MP-TE LSP. For re-optimizing a group of S2L sub-LSP(s) in a tree, > an S2L sub-LSP descriptor list can be used to signal one or more S2L > sub-LSPs in an RSVP message. This document defines markers to > indicate beginning and end of an S2L sub-LSP descriptor list when the > RSVP message needs to be fragmented due to large number of S2L > sub-LSPs in the message when performing sub-group based > re-optimization. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-teas-p2mp-loose-path-reopt/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-teas-p2mp-loose-path-reopt-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-p2mp-loose-path-reopt-0= 2 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Mon Mar 9 08:27:09 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038FB1A8A4E; Mon, 9 Mar 2015 08:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUCMOS9xkN4v; Mon, 9 Mar 2015 08:27:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AC91A8A90; Mon, 9 Mar 2015 08:20:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309152026.11471.11879.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 08:20:26 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-diversity-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:27:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route Authors : Zafar Ali George Swallow Fatai Zhang Dieter Beller Filename : draft-ietf-teas-lsp-diversity-01.txt Pages : 28 Date : 2015-03-09 Abstract: RFC 4874 specifies methods by which path exclusions can be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP source node. This document specifies procedures for additional route exclusion subobject based on Paths currently existing or expected to exist within the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-diversity-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-diversity-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 09:50:58 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710FA1A8A87 for ; Mon, 9 Mar 2015 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr9K0WUetGpm for ; Mon, 9 Mar 2015 09:50:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75FB31A8BC5 for ; Mon, 9 Mar 2015 09:50:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id D7DD41ABDED5E for ; Mon, 9 Mar 2015 16:50:37 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t29GoPR7014168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 17:50:40 +0100 Received: from [149.204.107.61] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 9 Mar 2015 17:50:32 +0100 Message-ID: <54FDCF52.1070807@alcatel-lucent.com> Date: Mon, 9 Mar 2015 17:50:26 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: TEAS WG References: <20150309152026.11471.11879.idtracker@ietfa.amsl.com> In-Reply-To: <20150309152026.11471.11879.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150309152026.11471.11879.idtracker@ietfa.amsl.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.38] Archived-At: Subject: [Teas] Fwd: I-D Action: draft-ietf-teas-lsp-diversity-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 16:50:55 -0000 Hi all,

we've uploaded a new version of the diversity draft.

Changes are resolving Lou's review comments that we got during the CCAMP session at IETF91.

Comments are welcome.


Thanks,
Dieter and co-authors


-------- Forwarded Message --------
Subject: I-D Action: draft-ietf-teas-lsp-diversity-01.txt
Date: Mon, 9 Mar 2015 08:20:26 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: teas@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF.

        Title           : Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route
        Authors         : Zafar Ali
                          George Swallow
                          Fatai Zhang
                          Dieter Beller
	Filename        : draft-ietf-teas-lsp-diversity-01.txt
	Pages           : 28
	Date            : 2015-03-09

Abstract:
   RFC 4874 specifies methods by which path exclusions can be
   communicated during RSVP-TE signaling in networks where precise
   explicit paths are not computed by the LSP source node. This
   document specifies procedures for additional route exclusion
   subobject based on Paths currently existing or expected to exist
   within the network.

   

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-teas-lsp-diversity-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-diversity-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From nobody Mon Mar 9 10:56:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33401A910A for ; Mon, 9 Mar 2015 10:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1iXo-DFvFiN for ; Mon, 9 Mar 2015 10:56:22 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B2F1A90FC for ; Mon, 9 Mar 2015 10:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=287; q=dns/txt; s=iport; t=1425923781; x=1427133381; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=lnWirezCy0/DfITh4Zh2gQnFHK31+OVzl3n+ZOLHgNw=; b=HglzDU8qpvp3p3kC0UKHxN+EKR11D4Wy+Pn/5USpWQd9+DzqhnzVXOpl slbCYLVvtrPOXYHAOEWx1Q+kRbq9nGxzh59ToSXRaviDIiXW8hj8zeghp UD6rHziIw0i7bzKmbyA6Xl9VlIodcPAPe89XoQM89Q5tprAbXHucYdqHX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBQDV3f1U/5JdJa1bgwZSWwPCaYVnCQKBKk0BAQEBAQF8hBEBBDo/EgEqFEImAQQODQGIJg3BGwEBAQEGAQEBAR6PVDGDHoEWBZAPim2DKIhThl8jg26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,369,1422921600"; d="scan'208";a="130244510" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 09 Mar 2015 17:56:21 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t29HuKpI009682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 17:56:21 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.151]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 12:56:20 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Agenda for Dallas Thread-Index: AdBakf6fdEmAMx0bSceNFm6Oo6jFvw== Date: Mon, 9 Mar 2015 17:56:19 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BB32AA@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.193.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: [Teas] Agenda for Dallas X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:56:24 -0000 All, The agenda has been uploaded; you can find it at http://www.ietf.org/procee= dings/92/agenda/agenda-92-teas. Please remember to send an update to the WG before the meeting for all draf= ts which are not being explicitly presented. Cheers Matt, Lou, Deborah and Pavan From nobody Mon Mar 9 10:59:16 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4931F1A9125; Mon, 9 Mar 2015 10:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z7G9koYgLp5; Mon, 9 Mar 2015 10:59:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D25721A9131; Mon, 9 Mar 2015 10:59:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309175909.32542.38226.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 10:59:09 -0700 Archived-At: Cc: teas chair , teas mailing list , RFC Editor Subject: [Teas] Protocol Action: 'GMPLS RSVP-TE Extensions for Lock Instruct and Loopback' to Proposed Standard (draft-ietf-teas-rsvp-te-li-lb-05.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:59:13 -0000 The IESG has approved the following document: - 'GMPLS RSVP-TE Extensions for Lock Instruct and Loopback' (draft-ietf-teas-rsvp-te-li-lb-05.txt) as Proposed Standard This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-li-lb/ Technical Summary This document specifies extensions to Resource Reservation Protocol- Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies which use Generalized Multi-Protocol Label Switching (GMPLS) for the control plane. Working Group Summary This document moved from the CCAMP to TEAS WGs as part of the routing WG changes. This document has been fairly noncontroversial. Document Quality The base GMPLS protocol has been implemented. The extensions defined in this document are compatible with earlier implementations and satisfy requirements previously documented in RFCs. While there have been no public statements on implementation, the authors are from multiple vendors and an operator, and implementation is expected. Personnel Lou Berger is the Document Shepherd Adrian Farrel is the Responsible Area Director RFC Editor Note s3.2, para 2: OLD: The ingress node MUST ensure that the entity (node or interface), at which loopback is intended to occur, is marked as a strict hop in the Explicit Route Object (ERO) subobject. NEW: The ingress node MUST ensure that the entity at which loopback is intended to occur is explicitly identified by the immediately preceding subobject of the ERO Hop Attributes subobject. END s3.2, para 3, AFTER Otherwise, the node SHOULD try to put the LSP into loopback mode. ADD The loopback SHOULD be enabled on the entity identified by the ERO subobject immediately prior to the ERO Hop Attributes subobject. If the immediately preceding subobject is a label subobject [RFC3473], the loopback SHOULD be enabled for the direction indicated by the U bit of the label subobject. END From nobody Mon Mar 9 11:06:23 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FE11A88A5; Mon, 9 Mar 2015 11:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_fzOsXDTxmL; Mon, 9 Mar 2015 11:06:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220781A9128; Mon, 9 Mar 2015 11:06:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTL30263; Mon, 09 Mar 2015 18:06:13 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Mar 2015 18:06:13 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Mon, 9 Mar 2015 11:06:08 -0700 From: Leeyoung To: "TEAS WG (teas@ietf.org)" , "actn@ietf.org" Thread-Topic: ACTN draft update Thread-Index: AdBak7gxNIzxgH73S5ak1lQYuIcqcw== Date: Mon, 9 Mar 2015 18:06:07 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C9548A@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.133.70] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729C9548Adfweml706chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] ACTN draft update X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 18:06:20 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729C9548Adfweml706chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Here's a couple of ACTN-related drafts: https://datatracker.ietf.org/doc/draft-ceccarelli-actn-framework/ https://datatracker.ietf.org/doc/draft-leebelotti-actn-info/ Thanks, Young and Daniel --_000_7AEB3D6833318045B4AE71C2C87E8E1729C9548Adfweml706chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Here’s a couple of ACTN-related drafts:

 

https://datatracker.ietf.org/doc/draft-ceccarelli= -actn-framework/

https://datatracker.ietf.org/doc/draft-leebelotti-actn= -info/

 

Thanks,

Young and Daniel

--_000_7AEB3D6833318045B4AE71C2C87E8E1729C9548Adfweml706chm_-- From nobody Mon Mar 9 13:13:03 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF001AC3E7; Mon, 9 Mar 2015 13:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiCM9JznNfCR; Mon, 9 Mar 2015 13:12:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F25D81AC3EE; Mon, 9 Mar 2015 13:12:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309201246.7568.85606.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 13:12:46 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:12:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Ingress Local Protection Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-teas-rsvp-ingress-protection-02.txt Pages : 23 Date : 2015-03-09 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-ingress-protection-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 10 01:52:35 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556EC1A1BF1; Tue, 10 Mar 2015 01:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS7nkNiRZkaS; Tue, 10 Mar 2015 01:52:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99431A7023; Tue, 10 Mar 2015 01:52:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQB62068; Tue, 10 Mar 2015 08:52:27 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Mar 2015 08:52:25 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.61]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Tue, 10 Mar 2015 16:52:23 +0800 From: "Zhangxian (Xian)" To: Gregory Mirsky , Robert Raszuk , Loa Andersson Thread-Topic: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang Thread-Index: AQHQWY7N8mPqrNg9FU+o0MVA+q+QpJ0SZ8GAgAMB0/A= Date: Tue, 10 Mar 2015 08:52:22 +0000 Message-ID: References: <54F88FE0.9040206@labn.net> <23CE718903A838468A8B325B80962F9B8705236A@BLREML509-MBX.china.huawei.com> <1c6cb7c87b1d44c880ddabb5947ebcea@ATL-SRV-MBX1.advaoptical.com> <40746B2300A8FC4AB04EE722A593182B85D178B3@ONWVEXCHMB04.ciena.com> <54FC161A.3070006@pi.nu> <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91C163@eusaamb103.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B47183FBCSZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "teas@ietf.org" , "Shah, Himanshu" Subject: Re: [Teas] [mpls] [Rtg-yang-coord] Generic LSP Yang X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 08:52:33 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B47183FBCSZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEdyZWcsIGFsbCwNCg0KWW91ciBpbnRlcnByZXRhdGlvbiBpcyBleGFjdGx5IHdoYXQgd2Ug aGF2ZSBpbiBtaW5kIGFuZCB0cmllZCB0byBleHBsYWluIGluIHRoZSBkcmFmdC4gWW91ciBwb2lu dC9zdWdnZXN0aW9uIGlzIHdlbGwgdGFrZW4gYW5kIHdlIGhvcGUgdGhhdCB0aGUgZGlzY3Vzc2lv bnMgcGxhbm5lZCBpbiBURUFTIHdpbGwgaGVscCB0byBhZGRyZXNzIGl0Lg0KDQpJZiB3ZSBoYXZl IG5vdCBtYWRlIGl0IGNsZWFybHkgaW4gdGhlIGRyYWZ0LCB3ZSB3YW50IHRvIGVtcGhhc2l6ZSB0 aGF0IDogIHRoaXMgbW9kZWwgaXMgb25seSBmb3IgdGhlIExTUCBvcGVyYXRpb25hbCBzdGF0ZSAo TFNQLURCKSBhbmQgTk9UIGEgZ2VuZXJpYyBzaWduYWxpbmctcHJvdG9jb2wgeWFuZyBtb2RlbCwg d2hpY2ggYWN0IGFzIGEgYmFzaXMgZm9yIGNvbmZpZ3VyaW5nIGFuZCBtYW5hZ2luZyBhbGwgc2ln bmFsaW5nIHByb3RvY29scy4gIEl0IG1lYW50IHRvIGJlIGEgaGVscGVyLW1vZHVsZSBmb3Igc2ln bmFsaW5nL3RlY2hub2xvZ3ktc3BlY2lmaWMgb25lcywgYXMgcmVwcmVzZW50ZWQgaW4gdGhlIGdy YXBoIERocnV2IG1lbnRpb25lZCBiZWZvcmUgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9tcGxzL2N1cnJlbnQvbXNnMTM4NjcuaHRtbCksIHNpbmNlIHdlL3RoZSBhdXRob3Jz IGJlbGlldmUgdGhlcmUgaXMgYSBzZXQgb2YgY29tbW9uIGVsZW1lbnRzL2luZm9ybWF0aW9uLg0K DQpSZWdhcmRzLA0KWGlhbiBhbmQgRGhydXYNCg0KRnJvbTogVGVhcyBbbWFpbHRvOnRlYXMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdyZWdvcnkgTWlyc2t5DQpTZW50OiAyMDE15bm0 M+aciDnml6UgMjo0OQ0KVG86IFJvYmVydCBSYXN6dWs7IExvYSBBbmRlcnNzb24NCkNjOiBtcGxz QGlldGYub3JnOyBTaGFoLCBIaW1hbnNodTsgdGVhc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtU ZWFzXSBbbXBsc10gW1J0Zy15YW5nLWNvb3JkXSBHZW5lcmljIExTUCBZYW5nDQoNCkhpIFJvYmVy dCwgZXQuIGFsLA0KaWYgSSBpbnRlcnByZXQgdGhlIOKAnExTUCBZQU5HIG1vZGVs4oCdLCB0aGVu IGl0IHJlYWRzIGFzIFlBTkcgbW9kZWwgb2YgTVBMUyBkYXRhIHBsYW5lLCBub3QgY29udHJvbCBw cm90b2NvbCwgYmUgaXQgUlNWUC1URSwgTERQLCBQQ0VQLCBvciBJR1AtVEUgb2YgU1BSSU5HLiBB bmQsIHNpbmNlIHRoZSBNUExTIGRhdGEgcGxhbmUgaXMgaW5kZWVkIGNvbW1vbiBhbmQgaW4gZmFj dCB0aGUgb25lIGFuZCBvbmx5LCBzdWNoIExTUCBZQU5HIG1vZGVsIHJpZ2h0ZnVsbHkgY2FuIGJl IGNoYXJhY3Rlcml6ZWQgYXMg4oCcR2VuZXJpY+KAnS4NCkJ1dCBpZiBhdXRob3JzIGludGVuZGVk IHRvIGRlc2NyaWJlIGNvbW1vbiBzZXQgYW1vbmcgbGlzdGVkIGFib3ZlIGNvbnRyb2wgcHJvdG9j b2xzIHBlcnRhaW5pbmcgdG8gc2lnbmFsaW5nIG9mIGFuIE1QTFMgTFNQLCB0aGVuLCBJTU8sIHN1 Y2ggY29tbW9uIHNldCBmaXJzdCBtdXN0IGJlIGRpc2N1c3NlZCBhbmQgaWRlbnRpZmllZCB0byBk ZW1vbnN0cmF0ZSB0aGF0IGl0IGRvZXMgZXhpc3QgYW5kIGlzIHN1ZmZpY2llbnQgdG8gaGF2ZSBZ QU5HIG1vZGVsIG9mIGl0cyBvd24gcmF0aGVyIHRoYW4gWUFORyBtb2RlbHMgdGhhdCBkZXNjcmli ZSBMU1AgY29udHJvbCBieSBlYWNoIHNpZ25hbGluZyBwcm90b2NvbHMuIFRoYXQgdG8gbWUgbG9v a3MgdmVyeSBtdWNoIGxpa2Ugd2hhdCBMSU1FIFdHIGlzIHdvcmtpbmcgb24sIGludmVzdGlnYXRp bmcgd2hldGhlciBjb21tb24gbW9kZWwgb2YgSVAsIElQL01QTFMsIE1QTFMtVFAsIGFuZCBUUklM TCBPQU0gZXhpc3RzIGFuZCBpdHMgZXh0ZW50IGlzIHN1ZmZpY2llbnQgdG8gYmUgb2YgaW50ZXJl c3QuDQoNCiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBHcmVnDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBTdW5kYXksIE1hcmNoIDA4LCAyMDE1 IDM6NTggQU0NClRvOiBMb2EgQW5kZXJzc29uDQpDYzogbXBsc0BpZXRmLm9yZzsgdGVhc0BpZXRm Lm9yZzsgU2hhaCwgSGltYW5zaHUNClN1YmplY3Q6IFJlOiBbVGVhc10gW21wbHNdIFtSdGcteWFu Zy1jb29yZF0gR2VuZXJpYyBMU1AgWWFuZw0KDQpIaSBMb2EsDQoNClRoZSB3YXkgSSByZWFkIEln b3Igc3RhdGVtZW50IGFuZCBhZ3JlZWQgd2l0aCBpdCBpbiBhIHNlbnNlIG9mICJub3RoaW5nIGlu IGNvbW1vbiIgd2FzIHRoYXQgaXQgd2FzIHJlZmVycmluZyB0byB0aGUgY29udHJvbCBwbGFuZS4N Cg0KVGhlIHN1YmplY3Qgb2YgdGhpcyB0aHJlYWQgaXMgIkdlbmVyaWMgTFNQIFlBTkciIGFuZCB0 byBtZSBZYW5nIG1vZGVsIGRlc2NyaWJlcyBjb250cm9sIGFzcGVjdCBvZiBwcm90b2NvbCBvciBm dW5jdGlvbmFsaXR5IG5vdCB0aGUgY2hvaWNlIG9mIGZvcndhcmRpbmcgaGVhZGVyIGluIHRoZSBk YXRhIHBsYW5lLg0KDQpTbyBpZiB5b3UgYW5kIG90aGVycyBhZ3JlZSB3ZSBzaG91bGQgYmUgYWxs IGluIHN5bmMgYW5kIHBlcmhhcHMgd2UgY291bGQgY29uc2lkZXIgYXMgcHJvcG9zZWQgYmVmb3Jl IEdlbmVyaWMgRW5naW5lZXJlZCBQYXRoIG1vZGVsIGJyYW5jaGluZyBhdCB0aGUgbG93ZXIgbGF5 ZXIgYmV0d2VlbiB1bmljYXN0IGFuZCBtdWx0aWNhc3QuDQoNCkhvd2V2ZXIgaWYgeW91IHN0aWxs IHRoaW5rIHRoYXQgWWFuZyBpcyBhYm91dCBkYXRhIHBsYW5lIGFuZCBPQU0gdGhlbiBwZXJoYXBz IHdlIGhhdmUgYSBiaWdnZXIgaXNzdWUgaGVyZSAuLi4uDQoNCkNoZWVycywNClIuDQoNCg0KDQoN Ck9uIFN1biwgTWFyIDgsIDIwMTUgYXQgMTA6MjcgQU0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5u dTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQpIaW1hbnNodSwgZXQuYWw8aHR0cDovL2V0LmFs Pi4sDQoNCkkgdGhpbmsgdGhlcmUgYXJlIHR3byBpc3N1ZXMgaGVyZSBhbmQgaWYgc29ydGluZyB0 aGVtIG91dCBjb3JycmVjdGx5DQp3ZSBhcmUgdmVyeSBjbG9zZS4NCg0KVGhlIGZpcnN0IGlzc3Vl IGlzIHNpbWlsYXJpdGllcyBiZXR3ZWVuIGRpZmZlcmVudCB0eXBlcyBvZiBMU1BzLg0KDQpIZXJl IEkgc2FpZCB0aGF0LCBhdCBsZWFzdCBmb3IgYSBNUExTIFBTTiwgdGhlcmUgYXJlIHNpbWlsYXJp dGllcywNCmUuZy4gdGhlIGRhdGEgcGxhbmUgaXMgKG5lYXJseSkgdGhlIHNhbWUuIFRoaXMgd2Fz IHNhaWQgaW4gcmVhY3Rpb24NCnRvIElnb3IncyBzdGF0ZW1lbnQgIklNSE8gVEUtTFNQLCBMRFAt TFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZw0KaW4gY29tbW9uLiIgSSBzdGlsbCBkb24n dCB0aGluayB0aGF0IElnb3IncyBzdGF0ZW1lbnQgaXMgcmVhbGx5IGNvcnJlY3QuDQpJZiBoZSBo YWQgc2FpZCAiSU1ITyB0aGVyZSBhcmUgbm90IGVub3VnaCBzaW1pbGFyaXRlcyBiZXR3ZWVuIFRF LUxTUCwNCkxEUC1MU1AgYW5kIFNQUklORy1MU1AgdG8gbW90aXZhdGUgYSBjb21tb24gbW9kZWwi LiBJIHRoaW5rIHRoYXQgd2UgYmUNCmEgbXVjaCBtb3JlIGFjY3VyYXRlIHN0YXRlbWVudC4NCg0K QW5kIHRoYXQgaXMgdGhlIG90aGVyIGlzc3VlIC0gSXMgaXQgcmVhc29uYWJsZSB0byBtb2RlbCBU RS1MU1AsDQpMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGluIHRoZSBzYW1lIG1vZGVsPyBJIGRvbid0 IG5vdCB0aGluayBpdCBpcywNCmJ1dCB0aGF0IHdlIG5lZWQgYW4gb3ZlcmxhcCBvZiBwZW9wbGUg d29ya2luZyB3aXRoIHRoZSBkaWZmZXJlbnQgbW9kZWxzLg0KDQpIb3BlIHRoaXMgaXMgY2xlYXIg ZW5vdWdoLg0KDQovTG9hDQoNCg0KT24gMjAxNS0wMy0wNyAyMzoxOSwgU2hhaCwgSGltYW5zaHUg d3JvdGU6DQovSSBhZ3JlZSB3aXRoIFJvYmVydCBhbmQgSWdvciwgcHV0dGluZyBldmVyeXRoaW5n IGluIHRoZSBzYW1lIGJ1Y2tldA0KYmVjYXVzZSBvZiBjb21tb24gZGF0YSBwbGFuZSAmIE9BTSBk b2VzIG5vdCBqdXN0aWZ5Li8NCg0KL1dlIHdvdWxkbuKAmXQgY29uc2lkZXIgZG9pbmcgc2FtZSBm b3IgSVAgZGF0YSBwbGFuZS4uLw0KDQovSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFyYXRlIHRoZXNl IG1vZGVscyBhbmQgYXMgbWVudGlvbmVkIGVhcmxpZXIsDQp0aGVyZSBpcyBhbHJlYWR5IHdvcmsg Z29pbmcgb24gaW4gcmVzcGVjdGl2ZSBXR3MuLw0KDQovLw0KDQovVGhhbmtzLC8NCg0KL2hpbWFu c2h1Lw0KDQovLw0KDQovLw0KDQovLw0KDQoqRnJvbToqbXBscyBbbWFpbHRvOm1wbHMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAq TG9hIEFuZGVyc3Nvbg0KKlNlbnQ6KiBTYXR1cmRheSwgTWFyY2ggMDcsIDIwMTUgODoxOCBBTQ0K KlRvOiogdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4sIG1wbHNAaWV0Zi5vcmc8 bWFpbHRvOm1wbHNAaWV0Zi5vcmc+LCByb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJh c3p1ay5uZXQ+DQoqU3ViamVjdDoqIFJlOiBbbXBsc10gW1J0Zy15YW5nLWNvb3JkXSBbVGVhc10g R2VuZXJpYyBMU1AgWWFuZw0KDQpSb2JlcnQsDQoNCiBGcm9tIG9uZSBwZXJzcGVjdGl2ZSBJIGFn cmVlIHdpdGggeW91IGFuZCBJZ29yLCBob3dldmVyIGlmIHlvdSB0aGluaw0KYWJvdXQgTVBMUyBM U1BzLCBmcm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSAtIGFuZCB0aGF0IGlzIHdoZXJlIE9B TQ0Kb3BlcmF0ZXMsIHRoZXJlIGFsbW9zdCBubyBkaWZmZXJlbmNlIGJldHdlZW4gYSBURS1MU1Ag YSBMRFAtTFNQIGFuZCBhDQpTUFJJTkcgTVBMUyBMU1AgY29tZSB2ZXJ5IGNsb3NlLg0KDQpJZiB5 b3UgdGhlIG90aGVyIGhhbmQgdGhpbmsgb2YgTFNQcyBmb3Igb3RoZXIgZGF0YSBwbGFuZXMgdGhl ICJub3RoaW5nDQppbiBjb21tb24iIGlzIGFuIGFsbW9zdCB0cnVlIHN0YXRlbWVudC4gRnJvbSB0 aGF0IHBvaW50IG9mIHZpZXcgSSB0aGluaw0KZGlmZmVyZW50IG1vZGVscyBhcmUgd2hlcmUgd2Ug d2lsbCBlbmQgdXAsIGJ1dCBJIGFsc28gdGhpbmsgdGhhdCB3ZSBuZWVkDQoic2VwYXJhdGlvbiB3 aXRoIG1vZGVyYXRpb24iLg0KDQogIEJ1dCBub3RoaW5nIGlzIHNvIHNpbXBsZSB0aGF0IHdlIGNh biBjYXB0dXJlIGl0IGluIG9uZSB2ZXJ5IHNpbXBsZQ0Kc3RhdGVtZW50LCB3ZSBoYXZlIGhhY2tp bmcgYXdheSBvbiB0aGlzIGZvciAzMCB5ZWFycyBub3csIEknZCBhZHZpY2UNCnRha2luZyBhcmNo aXRlY3R1cmUgYW5kIGhpc3RvcnkgaW50byBjb25zaWRlcmF0aW9uLCBhcyB3ZWxsIGFzIHZpZXdp bmcNCnRoZSBza3kgZnJvbSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSB0aGFuIGZyb20gdGhlIGJv dHRvbSBvZiBhIGRlZXAgd2VsbC4NCg0KTGV0IG1lIGFsc28gc2F5IHRoYXQgSSdtIHZlcnkgc3Vw cG9ydGl2ZSBvZiBhbGwgdGhlIGdvb2Qgd29yayBnb2luZyBvbg0KaW4gdGhpcyBhcmVhLg0KDQov TG9hDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCg0KT24gMDcgTWFyIDIwMTUsIGF0IDE5OjQ3LCBS b2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+ DQo8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+PiB3 cm90ZToNCg0KICAgIEkgd291bGQgYWdyZWUgd2l0aCBJZ29yLg0KDQogICAgT3RoZXIgdGhlbiBu YW1lIG92ZXJsYXAgdGhvc2UgYXJlIGNvbXBsZXRlbHkgZGlmZmVyZW50IHRlY2hub2xvZ2llcw0K ICAgIGFuZCBhcnRpZmljaWFsbHkgcHV0dGluZyB0aGVtIHVuZGVyICJMU1AiIHVtYnJlbGxhIGp1 c3QgZG9lcyBub3QNCiAgICBicmluZyBhbnkgdmFsdWUsIGJ1dCBvbmx5IGNvbmZ1c2VzIHRoaW5n cyBldmVuIG1vcmUuDQoNCiAgICBROiBXaGF0IFNQUklORy1MU1AgaGFzIGFueXRoaW5nIGluIGNv bW1vbiB3aXRoICJsYWJlbCIgd2hlbiB5b3UgdXNlDQogICAgdjYgaGVhZGVyID8NCg0KICAgIElm IHlvdSB3YW50IHRvIHNlYXJjaCBmb3Igc29tZSBjb21tb25hbGl0aWVzIGxldCdzIHJlbW92ZSBM RFAtTFNQcw0KICAgIGZyb20gdGhpcyBtaXggKGFzIHRoZSBpcyBub3QgcmVsZXZhbnQpIGFuZCBs ZWF2ZSBURS1MU1AgJiBTUFJJTkcgKw0KICAgIG1heWJlIGFsc28gYWRkIEJJRVIgYXMgd2VsbCBh cyBjaGFuZ2UgdGhlIG5hbWUgdG8gR2VuZXJpYy1FUA0KICAgIChFbmdpbmVlcmVkIFBhdGhzKS4N Cg0KICAgIEkgc2VlIG5vIHZhbHVlIG9mIGdvcnVwaW5nIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQg ZGF0YSBwbGFuZSB1c2VzDQogICAgbXBscyBsYWJlbHMsIGJ1dCByYXRoZXIgSSB3b3VsZCBzZWUg cmVhc29uYWJsZSB0byBwcm92aWRlIG1vZGVscw0KICAgIGJhc2VkIG9uIHRoZSB0cmFuc3BvcnQg cGF0aCBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSB0cmFmZmljIGl0IGlzIHRvDQogICAgY2Fycnku DQoNCiAgICBCZXN0LA0KDQogICAgci4NCg0KICAgIE9uIEZyaSwgTWFyIDYsIDIwMTUgYXQgMjox MSBQTSwgSWdvciBCcnlza2luDQogICAgPElCcnlza2luQGFkdmFvcHRpY2FsLmNvbTxtYWlsdG86 SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPiA8bWFpbHRvOklCcnlza2luQGFkdmFvcHRpY2FsLmNv bTxtYWlsdG86SUJyeXNraW5AYWR2YW9wdGljYWwuY29tPj4+IHdyb3RlOg0KDQogICAgRHJ1diwN Cg0KICAgIElNSE8gVEUtTFNQLCBMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGhhdmUgbm90aGluZyBp biBjb21tb24uIFRoZXkNCiAgICBzaG91bGQgaGF2ZSB0b3RhbGx5IGluZGVwZW5kZW50IG1vZGVs cyBlYWNoIGJlaW5nIGRldmVsb3BlZCBpbg0KICAgIHJlc3BlY3RpdmUgV0cuDQoNCiAgICBJZ29y DQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgIFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdA0KICAgIFJ0Zy15YW5nLWNvb3JkQGlldGYu b3JnPG1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZz4gPG1haWx0bzpSdGcteWFuZy1jb29y ZEBpZXRmLm9yZzxtYWlsdG86UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc+Pg0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcg bGlzdA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzps b2FAbWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAg ICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2ll cyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDcz OSUyMDgxJTIwMjElMjA2ND4NCg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B47183FBCSZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksIEdyZWcsIGFs bCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50OjEwLjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Zb3VyIGludGVycHJldGF0aW9uIGlzIGV4YWN0bHkgd2hhdCB3ZSBoYXZlIGlu IG1pbmQgYW5kIHRyaWVkIHRvIGV4cGxhaW4gaW4gdGhlIGRyYWZ0LiBZb3VyIHBvaW50L3N1Z2dl c3Rpb24gaXMgd2VsbA0KIHRha2VuIGFuZCB3ZSBob3BlIHRoYXQgdGhlIGRpc2N1c3Npb25zIHBs YW5uZWQgaW4gVEVBUyB3aWxsIGhlbHAgdG8gYWRkcmVzcyBpdC4gPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MTAuNXB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWluZGVudDoxMC41cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SWYgd2UgaGF2ZSBub3QgbWFkZSBpdCBjbGVhcmx5IGluIHRoZSBk cmFmdCwgd2Ugd2FudCB0byBlbXBoYXNpemUgdGhhdCA6ICZuYnNwO3RoaXMgbW9kZWwgaXMgb25s eSBmb3IgdGhlIExTUCBvcGVyYXRpb25hbA0KIHN0YXRlIChMU1AtREIpIGFuZCBOT1QgYSBnZW5l cmljIHNpZ25hbGluZy1wcm90b2NvbCB5YW5nIG1vZGVsLCB3aGljaCBhY3QgYXMgYSBiYXNpcyBm b3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIGFsbCBzaWduYWxpbmcgcHJvdG9jb2xzLiAmbmJz cDtJdCBtZWFudCB0byBiZSBhIGhlbHBlci1tb2R1bGUgZm9yIHNpZ25hbGluZy90ZWNobm9sb2d5 LXNwZWNpZmljIG9uZXMsIGFzIHJlcHJlc2VudGVkIGluIHRoZSBncmFwaCBEaHJ1diBtZW50aW9u ZWQgYmVmb3JlDQogKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9tcGxzL2N1cnJlbnQvbXNnMTM4NjcuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9tcGxzL2N1cnJlbnQvbXNnMTM4NjcuaHRtbDwvc3Bhbj48L2E+KSwgc2luY2Ugd2UvdGhlIGF1 dGhvcnMgYmVsaWV2ZSB0aGVyZSBpcyBhIHNldCBvZiBjb21tb24gZWxlbWVudHMvaW5mb3JtYXRp b24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlhpYW4gYW5kIERocnV2Jm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5HcmVnb3J5IE1pcnNreTxicj4NCjxiPlNlbnQ6PC9iPiAyMDE1PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5bm0PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Mzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZMiPuaciDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAyOjQ5PGJyPg0KPGI+VG86PC9iPiBSb2JlcnQg UmFzenVrOyBMb2EgQW5kZXJzc29uPGJyPg0KPGI+Q2M6PC9iPiBtcGxzQGlldGYub3JnOyBTaGFo LCBIaW1hbnNodTsgdGVhc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNd IFttcGxzXSBbUnRnLXlhbmctY29vcmRdIEdlbmVyaWMgTFNQIFlhbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SGkgUm9iZXJ0LCBldC4gYWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5pZiBJIGludGVycHJldCB0aGUg4oCcTFNQIFlBTkcgbW9kZWzigJ0sIHRoZW4gaXQgcmVh ZHMgYXMgWUFORyBtb2RlbCBvZiBNUExTIGRhdGEgcGxhbmUsIG5vdCBjb250cm9sIHByb3RvY29s LCBiZSBpdCBSU1ZQLVRFLCBMRFAsIFBDRVAsIG9yIElHUC1URQ0KIG9mIFNQUklORy4gQW5kLCBz aW5jZSB0aGUgTVBMUyBkYXRhIHBsYW5lIGlzIGluZGVlZCBjb21tb24gYW5kIGluIGZhY3QgdGhl IG9uZSBhbmQgb25seSwgc3VjaCBMU1AgWUFORyBtb2RlbCByaWdodGZ1bGx5IGNhbiBiZSBjaGFy YWN0ZXJpemVkIGFzIOKAnEdlbmVyaWPigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5CdXQgaWYgYXV0aG9ycyBpbnRlbmRlZCB0byBkZXNjcmliZSBjb21tb24g c2V0IGFtb25nIGxpc3RlZCBhYm92ZSBjb250cm9sIHByb3RvY29scyBwZXJ0YWluaW5nIHRvIHNp Z25hbGluZyBvZiBhbiBNUExTIExTUCwgdGhlbiwgSU1PLCBzdWNoIGNvbW1vbg0KIHNldCBmaXJz dCBtdXN0IGJlIGRpc2N1c3NlZCBhbmQgaWRlbnRpZmllZCB0byBkZW1vbnN0cmF0ZSB0aGF0IGl0 IGRvZXMgZXhpc3QgYW5kIGlzIHN1ZmZpY2llbnQgdG8gaGF2ZSBZQU5HIG1vZGVsIG9mIGl0cyBv d24gcmF0aGVyIHRoYW4gWUFORyBtb2RlbHMgdGhhdCBkZXNjcmliZSBMU1AgY29udHJvbCBieSBl YWNoIHNpZ25hbGluZyBwcm90b2NvbHMuIFRoYXQgdG8gbWUgbG9va3MgdmVyeSBtdWNoIGxpa2Ug d2hhdCBMSU1FIFdHIGlzIHdvcmtpbmcNCiBvbiwgaW52ZXN0aWdhdGluZyB3aGV0aGVyIGNvbW1v biBtb2RlbCBvZiBJUCwgSVAvTVBMUywgTVBMUy1UUCwgYW5kIFRSSUxMIE9BTSBleGlzdHMgYW5k IGl0cyBleHRlbnQgaXMgc3VmZmljaWVudCB0byBiZSBvZiBpbnRlcmVzdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgR3JlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOnRl YXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxi cj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1hcmNoIDA4LCAyMDE1IDM6NTggQU08YnI+DQo8Yj5U bzo8L2I+IExvYSBBbmRlcnNzb248YnI+DQo8Yj5DYzo8L2I+IG1wbHNAaWV0Zi5vcmc7IHRlYXNA aWV0Zi5vcmc7IFNoYWgsIEhpbWFuc2h1PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVGVhc10g W21wbHNdIFtSdGcteWFuZy1jb29yZF0gR2VuZXJpYyBMU1AgWWFuZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkhpIExvYSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgd2F5IEkgcmVhZCBJZ29yIHN0 YXRlbWVudCBhbmQgYWdyZWVkIHdpdGggaXQgaW4gYSBzZW5zZSBvZiAmcXVvdDtub3RoaW5nIGlu IGNvbW1vbiZxdW90OyB3YXMgdGhhdCBpdCB3YXMgcmVmZXJyaW5nIHRvIHRoZSBjb250cm9sIHBs YW5lLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBzdWJqZWN0IG9mIHRoaXMgdGhy ZWFkIGlzICZxdW90O0dlbmVyaWMgTFNQIFlBTkcmcXVvdDsgYW5kIHRvIG1lIFlhbmcgbW9kZWwg ZGVzY3JpYmVzIGNvbnRyb2wgYXNwZWN0IG9mIHByb3RvY29sIG9yIGZ1bmN0aW9uYWxpdHkgbm90 IHRoZSBjaG9pY2Ugb2YgZm9yd2FyZGluZyBoZWFkZXIgaW4gdGhlIGRhdGEgcGxhbmUuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+U28gaWYgeW91IGFuZCBvdGhlcnMgYWdyZWUgd2Ugc2hv dWxkIGJlIGFsbCBpbiBzeW5jIGFuZCBwZXJoYXBzIHdlIGNvdWxkIGNvbnNpZGVyIGFzIHByb3Bv c2VkIGJlZm9yZSBHZW5lcmljIEVuZ2luZWVyZWQgUGF0aCBtb2RlbCBicmFuY2hpbmcgYXQgdGhl IGxvd2VyIGxheWVyIGJldHdlZW4gdW5pY2FzdCBhbmQgbXVsdGljYXN0LiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPkhvd2V2ZXIgaWYgeW91IHN0aWxsIHRoaW5rIHRoYXQgWWFuZyBpcyBh Ym91dCBkYXRhIHBsYW5lIGFuZCBPQU0gdGhlbiBwZXJoYXBzIHdlIGhhdmUgYSBiaWdnZXIgaXNz dWUgaGVyZSAuLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Q2hlZXJzLDxicj4NClIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBTdW4sIE1hciA4LCAyMDE1IGF0IDEw OjI3IEFNLCBMb2EgQW5kZXJzc29uICZsdDs8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJn ZXQ9Il9ibGFuayI+bG9hQHBpLm51PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpbWFuc2h1LCA8YSBo cmVmPSJodHRwOi8vZXQuYWwiIHRhcmdldD0iX2JsYW5rIj4NCmV0LmFsPC9hPi4sPGJyPg0KPGJy Pg0KSSB0aGluayB0aGVyZSBhcmUgdHdvIGlzc3VlcyBoZXJlIGFuZCBpZiBzb3J0aW5nIHRoZW0g b3V0IGNvcnJyZWN0bHk8YnI+DQp3ZSBhcmUgdmVyeSBjbG9zZS48YnI+DQo8YnI+DQpUaGUgZmly c3QgaXNzdWUgaXMgc2ltaWxhcml0aWVzIGJldHdlZW4gZGlmZmVyZW50IHR5cGVzIG9mIExTUHMu PGJyPg0KPGJyPg0KSGVyZSBJIHNhaWQgdGhhdCwgYXQgbGVhc3QgZm9yIGEgTVBMUyBQU04sIHRo ZXJlIGFyZSBzaW1pbGFyaXRpZXMsPGJyPg0KZS5nLiB0aGUgZGF0YSBwbGFuZSBpcyAobmVhcmx5 KSB0aGUgc2FtZS4gVGhpcyB3YXMgc2FpZCBpbiByZWFjdGlvbjxicj4NCnRvIElnb3IncyBzdGF0 ZW1lbnQgJnF1b3Q7SU1ITyBURS1MU1AsIExEUC1MU1AgYW5kIFNQUklORy1MU1AgaGF2ZSBub3Ro aW5nPGJyPg0KaW4gY29tbW9uLiZxdW90OyBJIHN0aWxsIGRvbid0IHRoaW5rIHRoYXQgSWdvcidz IHN0YXRlbWVudCBpcyByZWFsbHkgY29ycmVjdC48YnI+DQpJZiBoZSBoYWQgc2FpZCAmcXVvdDtJ TUhPIHRoZXJlIGFyZSBub3QgZW5vdWdoIHNpbWlsYXJpdGVzIGJldHdlZW4gVEUtTFNQLDxicj4N CkxEUC1MU1AgYW5kIFNQUklORy1MU1AgdG8gbW90aXZhdGUgYSBjb21tb24gbW9kZWwmcXVvdDsu IEkgdGhpbmsgdGhhdCB3ZSBiZTxicj4NCmEgbXVjaCBtb3JlIGFjY3VyYXRlIHN0YXRlbWVudC48 YnI+DQo8YnI+DQpBbmQgdGhhdCBpcyB0aGUgb3RoZXIgaXNzdWUgLSBJcyBpdCByZWFzb25hYmxl IHRvIG1vZGVsIFRFLUxTUCw8YnI+DQpMRFAtTFNQIGFuZCBTUFJJTkctTFNQIGluIHRoZSBzYW1l IG1vZGVsPyBJIGRvbid0IG5vdCB0aGluayBpdCBpcyw8YnI+DQpidXQgdGhhdCB3ZSBuZWVkIGFu IG92ZXJsYXAgb2YgcGVvcGxlIHdvcmtpbmcgd2l0aCB0aGUgZGlmZmVyZW50IG1vZGVscy48YnI+ DQo8YnI+DQpIb3BlIHRoaXMgaXMgY2xlYXIgZW5vdWdoLjxicj4NCjxicj4NCi9Mb2E8YnI+DQo8 YnI+DQo8YnI+DQpPbiAyMDE1LTAzLTA3IDIzOjE5LCBTaGFoLCBIaW1hbnNodSB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4vSSBhZ3JlZSB3aXRoIFJvYmVydCBhbmQg SWdvciwgcHV0dGluZyBldmVyeXRoaW5nIGluIHRoZSBzYW1lIGJ1Y2tldDxicj4NCmJlY2F1c2Ug b2YgY29tbW9uIGRhdGEgcGxhbmUgJmFtcDsgT0FNIGRvZXMgbm90IGp1c3RpZnkuLzxicj4NCjxi cj4NCi9XZSB3b3VsZG7igJl0IGNvbnNpZGVyIGRvaW5nIHNhbWUgZm9yIElQIGRhdGEgcGxhbmUu Li88YnI+DQo8YnI+DQovSSB0aGluayB3ZSBuZWVkIHRvIHNlcGFyYXRlIHRoZXNlIG1vZGVscyBh bmQgYXMgbWVudGlvbmVkIGVhcmxpZXIsPGJyPg0KdGhlcmUgaXMgYWxyZWFkeSB3b3JrIGdvaW5n IG9uIGluIHJlc3BlY3RpdmUgV0dzLi88YnI+DQo8YnI+DQovLzxicj4NCjxicj4NCi9UaGFua3Ms Lzxicj4NCjxicj4NCi9oaW1hbnNodS88YnI+DQo8YnI+DQovLzxicj4NCjxicj4NCi8vPGJyPg0K PGJyPg0KLy88YnI+DQo8YnI+DQoqRnJvbToqbXBscyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpt cGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSAqT24gQmVoYWxmIE9mICpMb2EgQW5kZXJzc29uPGJyPg0KKlNlbnQ6KiBTYXR1cmRh eSwgTWFyY2ggMDcsIDIwMTUgODoxOCBBTTxicj4NCipUbzoqIDxhIGhyZWY9Im1haWx0bzp0ZWFz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGVhc0BpZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1h aWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptcGxzQGlldGYub3JnPC9hPiwg PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0 QHJhc3p1ay5uZXQ8L2E+PGJyPg0KKlN1YmplY3Q6KiBSZTogW21wbHNdIFtSdGcteWFuZy1jb29y ZF0gW1RlYXNdIEdlbmVyaWMgTFNQIFlhbmc8YnI+DQo8YnI+DQpSb2JlcnQsPGJyPg0KPGJyPg0K Jm5ic3A7RnJvbSBvbmUgcGVyc3BlY3RpdmUgSSBhZ3JlZSB3aXRoIHlvdSBhbmQgSWdvciwgaG93 ZXZlciBpZiB5b3UgdGhpbms8YnI+DQphYm91dCBNUExTIExTUHMsIGZyb20gYSBkYXRhIHBsYW5l IHBlcnNwZWN0aXZlIC0gYW5kIHRoYXQgaXMgd2hlcmUgT0FNPGJyPg0Kb3BlcmF0ZXMsIHRoZXJl IGFsbW9zdCBubyBkaWZmZXJlbmNlIGJldHdlZW4gYSBURS1MU1AgYSBMRFAtTFNQIGFuZCBhPGJy Pg0KU1BSSU5HIE1QTFMgTFNQIGNvbWUgdmVyeSBjbG9zZS48YnI+DQo8YnI+DQpJZiB5b3UgdGhl IG90aGVyIGhhbmQgdGhpbmsgb2YgTFNQcyBmb3Igb3RoZXIgZGF0YSBwbGFuZXMgdGhlICZxdW90 O25vdGhpbmc8YnI+DQppbiBjb21tb24mcXVvdDsgaXMgYW4gYWxtb3N0IHRydWUgc3RhdGVtZW50 LiBGcm9tIHRoYXQgcG9pbnQgb2YgdmlldyBJIHRoaW5rPGJyPg0KZGlmZmVyZW50IG1vZGVscyBh cmUgd2hlcmUgd2Ugd2lsbCBlbmQgdXAsIGJ1dCBJIGFsc28gdGhpbmsgdGhhdCB3ZSBuZWVkPGJy Pg0KJnF1b3Q7c2VwYXJhdGlvbiB3aXRoIG1vZGVyYXRpb24mcXVvdDsuPGJyPg0KPGJyPg0KJm5i c3A7IEJ1dCBub3RoaW5nIGlzIHNvIHNpbXBsZSB0aGF0IHdlIGNhbiBjYXB0dXJlIGl0IGluIG9u ZSB2ZXJ5IHNpbXBsZTxicj4NCnN0YXRlbWVudCwgd2UgaGF2ZSBoYWNraW5nIGF3YXkgb24gdGhp cyBmb3IgMzAgeWVhcnMgbm93LCBJJ2QgYWR2aWNlPGJyPg0KdGFraW5nIGFyY2hpdGVjdHVyZSBh bmQgaGlzdG9yeSBpbnRvIGNvbnNpZGVyYXRpb24sIGFzIHdlbGwgYXMgdmlld2luZzxicj4NCnRo ZSBza3kgZnJvbSBhIGRpZmZlcmVudCBwZXJzcGVjdGl2ZSB0aGFuIGZyb20gdGhlIGJvdHRvbSBv ZiBhIGRlZXAgd2VsbC48YnI+DQo8YnI+DQpMZXQgbWUgYWxzbyBzYXkgdGhhdCBJJ20gdmVyeSBz dXBwb3J0aXZlIG9mIGFsbCB0aGUgZ29vZCB3b3JrIGdvaW5nIG9uPGJyPg0KaW4gdGhpcyBhcmVh Ljxicj4NCjxicj4NCi9Mb2E8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgaVBhZDxicj4NCjxicj4N Cjxicj4NCk9uIDA3IE1hciAyMDE1LCBhdCAxOTo0NywgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1 ay5uZXQ8L2E+PGJyPg0KJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5u ZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgd291bGQgYWdyZWUgd2l0aCBJZ29yLjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgT3RoZXIgdGhlbiBuYW1lIG92ZXJsYXAgdGhvc2UgYXJlIGNvbXBs ZXRlbHkgZGlmZmVyZW50IHRlY2hub2xvZ2llczxicj4NCiZuYnNwOyAmbmJzcDsgYW5kIGFydGlm aWNpYWxseSBwdXR0aW5nIHRoZW0gdW5kZXIgJnF1b3Q7TFNQJnF1b3Q7IHVtYnJlbGxhIGp1c3Qg ZG9lcyBub3Q8YnI+DQombmJzcDsgJm5ic3A7IGJyaW5nIGFueSB2YWx1ZSwgYnV0IG9ubHkgY29u ZnVzZXMgdGhpbmdzIGV2ZW4gbW9yZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFE6IFdoYXQg U1BSSU5HLUxTUCBoYXMgYW55dGhpbmcgaW4gY29tbW9uIHdpdGggJnF1b3Q7bGFiZWwmcXVvdDsg d2hlbiB5b3UgdXNlPGJyPg0KJm5ic3A7ICZuYnNwOyB2NiBoZWFkZXIgPzxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDsgSWYgeW91IHdhbnQgdG8gc2VhcmNoIGZvciBzb21lIGNvbW1vbmFsaXRpZXMg bGV0J3MgcmVtb3ZlIExEUC1MU1BzPGJyPg0KJm5ic3A7ICZuYnNwOyBmcm9tIHRoaXMgbWl4IChh cyB0aGUgaXMgbm90IHJlbGV2YW50KSBhbmQgbGVhdmUgVEUtTFNQICZhbXA7IFNQUklORyAmIzQz Ozxicj4NCiZuYnNwOyAmbmJzcDsgbWF5YmUgYWxzbyBhZGQgQklFUiBhcyB3ZWxsIGFzIGNoYW5n ZSB0aGUgbmFtZSB0byBHZW5lcmljLUVQPGJyPg0KJm5ic3A7ICZuYnNwOyAoRW5naW5lZXJlZCBQ YXRocykuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJIHNlZSBubyB2YWx1ZSBvZiBnb3J1cGlu ZyBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IGRhdGEgcGxhbmUgdXNlczxicj4NCiZuYnNwOyAmbmJz cDsgbXBscyBsYWJlbHMsIGJ1dCByYXRoZXIgSSB3b3VsZCBzZWUgcmVhc29uYWJsZSB0byBwcm92 aWRlIG1vZGVsczxicj4NCiZuYnNwOyAmbmJzcDsgYmFzZWQgb24gdGhlIHRyYW5zcG9ydCBwYXRo IGNoYXJhY3RlcmlzdGljcyBmb3IgdGhlIHRyYWZmaWMgaXQgaXMgdG88YnI+DQombmJzcDsgJm5i c3A7IGNhcnJ5Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQmVzdCw8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IHIuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBGcmksIE1hciA2LCAyMDE1 IGF0IDI6MTEgUE0sIElnb3IgQnJ5c2tpbjxicj4NCiZuYnNwOyAmbmJzcDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb20iIHRhcmdldD0iX2JsYW5rIj5JQnJ5c2tp bkBhZHZhb3B0aWNhbC5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOklCcnlza2lu QGFkdmFvcHRpY2FsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPklCcnlza2luQGFkdmFvcHRpY2FsLmNv bTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IERydXYsPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBJTUhPIFRFLUxTUCwgTERQLUxTUCBhbmQgU1BSSU5HLUxTUCBo YXZlIG5vdGhpbmcgaW4gY29tbW9uLiBUaGV5PGJyPg0KJm5ic3A7ICZuYnNwOyBzaG91bGQgaGF2 ZSB0b3RhbGx5IGluZGVwZW5kZW50IG1vZGVscyBlYWNoIGJlaW5nIGRldmVsb3BlZCBpbjxicj4N CiZuYnNwOyAmbmJzcDsgcmVzcGVjdGl2ZSBXRy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEln b3I8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBSdGcteWFuZy1jb29yZCBtYWls aW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpSdGcteWFuZy1jb29y ZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPC9hPiAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPC9hPiZndDs8YnI+DQombmJzcDsgJm5i c3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlh bmctY29vcmQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRnLXlhbmctY29vcmQ8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUZWFzIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+VGVhc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RlYXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RlYXM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48 YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLSA8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0KPHNw YW4gY2xhc3M9ImhvZW56YiI+TG9hIEFuZGVyc3NvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGVtYWlsOiA8YSBocmVmPSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0YXJnZXQ9Il9i bGFuayI+DQpsb2FAbWFpbDAxLmh1YXdlaS5jb208L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNz PSJob2VuemIiPlNlbmlvciBNUExTIEV4cGVydCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFuayI+DQpsb2FAcGku bnU8L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkh1YXdlaSBUZWNobm9sb2dp ZXMgKGNvbnN1bHRhbnQpJm5ic3A7ICZuYnNwOyAmbmJzcDtwaG9uZTogPGEgaHJlZj0idGVsOiUy QjQ2JTIwNzM5JTIwODElMjAyMSUyMDY0IiB0YXJnZXQ9Il9ibGFuayI+DQomIzQzOzQ2IDczOSA4 MSAyMSA2NDwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B47183FBCSZXEMA512MBSchi_-- From nobody Tue Mar 10 12:37:07 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056C41A8843 for ; Tue, 10 Mar 2015 12:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX3a-sMCGEJd for ; Tue, 10 Mar 2015 12:12:03 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 87EBC1A0169 for ; Tue, 10 Mar 2015 12:12:03 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id t2AJC2la016300 for ; Tue, 10 Mar 2015 15:12:02 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id t2AJC1he011099 for ; Tue, 10 Mar 2015 15:12:01 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Tue, 10 Mar 2015 15:12:01 -0400 From: "Wilson, Brian J" To: "teas@ietf.org" Thread-Topic: Status of draft-ietf-teas-fast-lsps-requirements-00 Thread-Index: AdBbZhXFanKIDWnQQF2LkaYdl1AQRQ== Date: Tue, 10 Mar 2015 19:11:59 +0000 Message-ID: <4CC5843A6E31AE43B84680C27EDF38AA0D3EE5EB@rrc-ats-exmb2.ats.atsinnovate.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4CC5843A6E31AE43B84680C27EDF38AA0D3EE5EBrrcatsexmb2atsa_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 10 Mar 2015 12:37:06 -0700 Subject: [Teas] Status of draft-ietf-teas-fast-lsps-requirements-00 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:12:08 -0000 --_000_4CC5843A6E31AE43B84680C27EDF38AA0D3EE5EBrrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To the TEAS working group, This note is a status update of draft-ietf-teas-fast-lsps-requirements-00. = This draft has been adopted as a TEAS Working Group document following the = last IETF general meeting in Nov. 2014. All comments received during and fo= llowing the IETF meeting have been addressed in this version. We do not hav= e updates for this draft at this time. We would appreciate additional WG re= view and comments. Thanks, Brian Wilson for the authors --_000_4CC5843A6E31AE43B84680C27EDF38AA0D3EE5EBrrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To the TEAS w= orking group,

 

This note is a status update of draft-ietf-teas-fast-= lsps-requirements-00. This draft has been adopted as a TEAS Working Group d= ocument following the last IETF general meeting in Nov. 2014. All comments = received during and following the IETF meeting have been addressed in this = version. We do not have updates for this draft at this time. We would appre= ciate additional WG review and comments.

 

Thanks,

 

Brian Wil= son for the authors

 

= --_000_4CC5843A6E31AE43B84680C27EDF38AA0D3EE5EBrrcatsexmb2atsa_-- From nobody Wed Mar 11 09:26:41 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F045D1ACDE9; Wed, 11 Mar 2015 09:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6KmLCW_RblQ; Wed, 11 Mar 2015 09:26:38 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 094E91ACDF7; Wed, 11 Mar 2015 09:26:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 579512CD0E; Wed, 11 Mar 2015 18:26:21 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9un1h3aFu0vv; Wed, 11 Mar 2015 18:26:20 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id EB4722CCCF; Wed, 11 Mar 2015 18:26:20 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_3A44B30D-8481-4887-98A2-9446A748D3DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <54F86CC7.8080905@folly.org.uk> Date: Wed, 11 Mar 2015 18:26:20 +0200 Message-Id: <84D681B4-952D-440D-8813-C87FDDB5B7EA@piuha.net> References: <201502161358.t1GDwFvO095836@givry.fdupont.fr> <54F5F635.2050304@folly.org.uk> <54F74F12.3020205@folly.org.uk> <54F85971.6040600@folly.org.uk> <54F86CC7.8080905@folly.org.uk> To: Elwyn Davies X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-teas-lsp-attribute-ro.all@tools.ietf.org, gen-art@ietf.org, teas@ietf.org, "draft-ietf-teas-rsvp-te-li-lb.all@tools.ietf.org" , Lou Berger , Cyril Margaria Subject: Re: [Teas] [Gen-art] review of draft-ietf-teas-lsp-attribute-ro-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:26:40 -0000 --Apple-Mail=_3A44B30D-8481-4887-98A2-9446A748D3DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Francis & Elwyn: thanks for your reviews. And thank you Cyril for the = updates. I have balloted no-objection for this document on the upcoming = IESG telechat. Jari --Apple-Mail=_3A44B30D-8481-4887-98A2-9446A748D3DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVAGysAAoJEM80gCTQU46qLX8QAIKXpJyByJgZWPCZeNOBBm2F v+pQjb2LT1pSHuyNRjAlgLcALD/cebE4EcCSf6xzH6itZoYIOW3uA3YgnFnBSuev Gqkg6jS8OYaj0cff/KRKuKMkfU1K9kmmHigjM0NZW0nQKBWREU+7C5AKmfDA4a92 r5Hai5UM9skSCwtXPiBwrKVvwu6arRf4hA8L6nT6v9fvYo9ru4YYAON2YUw7dOKA x7MLUH9qyH6ltjhMKn35qHj1oZXtwk2ZK6LvQWcf68HI8Grdlsz582gf5a7WyNeN Jz5XQjXaaUhhm+FKKFIK/IbJL5Rp6VLYkSCVgh9caPrsAVT07Eeyj2CcTqIUz3fW IMVRP37Kxe0kFaS70K/8ep9ghPd+YIxPE3QlAgPieJmb+bJX0KsC2WHpLrxLBzPE t2WRaNZYKvfWj3yoxCxqrxWUeXuUpQ8JDxYK9lRruvMCYdAyjYxMdHD8RYZX4+nv XTD/K/c3HCAPrFQZoZSePSEdufvvfejl0QeQw4eIbaAFpWMgk/G3uxFToUYBzM+4 8mjwnHN6KNp+9ejaqBRT0s2q2GatZSQLxl9PC1mOE0AKEMsvC31mgcskpJHhJWUW TZTLFiQWU+isCLPg2ZqnqFdC6EUanFWvIvY2dJHQU4VFqeXFroVxNOGTURE4FiRI BRwGMC146QgZ29YvDUej =y5uj -----END PGP SIGNATURE----- --Apple-Mail=_3A44B30D-8481-4887-98A2-9446A748D3DE-- From nobody Thu Mar 12 13:38:02 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C921A0439 for ; Thu, 12 Mar 2015 13:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PObreX4SU812 for ; Thu, 12 Mar 2015 13:38:00 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CE81A1EEA for ; Thu, 12 Mar 2015 13:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=292; q=dns/txt; s=iport; t=1426192680; x=1427402280; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=8wWOuWgyyzy1uOWXsHybd9RjTF4zpihvgLG/mfQbTXY=; b=lkgxjC6otfN1NO2fbs8QtoAvJffQo0mwHwoTR0WGQUVdPjIK1dpZ9UXD gLmzaIhF/wLt9kGZtkyjvUueHxC0NzrMPi+hO8YNF+Pgk2rbb6MgOj8lv Ck3E2sugvS1HM2GtNOizwVcT6vGAUY06J9MYjmKRu/DbvJiOavOqNlncB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DxBAAI+QFV/5ldJa1bgwaBMMFmhzcCgTA4FAEBAQEBAQF8hBEBBDo/EgEqFEImAQQODYgnyxgBAQEBAQEBAQEBAQEBAQEBAQEaj08xgx6BFAWPdopfi2iGUyODboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,390,1422921600"; d="scan'208";a="131412800" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 12 Mar 2015 20:37:56 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t2CKbu8R002271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Mar 2015 20:37:56 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.151]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 12 Mar 2015 15:37:56 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Update on draft-ietf-teas-rsvp-te-srlg-collect Thread-Index: AdBdBC4NwtPQUn8LTrKZUOeRVR7Ygg== Date: Thu, 12 Mar 2015 20:37:56 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BBAEDC@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: [Teas] Update on draft-ietf-teas-rsvp-te-srlg-collect X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 20:38:01 -0000 All, We aren't planning to present this in Dallas, so a brief update. Current status: WG LC complete Open issues: none Next steps: finish current cleanup/idnits, progress to AD review and move t= owards publication. We hope to get this done very soon. Cheers Matt/authors From nobody Fri Mar 13 03:47:41 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3A41A00C7 for ; Fri, 13 Mar 2015 03:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DepOvVo5C1g for ; Fri, 13 Mar 2015 03:47:38 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 20EA81A00B2 for ; Fri, 13 Mar 2015 03:47:38 -0700 (PDT) Received: (qmail 10462 invoked by uid 0); 13 Mar 2015 10:47:37 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 13 Mar 2015 10:47:37 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 34nY1q00N2SSUrH014nbi8; Fri, 13 Mar 2015 10:47:36 -0600 X-Authority-Analysis: v=2.1 cv=TeEF63gh c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=99K8i5EPIjMA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=xt59-6yu6yAA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=9-yR2fW_QLOCErX0VNUA:9 a=CjuIK1q_8ugA:10 a=jM_x9b4JT8QA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:To:From; bh=fRUf6LooXgK0FVDGJa+YjPkUdpISyLMY9fznnKLy0l0=; b=IEXF6gaq4t37MPvoevuAbPdR+c0NNTn8AUfTlU6/WyF9q+3eB2jtqIJKZouXiqsFT4yfm9TCNuPqfmjBtthaGXsOyGuu44tszasiOf4V1WFPWFeAiH2ug8tlCo4FhHO9; Received: from [172.56.29.213] (port=61330 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YWN7t-0005Is-ET; Fri, 13 Mar 2015 04:47:33 -0600 From: Lou Berger To: , Date: Fri, 13 Mar 2015 06:47:32 -0400 Message-ID: <14c12befde8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <20150309224815.8246.60629.idtracker@ietfa.amsl.com> <14c12b948f8.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.1.13 (build: 21020013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.56.29.213 authed with lberger@labn.net} Archived-At: Subject: [Teas] Fwd: [Rtg-yang-coord] Fwd: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 10:47:39 -0000 Fyi - hope to see this discussed on the coordination list... --- Forwarded message --- From: Lou Berger Date: March 13, 2015 6:45:10 AM Subject: [Rtg-yang-coord] Fwd: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt To: CC: rtg-yang-coord@ietf.org Authors, Nice bit of work here. It has a pretty comprehensive scope and touches a few wgs (mpls, teas, perhaps rtgwg...). Assuming your plan is to stanardize this work, what are your thoughts / plans on how you are going to break down the work into different pieces and WGs? Thanks, Lou --- Forwarded message --- From: internet-drafts@ietf.org Date: March 9, 2015 6:49:56 PM Subject: I-D Action: draft-openconfig-mpls-consolidated-model-00.txt To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS / TE Model for Service Provider Networks Authors : Joshua George Luyuan Fang Eric Osborne Rob Shakir Filename : draft-openconfig-mpls-consolidated-model-00.txt Pages : 47 Date : 2015-03-09 Abstract: This document defines a framework for a YANG data model for configuring and managing label switched paths, including the signaling protocols, traffic engineering, and operational aspects based on carrier and content provider operational requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-openconfig-mpls-consolidated-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Sat Mar 14 05:02:58 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51D1A8978 for ; Fri, 13 Mar 2015 15:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeW-YmF-Wy2J for ; Fri, 13 Mar 2015 15:06:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6531A87C2 for ; Fri, 13 Mar 2015 15:06:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQF46003; Fri, 13 Mar 2015 22:06:04 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Mar 2015 22:06:04 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.223]) with mapi id 14.03.0158.001; Fri, 13 Mar 2015 15:05:54 -0700 From: Huaimo Chen To: "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt Thread-Index: AQHQQDAnGEX9/Sm5Ek2z9g/Hi6EEvp0bLzwA Date: Fri, 13 Mar 2015 22:05:54 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E369B0E@SJCEML701-CHM.china.huawei.com> References: <20150204040732.31039.38899.idtracker@ietfa.amsl.com> In-Reply-To: <20150204040732.31039.38899.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Sat, 14 Mar 2015 05:02:57 -0700 Cc: "lberger@labn.net" , "Toy, Mehmet" , "ningso01@gmail.com" , Autumn Liu , "vbeeram@juniper.net" , Lu Huang , Tarek Saad , Fengman Xu , "liulei.kddi@gmail.com" , Lizhenbin Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 22:06:11 -0000 Hi Everyone, We addressed the comments from Lou in this version.=20 We believe that this draft is ready for WGLC. Any new comments and sugg= estions are welcome. Best Regards, Huaimo -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, February 03, 2015 11:08 PM To: i-d-announce@ietf.org Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Traffic Engineering Architecture and Sign= aling Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Egress Local Protec= tion Authors : Huaimo Chen Ning So Autumn Liu Tarek Saad Fengman Xu Filename : draft-ietf-teas-rsvp-egress-protection-01.txt Pages : 17 Date : 2015-02-03 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-egress-protection-0= 1 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Sat Mar 14 05:03:09 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CFC1A8738 for ; Fri, 13 Mar 2015 15:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMfE6E86iY4U for ; Fri, 13 Mar 2015 15:34:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143E81A0072 for ; Fri, 13 Mar 2015 15:34:56 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQF47113; Fri, 13 Mar 2015 22:34:54 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Mar 2015 22:34:54 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0158.001; Fri, 13 Mar 2015 15:34:43 -0700 From: Huaimo Chen To: "teas@ietf.org" , "lberger@labn.net" , "vbeeram@juniper.net" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt Thread-Index: AQHQWqV7w0+p11o6AEeHZz+8LAq/vZ0a/kkA Date: Fri, 13 Mar 2015 22:34:42 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E369B5D@SJCEML701-CHM.china.huawei.com> References: <20150309201246.7568.85606.idtracker@ietfa.amsl.com> In-Reply-To: <20150309201246.7568.85606.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.29] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E369B5DSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Sat, 14 Mar 2015 05:03:08 -0700 Cc: Raveendra Torvi , Markus Jork , "Boris.Zhang@telus.com" , Richard Li , "ningso01@gmail.com" , Autumn Liu , Quintin zhao , Tarek Saad , Alia Atlas , Yimin Shen , Fengman Xu , "liulei.kddi@gmail.com" , Lizhenbin Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 22:34:59 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E369B5DSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everyone, We addressed the comments from Lou in this version. There are two methods for a backup ingress to get the information to pr= ovide protection for the primary ingress of an LSP in the draft. One method= needs to be selected. After this is resolved, the draft is ready for WGLC. Best Regards, Huaimo -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Monday, March 09, 2015 4:13 PM To: i-d-announce@ietf.org Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Traffic Engineering Architecture and Sign= aling Working Group of the IETF. Title : Extensions to RSVP-TE for LSP Ingress Local Prote= ction Authors : Huaimo Chen Raveendra Torvi Filename : draft-ietf-teas-rsvp-ingress-protection-02.txt Pages : 23 Date : 2015-03-09 Abstract: This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Label Switched Path (LSP), which is a Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-ingress-protection-= 02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_5316A0AB3C851246A7CA5758973207D44E369B5DSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Everyone,
 
    We addressed the comments from Lou in this version.=
 
    There are two methods for a backup ingress to get t= he information to provide protection for the primary ingress of an LSP in t= he draft. One method needs to be selected. After this is resolved, the draf= t is ready for WGLC.
 
Best Regards,
Huaimo
 
-----Original Message-----
From: Teas [mailto:teas-bounces@ie= tf.org] On Behalf Of internet-drafts@ietf.org
Sent: Monday, March 09, 2015 4:13 PM
To: i-d-announce@ietf.org
Cc: teas@ietf.org
Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt<= /div>
 
 
A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
This draft is a work item of the Traffic Engineering Architecture and= Signaling Working Group of the IETF.
 
        Title   &nbs= p;       : Extensions to RSVP-TE for LSP Ingr= ess Local Protection
        Authors   &n= bsp;     : Huaimo Chen
           &nbs= p;            &= nbsp; Raveendra Torvi
        Filename   &= nbsp;    : draft-ietf-teas-rsvp-ingress-protection-02.txt
        Pages   &nbs= p;       : 23
        Date    = ;        : 2015-03-09
 
Abstract:
   This document describes extensions to Resource Reservatio= n Protocol -
   Traffic Engineering (RSVP-TE) for locally protecting the = ingress node
   of a Traffic Engineered (TE) Label Switched Path (LSP), w= hich is a
   Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) = LSP.
 
 
The IETF datatracker status page for this draft is:
 
There's also a htmlized version available at:
 
A diff from the previous version is available at:
 
 
Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.org.=
 
Internet-Drafts are also available by anonymous FTP at:
 
_______________________________________________
Teas mailing list
 
 --_000_5316A0AB3C851246A7CA5758973207D44E369B5DSJCEML701CHMchi_-- From nobody Sat Mar 14 06:28:31 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440B71A038D for ; Sat, 14 Mar 2015 06:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up0NFF5mmOL5 for ; Sat, 14 Mar 2015 06:28:29 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052931A0382 for ; Sat, 14 Mar 2015 06:28:29 -0700 (PDT) Received: by igbue6 with SMTP id ue6so6200532igb.1 for ; Sat, 14 Mar 2015 06:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=Ul3HySV5UuAdawqq1Zslse8ggnxf9jI/BBfIs1KQ/w0=; b=u+hyxHETlNatfSnJGe2jctbweLMt7rgyxExILij6CllJB1U8zeGw09WxZ0br0EaU6Q h93780Z1dfLFKiG7Ttsfia/N87dvw+SIRKnK10ahA5vLOxtn+GEKqJaVgpITPOln5ut1 3yVMIDA8IuzbbThk9XFKLTL7IiICrVq9lpdi5UuTa26s5q59WFoKPCLcS0zHtdS3moI4 vduqIPJK2t7Jb68GnrvkRx5xyrdqF/diMJEDBUMbI5BADmjfsQJOdcBXg/OTNySDThZN ObxaU9rnit395jbNqLd4AoELcZ/rICOZANQsc9jTXIHRtD1+YgMv4BEZZymHBhWCoL8q IhCQ== MIME-Version: 1.0 X-Received: by 10.107.155.13 with SMTP id d13mr91777434ioe.29.1426339708414; Sat, 14 Mar 2015 06:28:28 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.167.2 with HTTP; Sat, 14 Mar 2015 06:28:28 -0700 (PDT) Date: Sat, 14 Mar 2015 18:58:28 +0530 X-Google-Sender-Auth: O3lKUSoa6-vd1dQMK4xSjguABUE Message-ID: From: Dhruv Dhody To: "TEAS WG (teas@ietf.org)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "pce-chairs@tools.ietf.org" Subject: [Teas] Domain Subobjects draft X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 13:28:30 -0000 Hi, We will not be presenting Domain Subobjects draft [1] in this IETF TEAS WG meeting. There are no pending actions, or open issues. The draft was pending the progress of its companion Domain Sequence document [2] in PCE WG; which intern was pending the progress of the IRO update draft [3], which has been adopted by PCE WG. It was decided to progress the documents together; In the opinion of the authors, the document set is ready to progress to the next step. Regards, Dhruv [1] https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-00 [2] http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-07 [2] https://tools.ietf.org/html/draft-ietf-pce-iro-update-01 From nobody Mon Mar 16 10:35:10 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DAF1A88F2; Mon, 16 Mar 2015 10:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzLuSl_XlQjb; Mon, 16 Mar 2015 10:35:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2751A891C; Mon, 16 Mar 2015 10:35:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150316173504.5027.16276.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 10:35:04 -0700 Archived-At: Cc: teas chair , teas mailing list , RFC Editor Subject: [Teas] Protocol Action: 'RSVP-TE Extensions for Associated Bidirectional LSPs' to Proposed Standard (draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:35:08 -0000 The IESG has approved the following document: - 'RSVP-TE Extensions for Associated Bidirectional LSPs' (draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07.txt) as Proposed Standard This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp/ Technical Summary This document describes Resource reSerVation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single sided provisioning case. Working Group Summary The document moved from the CCAMP to TEAS WGs as part of the routing WG changes. This document has been fairly noncontroversial. Document Quality The base GMPLS protocol has been implemented. The extensions defined in this document are compatible with earlier implementations. While there have been no public statements on implementation, the authors are from multiple vendors and an operator, and implementation Is expected. The Acknowledgement section acknowledges a prototype implementation. Personnel Deborah Brungard is the Document Shepherd Adrian Farrel is the Responsible Area Director From nobody Tue Mar 17 07:22:17 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4BB1A1A6F for ; Tue, 17 Mar 2015 07:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWik-ODQFRTt for ; Tue, 17 Mar 2015 07:22:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA57B1A1A4D for ; Tue, 17 Mar 2015 07:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=476; q=dns/txt; s=iport; t=1426602124; x=1427811724; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=cicASoM+jiCb/K6DTo36GmcBxmSN5LLOSPWs3MEG1gc=; b=NznmOzoXnbzJ921KcUn39UHEPJEdHlIRrLVLHMjJtJhbi+TGI/sEnr48 rAt8s/np+ioD0o7Lxir9UPRhDj6jwyGI1W/0W+i8bM5MuvbmQ0uUGKBWk BdY3ENK5vLlI6GmCmGYaejZ2dTrKn6u9gAZqx0mqT42F7PFPAdypAV/m+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsBQCuNwhV/40NJK1bgwaBMMttAoE0TAEBAQEBAX2EFjpRAT5CJQIECog4nzOqawEBAQEBBQEBAQEBHZAPhC0FkD6JaYEbjBGGbiODboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,416,1422921600"; d="scan'208";a="404680394" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-2.cisco.com with ESMTP; 17 Mar 2015 14:22:04 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2HEM1kf006223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Mar 2015 14:22:02 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 09:22:01 -0500 From: "Rakesh Gandhi (rgandhi)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Status update of draft-ietf-teas-p2mp-loose-path-reopt-02 Thread-Index: AQHQYL281JCKtPDkgk2C4+M+RK0c7Q== Date: Tue, 17 Mar 2015 14:22:01 +0000 Message-ID: In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29BBAEDC@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.249.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Teas] Status update of draft-ietf-teas-p2mp-loose-path-reopt-02 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:22:08 -0000 Hi working group, This note is a status update of draft-ietf-teas-p2mp-loose-path-reopt-02. Current status: This draft was adopted as an MPLS working group document and transferred to the new TEAS working group in December'14. Authors have made editorial/cleanup changes to this document since the last IETF meeting in November'14 and believe it is ready for the WG LC. Open issues: Not aware of any. Next steps: Requesting WG LC. Thanks, Authors From nobody Tue Mar 17 15:21:04 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C0F1A8937 for ; Tue, 17 Mar 2015 15:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1UknqMatemh for ; Tue, 17 Mar 2015 15:21:02 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7801A8930 for ; Tue, 17 Mar 2015 15:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=415; q=dns/txt; s=iport; t=1426630862; x=1427840462; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9DwQJRhCoXelmgcr++pcFi+C8kzphH2xkbzDpokLrww=; b=i82Zih+JzMrVRFp85+U3W9yV/CsI8CG+VVp14D0jeyGdLqNo16lqc2dO gRqcM3QKsGU4JsbvwWeh6RNuwCFDShMu/VcW9ImXovD0GkYwvVqnmYPDs DUEyHUKytT6QJuj7kyyyCAkAvxaYrWKmQE55BW40bg760i4OF15HQ9G0G Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B/BQAXqAhV/4gNJK1bgwaBMM02TAEBAQEBAX2EFjpRAT5CJwSIQqAsqnoBAQgCIJQ8BZBAiWqBG4wUhm4jg26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,418,1422921600"; d="scan'208";a="404535416" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 17 Mar 2015 22:21:01 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2HML1CO007812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Mar 2015 22:21:01 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 17:21:00 -0500 From: "Rakesh Gandhi (rgandhi)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Status update of draft-ietf-teas-gmpls-lsp-fastreroute-02 Thread-Index: AQHQYQClMzPCM7qthk6yXnRjpjDgkw== Date: Tue, 17 Mar 2015 22:21:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.249.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Teas] Status update of draft-ietf-teas-gmpls-lsp-fastreroute-02 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 22:21:03 -0000 Hi working group, This note is a status update of draft-ietf-teas-gmpls-lsp-fastreroute-02. Current status: This draft was adopted as a TEAS working group in December'14. Authors have updated the draft to address the comments received from the WG during the adoption poll. Open issues: Not aware of any. Next steps: We would appreciate additional WG review and comments. Thanks, Authors From nobody Wed Mar 18 05:44:35 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0EE1A00E9 for ; Wed, 18 Mar 2015 05:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwNARiMPR2B4 for ; Wed, 18 Mar 2015 05:39:17 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id D932F1A00CD for ; Wed, 18 Mar 2015 05:39:16 -0700 (PDT) Received: (qmail 28461 invoked by uid 0); 18 Mar 2015 12:39:12 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 18 Mar 2015 12:39:12 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 56f71q00b2SSUrH016fAEZ; Wed, 18 Mar 2015 12:39:10 -0600 X-Authority-Analysis: v=2.1 cv=TeEF63gh c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=UKBaUiMnSBSwCAIuLrYA:9 a=ojWUC1fvjWrfnSID:21 a=k6xJB8iYKsWz95iC:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hCRvN7Mf3qs0xTreB+1JvezD6UIqyD2JjN2u+gbAn5Q=; b=vVO4NE2JojBsV+uepZ6X7pTn/ZcpMhVQalbYtrjL674J/QfgzZz8Xg+CCTD63Y41Hozesoufy41RAa6ijmW8RJx/EqAGTIAxm79sIAb2B32SssCkkUgxDicDdSpnoZk9; Received: from box313.bluehost.com ([69.89.31.113]:46009 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YYDFd-0006zQ-2J; Wed, 18 Mar 2015 06:39:09 -0600 Message-ID: <550971E2.1000806@labn.net> Date: Wed, 18 Mar 2015 08:38:58 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Huaimo Chen , "teas@ietf.org" , "vbeeram@juniper.net" References: <20150309201246.7568.85606.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D44E369B5D@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E369B5D@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: X-Mailman-Approved-At: Wed, 18 Mar 2015 05:44:33 -0700 Cc: Raveendra Torvi , Markus Jork , "Boris.Zhang@telus.com" , Richard Li , "ningso01@gmail.com" , Autumn Liu , Lizhenbin , Tarek Saad , Alia Atlas , Yimin Shen , Fengman Xu , "liulei.kddi@gmail.com" , Quintin zhao Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 12:39:18 -0000 Huaimo, Co-authors, What is your plan for resolving the major open issue on this document? (BTW I'm completely baffled by the WGLC reference!) Also, a general comment: When addressing comments sent to the list, please respond directly to the message containing the comment and discuss the details of how you (plan to) address the comment. Alternatively, you can summarize the details of each issue resolution in a single message after publication of a new version. In other words "We addressed the comments from..." is a bit too terse. Thanks, Lou On 3/13/2015 6:34 PM, Huaimo Chen wrote: > Hi Everyone, > > We addressed the comments from Lou in this version. > > There are two methods for a backup ingress to get the information > to provide protection for the primary ingress of an LSP in the draft. > One method needs to be selected. After this is resolved, the draft is > ready for WGLC. > > Best Regards, > Huaimo > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, March 09, 2015 4:13 PM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Traffic Engineering Architecture and > Signaling Working Group of the IETF. > > Title : Extensions to RSVP-TE for LSP Ingress Local > Protection > Authors : Huaimo Chen > Raveendra Torvi > Filename : draft-ietf-teas-rsvp-ingress-protection-02.txt > Pages : 23 > Date : 2015-03-09 > > Abstract: > This document describes extensions to Resource Reservation Protocol - > Traffic Engineering (RSVP-TE) for locally protecting the ingress node > of a Traffic Engineered (TE) Label Switched Path (LSP), which is a > Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-ingress-protection-02 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Mar 18 05:44:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE311A00DF for ; Wed, 18 Mar 2015 05:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLXXCoU7h4-U for ; Wed, 18 Mar 2015 05:41:21 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 918431A00EA for ; Wed, 18 Mar 2015 05:41:21 -0700 (PDT) Received: (qmail 9883 invoked by uid 0); 18 Mar 2015 12:41:21 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy4.mail.unifiedlayer.com with SMTP; 18 Mar 2015 12:41:21 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 50hF1q0012SSUrH010hJst; Wed, 18 Mar 2015 06:41:19 -0600 X-Authority-Analysis: v=2.1 cv=dKs1xopb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=lH5V8Q3S9c1h7jv5wWYA:9 a=MZHryUiFUYS0zRx-:21 a=yegXq6VB2t9xvpL4:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=m087BSO/tWtXmOucKLE0slz2LfxC8/URa8dykw0SI+E=; b=gTxqPrdUcmKNS7dSeFlF3tyqAA0RNGMpXe3zjfjyCBPTXXfDKCYC6MnBl8elIUKy6Wzk4bJmg39CmqX3/nHzsijoYZrxb6EkUnC2DOVf+4TTAeNv0ZsTDyMyvv8p5rzf; Received: from box313.bluehost.com ([69.89.31.113]:46081 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YYDHg-0007Of-Sy; Wed, 18 Mar 2015 06:41:16 -0600 Message-ID: <55097264.8040800@labn.net> Date: Wed, 18 Mar 2015 08:41:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Huaimo Chen , "teas@ietf.org" References: <20150204040732.31039.38899.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D44E369B0E@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E369B0E@SJCEML701-CHM.china.huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: X-Mailman-Approved-At: Wed, 18 Mar 2015 05:44:33 -0700 Cc: "Toy, Mehmet" , "ningso01@gmail.com" , Autumn Liu , "vbeeram@juniper.net" , Lu Huang , Tarek Saad , Fengman Xu , "liulei.kddi@gmail.com" , Lizhenbin Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 12:41:22 -0000 Huaimo, Co-authors, WG, A general comment: When addressing comments sent to the list, please respond directly to the message containing the comments and discuss the details of how you (plan to) address the comment. Alternatively, you can summarize the details of each issue resolution in a single message after publication of a new version. In other words "We addressed the comments from..." is a bit too terse. Thanks, Lou On 3/13/2015 6:05 PM, Huaimo Chen wrote: > Hi Everyone, > > We addressed the comments from Lou in this version. > We believe that this draft is ready for WGLC. Any new comments and suggestions are welcome. > > Best Regards, > Huaimo > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, February 03, 2015 11:08 PM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. > > Title : Extensions to RSVP-TE for LSP Egress Local Protection > Authors : Huaimo Chen > Ning So > Autumn Liu > Tarek Saad > Fengman Xu > Filename : draft-ietf-teas-rsvp-egress-protection-01.txt > Pages : 17 > Date : 2015-02-03 > > Abstract: > This document describes extensions to Resource Reservation Protocol - > Traffic Engineering (RSVP-TE) for locally protecting egress nodes of > a Traffic Engineered (TE) Label Switched Path (LSP), which is a > Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protection/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-egress-protection-01 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Wed Mar 18 18:43:19 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2F11AC3D1 for ; Wed, 18 Mar 2015 18:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DctpHtqulIW8 for ; Wed, 18 Mar 2015 18:43:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06D91AC3CD for ; Wed, 18 Mar 2015 18:43:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTU98402; Thu, 19 Mar 2015 01:43:11 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Mar 2015 01:43:10 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML702-CHM.china.huawei.com ([169.254.4.237]) with mapi id 14.03.0158.001; Wed, 18 Mar 2015 18:43:01 -0700 From: Huaimo Chen To: Lou Berger , "teas@ietf.org" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt Thread-Index: AQHQQDAnGEX9/Sm5Ek2z9g/Hi6EEvp0bLzwAgAe3WQCAAF+rkA== Date: Thu, 19 Mar 2015 01:43:00 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E376AC5@SJCEML701-CHM.china.huawei.com> References: <20150204040732.31039.38899.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D44E369B0E@SJCEML701-CHM.china.huawei.com> <55097264.8040800@labn.net> In-Reply-To: <55097264.8040800@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Toy, Mehmet" , "ningso01@gmail.com" , Autumn Liu , "vbeeram@juniper.net" , Lu Huang , Tarek Saad , Fengman Xu , "liulei.kddi@gmail.com" , Lizhenbin Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 01:43:18 -0000 Hi Lou, Thank you very much. Your comments were addressed in the updated draft as follows: > - You have a lot of names on the front page. The RFC editor's guidance i= s a max of 5 names on the front page. Getting to this number will smooth t= he publication process. [Huaimo] Keep 5 names on the front page in the updated draft. > > - There are a number of nits that would be good to clean up. [Huaimo] Cleaned up. > > - You have conformance (RFC2119) language in informative text=20 [Huaimo] Removed conformance language in informative text. > > - You mention GMPLS, which is good, but don't mention how the document re= lates to RFC4872 and 4873. I'm not saying that the document can't be limit= ed to FRR protection, but do want to at least discuss if a unified approach= can be found for FRR and 4873 style segment protection. The conclusion of= this discussion will need to reflected in someway in the document, either = as a change in the mechanisms or an explicit statement of scope. [Huaimo] Removed GMPLS from abstract.=20 > > - You can define values for objects/TLVs defined in this document. [Huaimo] Defined values for new objects/TLVs. > > - You combined v4/v6 object definition is subject to misinterpretation.=20 > It needs to be clarified. I suggest using past RFCs as a reference of ho= w this can be done, e.g., see RFC4875. [Huaimo] Defined IPv4 and IPv6 objects separately. > > - You should reference where the FAST_REROUTE object is defined in=20 > section 4.2=20 [Huaimo] Removed this section. Moved flags into EGRESS_BACKUP object since = the flags are specific to egress protection. > > - Section 5 seems to be a mix informative and normative text. It's not c= lear if all required behaviors have normative language. I suspect there are= a number of cases missing - particularly, but not exclusively, in the lang= uage around processing that is the same as / different than RFC4090, which = is generally very loosely defined. >=20 [Huaimo] Separated informative and normative text, make sure all required b= ehaviors in normative language. > > - The term "The S2L Sub LSP Protection" is first in the procedures sectio= n. It's definition / introduction is needed somewhere, either by reference= or earlier in the document. Consider if you even need to introduce this n= ew term. >=20 [Huaimo] Introduced "S2L Sub LSP Protection".=20 > > - Section 6.3 seems like it's going to be an informative section, but the= n conformance language shows up. I suspect the conformance language belong= s in Section 5. >=20 [Huaimo] Removed the conformance language in this section. > > - Section 7 is pretty light, I suspect you can find more to say on this t= opic. >=20 [Huaimo] Added more on this topic. > > - The iana section doesn't follow rfc5226. See some recent RFCs for exam= ples. (I just reviewed draft-ietf-teas-rsvp-te-li-lb and it provides an exa= mple for exiting registries, but not establishing a new one.=20 >=20 [Huaimo] Re-wrote IANA section. > > - Your references need to be revisited/cleaned up. There are some clearl= y stale references and the normative/informative split doesn't make a whole= lot of sense. >=20 [Huaimo] Cleaned up the references. Best Regards, Huaimo -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, March 18, 2015 8:41 AM To: Huaimo Chen; teas@ietf.org Cc: Toy, Mehmet; ningso01@gmail.com; Autumn Liu; vbeeram@juniper.net; Lu Hu= ang; Tarek Saad; Fengman Xu; liulei.kddi@gmail.com; Lizhenbin Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-egress-protection-01.t= xt Huaimo, Co-authors, WG, A general comment: When addressing comments sent to the list, please respon= d directly to the message containing the comments and discuss the details o= f how you (plan to) address the comment. Alternatively, you can summarize = the details of each issue resolution in a single message after publication = of a new version. In other words "We addressed the comments from..." is a = bit too terse. Thanks, Lou On 3/13/2015 6:05 PM, Huaimo Chen wrote: > Hi Everyone, > > We addressed the comments from Lou in this version.=20 > We believe that this draft is ready for WGLC. Any new comments and su= ggestions are welcome. > > Best Regards, > Huaimo > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Tuesday, February 03, 2015 11:08 PM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action:=20 > draft-ietf-teas-rsvp-egress-protection-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Traffic Engineering Architecture and Si= gnaling Working Group of the IETF. > > Title : Extensions to RSVP-TE for LSP Egress Local Prot= ection > Authors : Huaimo Chen > Ning So > Autumn Liu > Tarek Saad > Fengman Xu > Filename : draft-ietf-teas-rsvp-egress-protection-01.txt > Pages : 17 > Date : 2015-02-03 > > Abstract: > This document describes extensions to Resource Reservation Protocol - > Traffic Engineering (RSVP-TE) for locally protecting egress nodes of > a Traffic Engineered (TE) Label Switched Path (LSP), which is a > Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-egress-protectio > n/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-rsvp-egress-protection-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-egress-protectio > n-01 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Thu Mar 19 10:27:11 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D971A802E for ; Thu, 19 Mar 2015 10:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v06b4j10MGCs for ; Thu, 19 Mar 2015 10:27:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4041A870C for ; Thu, 19 Mar 2015 10:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=711; q=dns/txt; s=iport; t=1426786016; x=1427995616; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=m7eww0j4kJgdcj/SWMo14MsAnXhqbKbnTYGYRjQOrTk=; b=P3/wp3jklFQB2TTd3TUHvYocY2EcXFQ+pxrAqyMDbLjJo/Qfl032fCUy ttxwNmCCVh13eU56kD3dziqOkJ1Bi30K/ircCl/8WFdom7nn6BxQqmn1i BnflFkiJuhkt4dImdmQI/gQC7wrfPM66sO+eLEUQryKObyeCb90JrZMki 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQA/BgtV/4sNJK1cgwaBMMwXAoFMTAEBAQEBAX2EEQEEOj8SASoUQiYBBA4NiCfOKwEBAQEBAQEBAQEBAQEBAQEBARqPVzGDHoEWBZBJiwiMG4ZyIoNugjN/AQEB X-IronPort-AV: E=Sophos;i="5.11,430,1422921600"; d="scan'208";a="404980823" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2015 17:26:55 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2JHQtwG013966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 17:26:55 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.251]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 12:26:55 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Update on draft-ietf-teas-te-metric-recording Thread-Index: AdBiaYTAhoaRDjtTSb2NPE3xsoaj9g== Date: Thu, 19 Mar 2015 17:26:54 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BE09F1@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "draft-ietf-teas-te-metric-recording@tools.ietf.org" Subject: [Teas] Update on draft-ietf-teas-te-metric-recording X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:27:10 -0000 All, We aren't planning to present this in Dallas, so a brief update. Current status: waiting on draft-ietf-teas-rsvp-te-srlg-collect. Since this= draft is similar to the SRLG-recording in terms of mechanisms, use-cases, = etc we're waiting until the SRLG draft is though the IETF process as any co= mments made for that draft are likely to apply to this one too. Once that's= done, this one will follow. Open issues: none Next steps: hopefully the SRLG draft will go to AD review and beyond in the= near future; when that's done this draft will resume progress towards WG L= C. In the meantime, further review and comments from the WG would be apprec= iated. Cheers Matt/authors From nobody Thu Mar 19 10:54:41 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295EA1A8778; Thu, 19 Mar 2015 10:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvgWgWd71Ps0; Thu, 19 Mar 2015 10:54:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D72F1A8769; Thu, 19 Mar 2015 10:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=342; q=dns/txt; s=iport; t=1426787678; x=1427997278; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=HpAgQkAJuCNRb9UIFq4UzGZJeWgbhAKxLFJwz1/1Rxs=; b=XfiJPXuK/JdmNHEvHcD6ARxmtNSNa97yX6Q5jNoa1wzdSKXdpSPc7/7Q izK6gkAYx3W53lgWhmXXb6H5SaAOArNA0V0wi+DLe3ZkuCL4WLxUthzpk uTzBoW0t962hNpikzIWjIxA4m4Vnv7O/Xu3/OZtAntMrSmesfPg6F9vpJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIBQDVDAtV/5hdJa1cgwaBMMwbAoFNTAEBAQEBAX2EEQEEOj8SASoUQiYBBA4NiCfOLAEBAQEBAQEBAgEBAQEBAQEBGo9XMYMegRYBBJBMiwiDMIhrgyuDRyKDboIzfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,431,1422921600"; d="scan'208";a="405383421" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2015 17:54:37 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2JHsbZY005366 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Mar 2015 17:54:37 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.251]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 19 Mar 2015 12:54:37 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Slides and updates for Dallas Thread-Index: AdBibVTHaOjQlQV4SianoZNlgai9/g== Date: Thu, 19 Mar 2015 17:54:36 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BE0AC3@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" Subject: [Teas] Slides and updates for Dallas X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:54:39 -0000 A friendly reminder... If you're presenting, please make sure that you've sent your slides to me a= nd the Chairs by Sunday. If you have a WG document and it's not being presented, we're expecting a b= rief status update. Thanks to those who have already sent them; others, ple= ase do so. Thanks Matt, Deborah, Lou and Pavan From nobody Thu Mar 19 12:35:30 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7959C1A8ADE for ; Thu, 19 Mar 2015 12:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxxOjsnZiDYJ for ; Thu, 19 Mar 2015 12:35:27 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5711A8AD4 for ; Thu, 19 Mar 2015 12:35:27 -0700 (PDT) Received: by qcbkw5 with SMTP id kw5so75850430qcb.2 for ; Thu, 19 Mar 2015 12:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yNtzDpqXOKeU/VZv9ifBEPV8rP3mPVQQCQNI40hmTnM=; b=G6/5qQNTm7koywBZ8ftJ63C3cWeIR7UdIeBaqBp/G/CUffoWiASs4kPOchV1a5qZxq jB/sT/ttykpivQAhpvVxrSsDzpPP6/yg/0WUOdpzLUi+ARVdHl3JHaaHAPHTTc/UHqTl 1wvgpI3EsJaaYZFM7eEyM/pwUx+V8SGv+DP7zJ2EHsbjS/3my/XwFOKBymERvuWqMCnM GH/ZCfPZid1OCwS9+No+c8zaR3rN5D5IqD1m60GplVl28lYgW6ABZhA7FFflTbe7UogE tLCnlTcKAJHMys6hh0wTNI8WjztyNis0YE6Scgd7E8q/bjKW0dcshWKCv7G1uvReScqH ovmg== MIME-Version: 1.0 X-Received: by 10.140.36.239 with SMTP id p102mr94965196qgp.44.1426793726297; Thu, 19 Mar 2015 12:35:26 -0700 (PDT) Received: by 10.140.85.227 with HTTP; Thu, 19 Mar 2015 12:35:26 -0700 (PDT) Date: Thu, 19 Mar 2015 15:35:26 -0400 Message-ID: From: Vishnu Pavan Beeram To: "teas@ietf.org" , draft-ietf-teas-network-assigned-upstream-label@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c11e06394bf20511a94ddc Archived-At: Subject: [Teas] Update on X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 19:35:28 -0000 --001a11c11e06394bf20511a94ddc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable WG, Hi! Latest Update: A new version was published recently. The following are the diffs - - Section 6.2 - Change MUST->SHOULD - =E2=80=9CIn such a scenario, if the ingress client receives a ch= anged label via the LABEL object in a RESV modify, it SHOULD retune the laser at the ingress to the new wavelength. Similarly if the egress client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH modify, it SHOULD retune the laser at the egress to the new wavelength.=E2=80=9D - Added Zafar Ali to the list of contributors Open Issues: None. Next Steps: Request further review from the WG (authors believe that the draft is ready to progress to the next stage) Regards, -Pavan (On behalf of the authors/contributors) --001a11c11e06394bf20511a94ddc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
WG, Hi!

Latest Update:
A new version was published recently. The f= ollowing are the diffs -
    • Section 6.2 - Change MUS= T->SHOULD
      • =E2=80=9CIn such a scenario, if the ingress client= receives a changed label via the LABEL object in a RESV modify, it SHOULD = retune the laser at the ingress to the new wavelength. Similarly if the egr= ess client receives a changed label via UPSTREAM_LABEL/LABEL_SET in a PATH = modify, it SHOULD retune the laser at the egress to the new wavelength.=E2= =80=9D
    • Added Zafar Ali to the list of contributors
Open Issues:
None.

Next Steps:
Request further review from the WG (authors believe that the draft is r= eady to progress to the next stage)

Regards,
-Pavan
(On behalf of the authors/contributors)
--001a11c11e06394bf20511a94ddc-- From nobody Thu Mar 19 18:05:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD651A8898 for ; Thu, 19 Mar 2015 18:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXtwr9XEIy7t for ; Thu, 19 Mar 2015 18:05:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125281A8893 for ; Thu, 19 Mar 2015 18:05:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQL27413; Fri, 20 Mar 2015 01:05:11 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Mar 2015 01:05:10 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Thu, 19 Mar 2015 18:04:59 -0700 From: Huaimo Chen To: Lou Berger , "teas@ietf.org" , "vbeeram@juniper.net" Thread-Topic: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt Thread-Index: AQHQWqV7w0+p11o6AEeHZz+8LAq/vZ0a/kkAgAeyxgCAAeUqQA== Date: Fri, 20 Mar 2015 01:04:58 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E376D31@SJCEML701-CHM.china.huawei.com> References: <20150309201246.7568.85606.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D44E369B5D@SJCEML701-CHM.china.huawei.com> <550971E2.1000806@labn.net> In-Reply-To: <550971E2.1000806@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.171] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Raveendra Torvi , Markus Jork , "Boris.Zhang@telus.com" , Richard Li , "ningso01@gmail.com" , Autumn Liu , Lizhenbin , Tarek Saad , Alia Atlas , Yimin Shen , Fengman Xu , "liulei.kddi@gmail.com" , Quintin zhao Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 01:05:18 -0000 Hi Lou, Thanks much for your comments. For the open issue in this draft, we are going to have some meetings re= cently to try to resolve it. For your comments for the egress protection draft, which are applicable= to this draft, they were addressed in the draft as follows: > - You mention GMPLS, which is good, but don't mention how the document re= lates to RFC4872 and 4873. I'm not saying that the document can't be limit= ed to FRR protection, but do want to at least discuss if a unified approach= can be found for FRR and 4873 style segment protection. The conclusion of= this discussion will need to reflected in someway in the document, either = as a change in the mechanisms or an explicit statement of scope. [Huaimo] Removed GMPLS from abstract.=20 > > - You can define values for objects/TLVs defined in this document. [Huaimo] Defined values for new objects/TLVs. > > - You combined v4/v6 object definition is subject to misinterpretation.=20 > It needs to be clarified. I suggest using past RFCs as a reference of ho= w this can be done, e.g., see RFC4875. [Huaimo] Defined IPv4 and IPv6 objects separately. > - The iana section doesn't follow rfc5226. See some recent RFCs for exam= ples. (I just reviewed draft-ietf-teas-rsvp-te-li-lb and it provides an exa= mple for exiting registries, but not establishing a new one.=20 >=20 [Huaimo] Wrote IANA section in details. > > - Your references need to be revisited/cleaned up. There are some clearl= y stale references and the normative/informative split doesn't make a whole= lot of sense. >=20 [Huaimo] Cleaned up the references. Best Regards, Huaimo -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, March 18, 2015 8:39 AM To: Huaimo Chen; teas@ietf.org; vbeeram@juniper.net Cc: Raveendra Torvi; Markus Jork; Boris.Zhang@telus.com; Richard Li; ningso= 01@gmail.com; Autumn Liu; Quintin zhao; Tarek Saad; Alia Atlas; Yimin Shen;= Fengman Xu; liulei.kddi@gmail.com; Lizhenbin Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.= txt Huaimo, Co-authors, What is your plan for resolving the major open issue on this document? = (BTW I'm completely baffled by the WGLC reference!) Also, a general comment: When addressing comments sent to the list, please = respond directly to the message containing the comment and discuss the det= ails of how you (plan to) address the comment.=20 Alternatively, you can summarize the details of each issue resolution in a = single message after publication of a new version. In other words "We addr= essed the comments from..." is a bit too terse. Thanks, Lou On 3/13/2015 6:34 PM, Huaimo Chen wrote: > Hi Everyone, > =20 > We addressed the comments from Lou in this version. > =20 > There are two methods for a backup ingress to get the information=20 > to provide protection for the primary ingress of an LSP in the draft. > One method needs to be selected. After this is resolved, the draft is=20 > ready for WGLC. > =20 > Best Regards, > Huaimo > =20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Monday, March 09, 2015 4:13 PM > To: i-d-announce@ietf.org > Cc: teas@ietf.org > Subject: [Teas] I-D Action:=20 > draft-ietf-teas-rsvp-ingress-protection-02.txt > =20 > =20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Traffic Engineering Architecture and=20 > Signaling Working Group of the IETF. > =20 > Title : Extensions to RSVP-TE for LSP Ingress Local > Protection > Authors : Huaimo Chen > Raveendra Torvi > Filename : draft-ietf-teas-rsvp-ingress-protection-02.txt > Pages : 23 > Date : 2015-03-09 > =20 > Abstract: > This document describes extensions to Resource Reservation Protocol - > Traffic Engineering (RSVP-TE) for locally protecting the ingress node > of a Traffic Engineered (TE) Label Switched Path (LSP), which is a > Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protecti > on/ > =20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-02 > =20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-teas-rsvp-ingress-protecti > on-02 > =20 > =20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > =20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > =20 > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Mar 19 19:23:11 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B661A92B0 for ; Thu, 19 Mar 2015 19:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48KX_J4YWK-C for ; Thu, 19 Mar 2015 19:23:07 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id A5D491A92AD for ; Thu, 19 Mar 2015 19:23:07 -0700 (PDT) Received: (qmail 22162 invoked by uid 0); 20 Mar 2015 02:23:04 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 20 Mar 2015 02:23:04 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 5eNu1q0062SSUrH01eNxNn; Thu, 19 Mar 2015 20:23:02 -0600 X-Authority-Analysis: v=2.1 cv=dKs1xopb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=99K8i5EPIjMA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=AqI0xvK1tnMA:10 a=emO1SXQWCLwA:10 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8 a=KWOEbxL7AAAA:8 a=pGLkceISAAAA:8 a=d7JaHwvYrg0GejuYue8A:9 a=un1SviokOySV5UKo:21 a=R-oUkSvXA57Jiqte:21 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=z8MVzQCrcoosGhMaitiZ3njePdkPYS3vY2WkQu8+8JM=; b=VmQf9Prj0sPx5lH/nF0GLSpLNyvSedfmlSmG/zkFV9nt3F02QUbygycBTKUq7oEPpSbsTYmUp3EZF8wwYAWmS0/yKd+nr9syfgTG98OJAv99Y7qio09I1rcp1pRwvYD3; Received: from [74.96.190.213] (port=49911 helo=[11.4.0.117]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YYmaN-0006BP-VP; Thu, 19 Mar 2015 20:22:56 -0600 From: Lou Berger To: Huaimo Chen , , Date: Thu, 19 Mar 2015 22:22:54 -0400 Message-ID: <14c34fd7c90.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E376D31@SJCEML701-CHM.china.huawei.com> References: <20150309201246.7568.85606.idtracker@ietfa.amsl.com> <5316A0AB3C851246A7CA5758973207D44E369B5D@SJCEML701-CHM.china.huawei.com> <550971E2.1000806@labn.net> <5316A0AB3C851246A7CA5758973207D44E376D31@SJCEML701-CHM.china.huawei.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.1.13 (build: 21020013) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.96.190.213 authed with lberger@labn.net} Archived-At: Cc: Raveendra Torvi , Markus Jork , Boris.Zhang@telus.com, Richard Li , ningso01@gmail.com, Autumn Liu , Quintin zhao , Tarek Saad , Alia Atlas , Yimin Shen , Fengman Xu , liulei.kddi@gmail.com, Lizhenbin Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 02:23:09 -0000 On March 19, 2015 9:05:43 PM Huaimo Chen wrote: > Hi Lou, > > Thanks much for your comments. > > For the open issue in this draft, we are going to have some meetings > recently to try to resolve it. > Keep in mind that any resolution must be agreed to by the WG... Lou > For your comments for the egress protection draft, which are applicable to > this draft, they were addressed in the draft as follows: > > > - You mention GMPLS, which is good, but don't mention how the document > relates to RFC4872 and 4873. I'm not saying that the document can't be > limited to FRR protection, but do want to at least discuss if a unified > approach can be found for FRR and 4873 style segment protection. The > conclusion of this discussion will need to reflected in someway in the > document, either as a change in the mechanisms or an explicit statement of > scope. > > [Huaimo] Removed GMPLS from abstract. > > > > > - You can define values for objects/TLVs defined in this document. > [Huaimo] Defined values for new objects/TLVs. > > > > - You combined v4/v6 object definition is subject to misinterpretation. > > It needs to be clarified. I suggest using past RFCs as a reference of > how this can be done, e.g., see RFC4875. > > [Huaimo] Defined IPv4 and IPv6 objects separately. > > > - The iana section doesn't follow rfc5226. See some recent RFCs for > examples. (I just reviewed draft-ietf-teas-rsvp-te-li-lb and it provides an > example for exiting registries, but not establishing a new one. > > > > [Huaimo] Wrote IANA section in details. > > > > > - Your references need to be revisited/cleaned up. There are some > clearly stale references and the normative/informative split doesn't make a > whole lot of sense. > > > > [Huaimo] Cleaned up the references. > > > Best Regards, > Huaimo > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, March 18, 2015 8:39 AM > To: Huaimo Chen; teas@ietf.org; vbeeram@juniper.net > Cc: Raveendra Torvi; Markus Jork; Boris.Zhang@telus.com; Richard Li; > ningso01@gmail.com; Autumn Liu; Quintin zhao; Tarek Saad; Alia Atlas; Yimin > Shen; Fengman Xu; liulei.kddi@gmail.com; Lizhenbin > Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-ingress-protection-02.txt > > Huaimo, Co-authors, > What is your plan for resolving the major open issue on this document? > (BTW I'm completely baffled by the WGLC reference!) > > Also, a general comment: When addressing comments sent to the list, please > respond directly to the message containing the comment and discuss the > details of how you (plan to) address the comment. > Alternatively, you can summarize the details of each issue resolution in a > single message after publication of a new version. In other words "We > addressed the comments from..." is a bit too terse. > > Thanks, > Lou > > On 3/13/2015 6:34 PM, Huaimo Chen wrote: > > Hi Everyone, > > > > We addressed the comments from Lou in this version. > > > > There are two methods for a backup ingress to get the information > > to provide protection for the primary ingress of an LSP in the draft. > > One method needs to be selected. After this is resolved, the draft is > > ready for WGLC. > > > > Best Regards, > > Huaimo > > > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Monday, March 09, 2015 4:13 PM > > To: i-d-announce@ietf.org > > Cc: teas@ietf.org > > Subject: [Teas] I-D Action: > > draft-ietf-teas-rsvp-ingress-protection-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Traffic Engineering Architecture and > > Signaling Working Group of the IETF. > > > > Title : Extensions to RSVP-TE for LSP Ingress Local > > Protection > > Authors : Huaimo Chen > > Raveendra Torvi > > Filename : draft-ietf-teas-rsvp-ingress-protection-02.txt > > Pages : 23 > > Date : 2015-03-09 > > > > Abstract: > > This document describes extensions to Resource Reservation Protocol - > > Traffic Engineering (RSVP-TE) for locally protecting the ingress node > > of a Traffic Engineered (TE) Label Switched Path (LSP), which is a > > Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protecti > > on/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-ingress-protecti > > on-02 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Fri Mar 20 00:45:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F031B2C6A for ; Fri, 20 Mar 2015 00:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbBBjBjmTZpY for ; Fri, 20 Mar 2015 00:45:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECAE01B2C69 for ; Fri, 20 Mar 2015 00:45:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTX15880; Fri, 20 Mar 2015 07:44:33 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Mar 2015 07:44:32 +0000 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.171]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Fri, 20 Mar 2015 15:44:30 +0800 From: "Zhangxian (Xian)" To: Vishnu Pavan Beeram Thread-Topic: [Teas] Update on Thread-Index: AQHQYnvfaKUHfhGyQ0KAGqtWg0kKZJ0kj6tQ Date: Fri, 20 Mar 2015 07:44:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B471AB716SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-teas-network-assigned-upstream-label@tools.ietf.org" , "teas@ietf.org" Subject: Re: [Teas] Update on X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 07:45:18 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471AB716SZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIFBhdmFuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSB1cGRhdGUuDQoNCkNvdWxkIHlvdSBleHBs YWluIGEgYml0IHRoZSBtb3RpdmF0aW9uIG9mIHRoaXMgdXBkYXRlPyBTaW5jZSBub3cgaXQgaXMg U0hPVUxEIG5vdCBNVVNUOyBzbyB3aXRoIGEgZ29vZCByZWFzb24sIHRoZSBpbmdyZXNzL2VncmVz cyBjYW4gY2hvb3NlIHRvIGlnbm9yZSBzdWNoIGxhYmVsIG1vZGlmeSByZWNlaXZlZCBmcm9tIHRo ZSBvdGhlciBlbmQsIGJ5IG5vdCB0dW5pbmcgdGhlIG5ldyB3YXZlbGVuZ3RoLCB3aWxsIGl0IGJl IGFueSBpc3N1ZT8gQW55IGFkZGl0aW9uYWwgdGV4dHMgbmVlZGVkIHRvIGhhbmRsZSBpdD8NCg0K ICBJIHdpbGwgc2VuZCBtb3JlIGRldGFpbGVkIHJldmlldyBjb21tZW50cyBwcm9iYWJseSBhZnRl ciB0aGlzIElFVEYuDQoNClJlZ2FyZHMsDQpYaWFuDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFtDQpTZW50 OiAyMDE15bm0M+aciDIw5pelIDM6MzUNClRvOiB0ZWFzQGlldGYub3JnOyBkcmFmdC1pZXRmLXRl YXMtbmV0d29yay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbEB0b29scy5pZXRmLm9yZw0KU3ViamVj dDogW1RlYXNdIFVwZGF0ZSBvbiA8ZHJhZnQtaWV0Zi10ZWFzLW5ldHdvcmstYXNzaWduZWQtdXBz dHJlYW0tbGFiZWw+DQoNCldHLCBIaSENCkxhdGVzdCBVcGRhdGU6DQpBIG5ldyB2ZXJzaW9uIHdh cyBwdWJsaXNoZWQgcmVjZW50bHkuIFRoZSBmb2xsb3dpbmcgYXJlIHRoZSBkaWZmcyAtDQoNCiAg ICAgKiAgIFNlY3Rpb24gNi4yIC0gQ2hhbmdlIE1VU1QtPlNIT1VMRA0KDQogICAgICAgICogICDi gJxJbiBzdWNoIGEgc2NlbmFyaW8sIGlmIHRoZSBpbmdyZXNzIGNsaWVudCByZWNlaXZlcyBhIGNo YW5nZWQgbGFiZWwgdmlhIHRoZSBMQUJFTCBvYmplY3QgaW4gYSBSRVNWIG1vZGlmeSwgaXQgU0hP VUxEIHJldHVuZSB0aGUgbGFzZXIgYXQgdGhlIGluZ3Jlc3MgdG8gdGhlIG5ldyB3YXZlbGVuZ3Ro LiBTaW1pbGFybHkgaWYgdGhlIGVncmVzcyBjbGllbnQgcmVjZWl2ZXMgYSBjaGFuZ2VkIGxhYmVs IHZpYSBVUFNUUkVBTV9MQUJFTC9MQUJFTF9TRVQgaW4gYSBQQVRIIG1vZGlmeSwgaXQgU0hPVUxE IHJldHVuZSB0aGUgbGFzZXIgYXQgdGhlIGVncmVzcyB0byB0aGUgbmV3IHdhdmVsZW5ndGgu4oCd DQoNCiAgICAgKiAgIEFkZGVkIFphZmFyIEFsaSB0byB0aGUgbGlzdCBvZiBjb250cmlidXRvcnMN Ck9wZW4gSXNzdWVzOg0KTm9uZS4NCk5leHQgU3RlcHM6DQpSZXF1ZXN0IGZ1cnRoZXIgcmV2aWV3 IGZyb20gdGhlIFdHIChhdXRob3JzIGJlbGlldmUgdGhhdCB0aGUgZHJhZnQgaXMgcmVhZHkgdG8g cHJvZ3Jlc3MgdG8gdGhlIG5leHQgc3RhZ2UpDQoNClJlZ2FyZHMsDQotUGF2YW4NCihPbiBiZWhh bGYgb2YgdGhlIGF1dGhvcnMvY29udHJpYnV0b3JzKQ0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471AB716SZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjg4MzgzNjk4NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwOTA0NTk0MTg7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksIFBhdmFu LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRl bnQ6OS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhbmsgeW91IGZvciB0aGUgdXBkYXRlLiZuYnNwOw0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjkuNnB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWluZGVudDo5LjZwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Db3VsZCB5b3UgZXhwbGFpbiBhIGJpdCB0aGUgbW90aXZhdGlvbiBv ZiB0aGlzIHVwZGF0ZT8gU2luY2Ugbm93IGl0IGlzIFNIT1VMRCBub3QgTVVTVDsgc28gd2l0aCBh IGdvb2QgcmVhc29uLCB0aGUgaW5ncmVzcy9lZ3Jlc3MNCiBjYW4gY2hvb3NlIHRvIGlnbm9yZSBz dWNoIGxhYmVsIG1vZGlmeSByZWNlaXZlZCBmcm9tIHRoZSBvdGhlciBlbmQsIGJ5IG5vdCB0dW5p bmcgdGhlIG5ldyB3YXZlbGVuZ3RoLCB3aWxsIGl0IGJlIGFueSBpc3N1ZT8gQW55IGFkZGl0aW9u YWwgdGV4dHMgbmVlZGVkIHRvIGhhbmRsZSBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6OS42cHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Ojku NnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyBJIHdpbGwgc2VuZCBtb3JlIGRldGFpbGVkIHJldmlldyBjb21tZW50cyBwcm9i YWJseSBhZnRlciB0aGlzIElFVEYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjkuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8YnI+DQpYaWFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWFzIFttYWlsdG86dGVh cy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5WaXNobnUgUGF2YW4gQmVl cmFtPGJyPg0KPGI+U2VudDo8L2I+IDIwMTU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPuW5tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuaciDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIwPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4NCiAzOjM1PGJyPg0KPGI+VG86PC9iPiB0ZWFzQGlldGYub3JnOyBkcmFmdC1p ZXRmLXRlYXMtbmV0d29yay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbEB0b29scy5pZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbVGVhc10gVXBkYXRlIG9uICZsdDtkcmFmdC1pZXRmLXRlYXMt bmV0d29yay1hc3NpZ25lZC11cHN0cmVhbS1sYWJlbCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5XRywgSGkhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+TGF0ZXN0IFVwZGF0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QSBuZXcgdmVyc2lvbiB3 YXMgcHVibGlzaGVkIHJlY2VudGx5LiBUaGUgZm9sbG93aW5nIGFyZSB0aGUgZGlmZnMgLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0 eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIg bGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+U2VjdGlvbiA2LjIgLSBDaGFuZ2UgTVVTVC0mZ3Q7 U0hPVUxEPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNj Ij4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMyBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj7i gJxJbiBzdWNoIGEgc2NlbmFyaW8sIGlmIHRoZSBpbmdyZXNzIGNsaWVudCByZWNlaXZlcyBhIGNo YW5nZWQgbGFiZWwgdmlhIHRoZSBMQUJFTCBvYmplY3QgaW4gYSBSRVNWIG1vZGlmeSwgaXQgU0hP VUxEIHJldHVuZSB0aGUgbGFzZXIgYXQgdGhlIGluZ3Jlc3MgdG8gdGhlIG5ldyB3YXZlbGVuZ3Ro LiBTaW1pbGFybHkgaWYgdGhlIGVncmVzcyBjbGllbnQgcmVjZWl2ZXMgYSBjaGFuZ2VkIGxhYmVs IHZpYSBVUFNUUkVBTV9MQUJFTC9MQUJFTF9TRVQNCiBpbiBhIFBBVEggbW9kaWZ5LCBpdCBTSE9V TEQgcmV0dW5lIHRoZSBsYXNlciBhdCB0aGUgZWdyZXNzIHRvIHRoZSBuZXcgd2F2ZWxlbmd0aC7i gJ08bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJk aXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDIgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QWRkZWQgWmFmYXIgQWxpIHRv IHRoZSBsaXN0IG9mIGNvbnRyaWJ1dG9yczxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwv dWw+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PcGVu IElzc3Vlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vbmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+TmV4dCBTdGVwczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXF1ZXN0IGZ1cnRoZXIg cmV2aWV3IGZyb20gdGhlIFdHIChhdXRob3JzIGJlbGlldmUgdGhhdCB0aGUgZHJhZnQgaXMgcmVh ZHkgdG8gcHJvZ3Jlc3MgdG8gdGhlIG5leHQgc3RhZ2UpPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LVBhdmFuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+KE9uIGJlaGFsZiBvZiB0aGUgYXV0aG9ycy9jb250cmlidXRvcnMpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471AB716SZXEMA512MBSchi_-- From nobody Fri Mar 20 06:21:07 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C181B2D27; Fri, 20 Mar 2015 06:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ahrVzALIobi; Fri, 20 Mar 2015 06:21:05 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAB61B2D24; Fri, 20 Mar 2015 06:21:03 -0700 (PDT) Received: by oigv203 with SMTP id v203so90799088oig.3; Fri, 20 Mar 2015 06:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=yhzFZ6lbNULg8L4tJ5YkaaJFS2AJsIND6IT2qatsbSo=; b=s4P4eAI3wGkinv8B7y2cqvX20TzQon3FoYLwCCkcvG1eqtxY2ODdl+61ppinY4spAZ zIWv9q2LKQZGn6kbGhGV1JcPsZaufzJaTukBpb6p44MT8/M2rHdyi9xUjOvpg1XptBLo OJ0BwdOgZ2vkd1SwSF9Na5EN7lyfTBUW/SbYfbOpc6wS0kUjVn7T+Enfv38w3X++GWYG rMqJxWhp33WgmH5ZQaSJUBywxEsyJXdiHAYAkzpkw9SxoAG3JI9ILziLrBQ/QSXpVTZR vlWZOSd20trwcqxlecK8Vm8g+waRhbNww3MzG4Dh9lOQjzn9UkNKME4npjiKPAbbRPmi Lweg== MIME-Version: 1.0 X-Received: by 10.60.115.99 with SMTP id jn3mr66214610oeb.68.1426857662636; Fri, 20 Mar 2015 06:21:02 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Fri, 20 Mar 2015 06:21:02 -0700 (PDT) Date: Fri, 20 Mar 2015 09:21:02 -0400 Message-ID: From: Alia Atlas To: teas@ietf.org Content-Type: multipart/alternative; boundary=089e0116126e2066b00511b83001 Archived-At: Cc: "teas-chairs@ietf.org" Subject: [Teas] status of draft-ietf-teas-te-express-path X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 13:21:06 -0000 --089e0116126e2066b00511b83001 Content-Type: text/plain; charset=UTF-8 As a co-author of draft-ietf-teas-te-express-path, I'd like to update on its status. Current Status: This draft has been stable for a couple years. It has companion documents in OSPF (RFC 7471 ) and ISIS ( draft-ietf-isis-te-metric-extensions-04 which is in WG Last Call). Open Items: I don't know of any open items. Please do read and comment! Next Steps: I'd be happy to see this progress to WG Last Call. I think it is ready. If you have a chance and interest, please do review and send comments to the list. Thanks, Alia --089e0116126e2066b00511b83001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a co-author of=C2=A0draft-ietf-teas-te-express-path, I&= #39;d like to update on its status.

Current Status: =C2= =A0This draft has been stable for a couple years. =C2=A0 It has companion
documents in OSPF (RFC 7471 ) and ISIS (draft-ietf-isis-te-metric-extensio= ns-04
which is in WG Last Call).

Ope= n Items: =C2=A0I don't know of any open items.=C2=A0 Please do read and= comment!

Next Steps: I'd be happy to see this= progress to WG Last Call.=C2=A0 I think it is ready.

<= div>If you have a chance and interest, please do review and send comments t= o the list.

Thanks,
Alia
--089e0116126e2066b00511b83001-- From nobody Sat Mar 21 23:56:43 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158B01A1B99 for ; Sat, 21 Mar 2015 23:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKOGra7RhhIT for ; Sat, 21 Mar 2015 23:56:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0767.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:767]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DF71A1B96 for ; Sat, 21 Mar 2015 23:56:39 -0700 (PDT) Received: from BY2PR08CA0012.namprd08.prod.outlook.com (25.163.62.150) by BY1PR0801MB1015.namprd08.prod.outlook.com (25.160.203.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Sun, 22 Mar 2015 06:56:19 +0000 Received: from BL2FFO11FD024.protection.gbl (2a01:111:f400:7c09::122) by BY2PR08CA0012.outlook.office365.com (2a01:111:e400:58a4::22) with Microsoft SMTP Server (TLS) id 15.1.118.21 via Frontend Transport; Sun, 22 Mar 2015 06:56:19 +0000 Received: from sv-ex13-prd2.infinera.com (204.128.141.24) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.1.125.13 via Frontend Transport; Sun, 22 Mar 2015 06:56:18 +0000 Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd2.infinera.com (10.100.103.229) with Microsoft SMTP Server (TLS) id 15.0.847.32; Sat, 21 Mar 2015 23:55:11 -0700 Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.0847.030; Sat, 21 Mar 2015 23:55:11 -0700 From: Khuzema Pithewan To: "teas@ietf.org" Thread-Topic: draft-beeram-mpls-rsvp-te-scaling-01 Thread-Index: AdBkbIdTpYD0SeLGS1W2aJI6P53nJQ== Date: Sun, 22 Mar 2015 06:55:11 +0000 Message-ID: <85855ba1f59f46ed83c8975869ea36bb@sv-ex13-prd1.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.99.93] Content-Type: multipart/alternative; boundary="_000_85855ba1f59f46ed83c8975869ea36bbsvex13prd1infineracom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.24 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.24; helo=sv-ex13-prd2.infinera.com; Authentication-Results: spf=pass (sender IP is 204.128.141.24) smtp.mailfrom=kpithewan@infinera.com; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:204.128.141.24; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(501624003)(189002)(199003)(46102003)(54356999)(102836002)(15975445007)(16796002)(50986999)(4546004)(92566002)(84326002)(106466001)(33646002)(24736003)(19625215002)(108616004)(77096005)(230783001)(16236675004)(450100001)(62966003)(77156002)(19300405004)(512874002)(53416004)(86362001)(2900100001)(19580395003)(2501003)(5000100001)(6806004)(110136001)(2351001)(107886001)(229853001)(87936001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0801MB1015; H:sv-ex13-prd2.infinera.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0801MB1015; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY1PR0801MB1015; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0801MB1015; X-Forefront-PRVS: 0523CF0711 X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2015 06:56:18.1960 (UTC) X-MS-Exchange-CrossTenant-Id: 721df8b1-ce4d-49b9-ac0b-4264176aca82 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=721df8b1-ce4d-49b9-ac0b-4264176aca82; Ip=[204.128.141.24]; Helo=[sv-ex13-prd2.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0801MB1015 Archived-At: Subject: [Teas] draft-beeram-mpls-rsvp-te-scaling-01 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 06:56:42 -0000 --_000_85855ba1f59f46ed83c8975869ea36bbsvex13prd1infineracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQXV0aG9ycywNCg0KSSBhbSBub3Qgc3VyZSBJIGNsZWFybHkgdW5kZXJzdG9vZCB0aGUg dmFsdWUgcHJvcG9zaXRpb24gb2YgdGhpcyBjb250cmlidXRpb24uIFdoeSB0aGlzIGRyYWZ0IG5l ZWQgdG8gYXNzdW1lIHRoYXQgcmZjMjk2MSBpcyBub3QgaW1wbGVtZW50ZWQgZm9yIHNjYWxpbmcg YW5kIHJlY29tbWVuZCB0aGUgaW1wbGVtZW50YXRpb24gb2YgaXQuDQoNCk1vc3Qgb2YgdGhlIHRl eHQgaW4gdGhlIGRvY3VtZW50IHJlZmVycyB0byBzdHVmZiBpbiAyOTYxLiBJIGRvIHNlZSBmZXcg dGhpbmdzIHRoYXQgdGhpcyBkcmFmdCBtYXkgYmUgYXNraW5nIGluIGFkZGl0aW9uIHRvIDI5NjEs IGJ1dCB3b3VsZCBhcHByZWNpYXRlIGlmIGF1dGhvcnMgY2FuIGNyaXNwbHkgbGlzdCB0aG9zZSB0 aGluZ3MsIHNvIHRoYXQgaXQgY2FuIGRlYmF0ZWQuDQoNClRoYW5rcw0KS2h1emVtYQ0K --_000_85855ba1f59f46ed83c8975869ea36bbsvex13prd1infineracom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IZWxsbyBBdXRob3JzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bSBub3Qgc3VyZSBJIGNsZWFybHkgdW5kZXJzdG9vZCB0aGUgdmFsdWUgcHJvcG9zaXRpb24gb2Yg dGhpcyBjb250cmlidXRpb24uIFdoeSB0aGlzIGRyYWZ0IG5lZWQgdG8gYXNzdW1lIHRoYXQgcmZj Mjk2MSBpcyBub3QgaW1wbGVtZW50ZWQgZm9yIHNjYWxpbmcgYW5kDQogcmVjb21tZW5kIHRoZSBp bXBsZW1lbnRhdGlvbiBvZiBpdC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Nb3N0IG9mIHRoZSB0ZXh0IGluIHRoZSBk b2N1bWVudCByZWZlcnMgdG8gc3R1ZmYgaW4gMjk2MS4gSSBkbyBzZWUgZmV3IHRoaW5ncyB0aGF0 IHRoaXMgZHJhZnQgbWF5IGJlIGFza2luZyBpbiBhZGRpdGlvbiB0byAyOTYxLCBidXQgd291bGQg YXBwcmVjaWF0ZSBpZiBhdXRob3JzDQogY2FuIGNyaXNwbHkgbGlzdCB0aG9zZSB0aGluZ3MsIHNv IHRoYXQgaXQgY2FuIGRlYmF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+S2h1emVtYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_85855ba1f59f46ed83c8975869ea36bbsvex13prd1infineracom_-- From nobody Mon Mar 23 07:35:56 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785851A8AEE for ; Mon, 23 Mar 2015 07:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5Lrxe0t0iAw for ; Mon, 23 Mar 2015 07:35:53 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC2A1A8AFB for ; Mon, 23 Mar 2015 07:35:41 -0700 (PDT) Received: by wixw10 with SMTP id w10so64688074wix.0 for ; Mon, 23 Mar 2015 07:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=FxkIz8sH5Ou8RmDbEfz8uVSnJZucipLsGIQvzubzV3U=; b=KsGduW/zXWPHDRP+V1KzdiQsVQjNvkhvgWIn8AciM/Wp+Bnvs7WNXj+kpyizbEUtaE PQrMkK0uTDKFoh6srS4/JbDFYHPYQ/UlIsrPqhcp33EGhh92C/7lVanSuaHoSO8I4eyl s7k4wIrCA+o3Tw0yibF9LzNpzrDMtWVd0CP3hbakBO8I9PLi/zzzruYAyJwRyKO5eki8 k/tB34xLnTpCL/RTD8gpsM8kBV3vMfTr3+84mSYKiYoXKo75e1WvQWlbD/mNFMr7tT6c 7z4DsTphOWIVke7rP87UDPrY1GaVHQenUAfRkkguCpaQkGLVZ5j8wzbauSXEvWbuSs1Q HEWw== MIME-Version: 1.0 X-Received: by 10.194.220.7 with SMTP id ps7mr189841503wjc.84.1427121340132; Mon, 23 Mar 2015 07:35:40 -0700 (PDT) Received: by 10.27.51.145 with HTTP; Mon, 23 Mar 2015 07:35:40 -0700 (PDT) Date: Mon, 23 Mar 2015 10:35:40 -0400 Message-ID: From: Cyril Margaria To: teas@ietf.org Content-Type: multipart/alternative; boundary=001a11c1b42487d78b0511f594a3 Archived-At: Subject: [Teas] Update of draft-ietf-teas-lsp-attribute-ro X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:35:54 -0000 --001a11c1b42487d78b0511f594a3 Content-Type: text/plain; charset=UTF-8 All, We are not planning to present the document in Dallas, so a brief update. Current status: Following Last Call update, the document was updated to resolve the comments. The document was processed by the IESG last week and approved for publication after additional IESG telechat review comments have been addressed. Next steps: New revision addressing IESG telechat comments will be posted very soon. Best Regards Cyril. --001a11c1b42487d78b0511f594a3 Content-Type: text/html; charset=UTF-8
All,

We are not planning to present the document in Dallas, so a brief update.

Current status: Following Last Call update, the document was updated to resolve the comments. The document was processed by the IESG last week and approved for publication after additional IESG telechat review comments have been addressed.

Next steps: New revision addressing IESG telechat comments will be posted very soon.

Best Regards
Cyril.
--001a11c1b42487d78b0511f594a3-- From nobody Mon Mar 23 08:45:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8AF1A8A0F; Mon, 23 Mar 2015 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJmF-NMeDf-7; Mon, 23 Mar 2015 08:45:17 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6201A6F3F; Mon, 23 Mar 2015 08:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=477; q=dns/txt; s=iport; t=1427125517; x=1428335117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P3d/5iVHnH1/aLvKidpNSpU/vFgdOo+BYEiRf/1yPr8=; b=B6IARiazt5UYd11uePbMlWK56NKOSfMAsL15B/n51YW1Qe/LlQYiBMox SwNdfNLx41U+rL33RGLBCzRZ1zcVERbypmY+VKRnixKdArpB7aa1flT+T dwzlBhYiZSLS6quy3pFnUnMyVsq10YgyWgcrNV9j+3ivfRMY3bf1QQL/A s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnBABzNBBV/51dJa1cgwaBMMR9h0QCgSk4FAEBAQEBAQF8hBQBAQEDATo/BQsCAQgiFBAyJQEBBA4NiB8IyDwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiyGERDEHgxeBFgEEkE+LCYMwiGyDLINHIoNugjN/AQEB X-IronPort-AV: E=Sophos;i="5.11,452,1422921600"; d="scan'208";a="134573072" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP; 23 Mar 2015 15:45:16 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2NFjGle009208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Mar 2015 15:45:17 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.251]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Mon, 23 Mar 2015 10:45:16 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Slides and updates for Dallas Thread-Index: AdBibVTHaOjQlQV4SianoZNlgai9/gDEvUAQ Date: Mon, 23 Mar 2015 15:45:16 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BE8BDE@xmb-rcd-x03.cisco.com> References: <9D50FCE7413E3D4EA5E42331115FB5BC29BE0AC3@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29BE0AC3@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.249.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas-chairs@ietf.org" Subject: Re: [Teas] Slides and updates for Dallas X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:45:18 -0000 Thanks to all of you who have sent slides. Another reminder for those who h= aven't :) Cheers Matt > A friendly reminder... >=20 > If you're presenting, please make sure that you've sent your slides to me > and the Chairs by Sunday. >=20 > If you have a WG document and it's not being presented, we're expecting a > brief status update. Thanks to those who have already sent them; others, > please do so. >=20 > Thanks >=20 > Matt, Deborah, Lou and Pavan From nobody Tue Mar 24 07:00:53 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DA91A8718; Tue, 24 Mar 2015 07:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1wW8FG2j7yo; Tue, 24 Mar 2015 07:00:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1C11A870F; Tue, 24 Mar 2015 07:00:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324140050.16453.52266.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 07:00:50 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-lsp-attribute-ro-05.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:00:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : LSP Attribute in ERO Authors : Cyril Margaria Giovanni Martinelli Steve Balls Ben Wright Filename : draft-ietf-teas-lsp-attribute-ro-05.txt Pages : 14 Date : 2015-03-24 Abstract: RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) objects to allow it to specify or record generic attributes which apply to a given hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-lsp-attribute-ro-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-lsp-attribute-ro-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 24 08:32:57 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8661A8927; Tue, 24 Mar 2015 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UefmKcJXr3Bv; Tue, 24 Mar 2015 08:32:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA081A8930; Tue, 24 Mar 2015 08:32:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324153246.26897.79578.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:32:46 -0700 Archived-At: Cc: teas chair , teas mailing list , RFC Editor Subject: [Teas] Protocol Action: 'LSP Attribute in ERO' to Proposed Standard (draft-ietf-teas-lsp-attribute-ro-05.txt) X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:32:54 -0000 The IESG has approved the following document: - 'LSP Attribute in ERO' (draft-ietf-teas-lsp-attribute-ro-05.txt) as Proposed Standard This document is the product of the Traffic Engineering Architecture and Signaling Working Group. The IESG contact persons are Alia Atlas and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ Technical Summary RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of an Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) objects to allow it to specify or record generic attributes which apply to a given hop. Working Group Summary This document moved from the CCAMP to TEAS WGs as part of the routing WG changes. This document has been fairly noncontroversial. Document Quality The base GMPLS protocol has been implemented. The extensions defined in this document are compatible with earlier implementations. While there have been no public statements on implementation, the authors are from multiple vendors, and implementation is expected. The mechanisms defined in this document are being used in two other extensions that have already been submitted for publication, and in a number of other documents that are work in progress. Personnel Lou Berger is the Document Shepherd Adrian Farrel is the Responsible Area Director From nobody Wed Mar 25 12:30:38 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7041AC41D; Wed, 25 Mar 2015 12:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV5obVxwNS9L; Wed, 25 Mar 2015 12:30:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3842D1A8A76; Wed, 25 Mar 2015 12:30:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQS02546; Wed, 25 Mar 2015 19:30:30 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Mar 2015 19:30:30 +0000 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 12:30:20 -0700 From: Leeyoung To: "actn@ietf.org" , "TEAS WG (teas@ietf.org)" Thread-Topic: New Version Notification for draft-actn-requirement-01.txt Thread-Index: AQHQZzAGjyyncj5X0kGKEH3lT3GOtZ0tlQgA Date: Wed, 25 Mar 2015 19:30:19 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729CA9515@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] FW: New Version Notification for draft-actn-requirement-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:30:37 -0000 RllJLCBhIGJyYW5kIG5ldyBkcmFmdCBvbiBBQ1ROIHJlcXVpcmVtZW50IGp1c3QgcHVibGlzaGVk LiANCg0KWW91bmcgb24gYmVoYWxmIG9mIGNvLWF1dGhvcnMuDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyNSwgMjAxNSAyOjE1 IFBNDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBMZWV5b3VuZzsgS2h1emVtYSBQaXRoZXdhbjsg RGFuaWVsZSBDZWNjYXJlbGxpOyBMZWV5b3VuZzsgU2VyZ2lvIEJlbG90dGk7IEtodXplbWEgUGl0 aGV3YW47IFNlcmdpbyBCZWxvdHRpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWFjdG4tcmVxdWlyZW1lbnQtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWFjdG4tcmVxdWlyZW1lbnQtMDEudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgWW91bmcgTGVlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZToJCWRyYWZ0LWFjdG4tcmVxdWlyZW1lbnQNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlS ZXF1aXJlbWVudHMgZm9yIEFic3RyYWN0aW9uIGFuZCBDb250cm9sIG9mIFRyYW5zcG9ydCBOZXR3 b3Jrcw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0yNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1p c3Npb24NClBhZ2VzOgkJMjUNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1hY3RuLXJlcXVpcmVtZW50LTAxLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFjdG4tcmVxdWlyZW1l bnQvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWN0 bi1yZXF1aXJlbWVudC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWFjdG4tcmVxdWlyZW1lbnQtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRyYWZ0IHByb3ZpZGVzIGEgc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgYWJzdHJhY3Rpb24gYW5k DQogICBjb250cm9sIG9mIHRyYW5zcG9ydCBuZXR3b3Jrcy4NCg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Mar 26 07:19:01 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D121ACEF6; Thu, 26 Mar 2015 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGSiuV5D8ELj; Thu, 26 Mar 2015 07:18:55 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E0A1ACECC; Thu, 26 Mar 2015 07:18:50 -0700 (PDT) Received: by iecvj10 with SMTP id vj10so47464154iec.0; Thu, 26 Mar 2015 07:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3+3YEEy5UqJllMUgY5tig5uVKw84oPQQmrMa6GGbEvo=; b=ez1L97tQK87D8aHUX/uztATtKMfWzpewyQ5TV4b6SxVrNp4f6ilC2tviZPrVgiVmd2 nmV9u+ZDXIz0cGJdrTgiN1eckvjw50L8X894RyzonpbAXtt/JJ7OHMuBSzC5sZWfHii1 31pV491OfNj66TQYVY6tco+bh7ib1mXKHiLpSqbd65kUInAdLQsd/0p9IwpfRjhBWtHG 4kZgdi17Dr1CT3Ft13w4pW12dGMvNMjS3+1191yg2cEu+TRiycgZAGY7+Q1RXMm6G43C Kki7hNReJ9lZCKnv6+rPpnYDNMw9YwyQ3yrbO26ue8Szrh5hu6AbTq/nuiLf0Niic8Sa 9nXA== MIME-Version: 1.0 X-Received: by 10.42.94.65 with SMTP id a1mr37429063icn.1.1427379530075; Thu, 26 Mar 2015 07:18:50 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.167.2 with HTTP; Thu, 26 Mar 2015 07:18:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 09:18:49 -0500 X-Google-Sender-Auth: tSZKHxi9ntSj1_-gbsNsL6zHRZ0 Message-ID: From: Dhruv Dhody To: Alia Atlas Content-Type: multipart/alternative; boundary=20cf303345f3d99605051231b147 Archived-At: Cc: "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] status of draft-ietf-teas-te-express-path X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:18:56 -0000 --20cf303345f3d99605051231b147 Content-Type: text/plain; charset=UTF-8 Hi, As mentioned on the mic, I think this comment got lost somewhere... OLD: For link loss, the path loss is not the sum of the used links' losses. Instead, the path loss percentage is 100 - (100 - loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links along the path are L1 to Ln. NEW: For link loss, the path loss is not the sum of the used links' losses. Instead, the path loss fraction is 1 - (1 - loss_L1)*(1 - loss_L2)*...*(1 - loss_Ln), where the links along the path are L1 to Ln with loss_Li in fractions. This also matches with http://tools.ietf.org/html/rfc6049#page-18 and https://tools.ietf.org/id/draft-ietf-pce-pcep-service-aware-07.html#rfc.section.4.1.3 Also, since these metrics can also be used in a network with a PCE, a mention somewhere in the draft would be nice to have. Thanks! Dhruv On Fri, Mar 20, 2015 at 8:21 AM, Alia Atlas wrote: > As a co-author of draft-ietf-teas-te-express-path, I'd like to update on > its status. > > Current Status: This draft has been stable for a couple years. It has > companion > documents in OSPF (RFC 7471 ) and ISIS ( > draft-ietf-isis-te-metric-extensions-04 > > which is in WG Last Call). > > Open Items: I don't know of any open items. Please do read and comment! > > Next Steps: I'd be happy to see this progress to WG Last Call. I think it > is ready. > > If you have a chance and interest, please do review and send comments to > the list. > > Thanks, > Alia > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --20cf303345f3d99605051231b147 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As mentioned on the mic,=C2=A0I think this com= ment got lost somewhere...=C2=A0

OLD:

=C2=A0 =C2=A0For link loss, the path loss is not the sum of th= e used links'
=C2=A0 =C2=A0losses.=C2=A0 Instead, the path loss perc= entage is 100 - (100 -
=C2=A0 =C2=A0loss_L1)*(100 - loss_L2)*...*(100 - = loss_Ln), where the links along=C2=A0
=C2=A0 =C2=A0the path are L1 to Ln.

NEW:

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0For link loss, the path los= s is not the sum of the used links'
=C2=A0 =C2=A0losses.=C2=A0 Inste= ad, the path loss fraction is 1 - (1 -
=C2=A0 =C2=A0loss_L1)*(1 - loss_L= 2)*...*(1 - loss_Ln), where the links along
=C2=A0 =C2=A0the path are L1= to Ln with loss_Li in fractions.

This also matches with http:= //tools.ietf.org/html/rfc6049#page-18 and=C2=A0https://tools.ietf.org/id/draft-ietf-pce-pcep-service-awar= e-07.html#rfc.section.4.1.3 =C2=A0

Also, since these metr= ics can also be used in a network with a PCE, a mention somewhere in the dr= aft would be nice to have.=C2=A0

Thanks!=C2=A0

Dhruv =C2=A0
On Fri, Mar 20, 2015 at 8:21 AM, Alia Atlas <= akatlas@gmail.com> wrote:
<= div dir=3D"ltr">As a co-author of=C2=A0draft-ietf-teas-te-express-path, I&#= 39;d like to update on its status.

Current Status: =C2= =A0This draft has been stable for a couple years. =C2=A0 It has companion
documents in OSPF (RFC 7471 ) and ISIS (draft-ietf-isis-= te-metric-extensions-04
which is in WG Last Call).
=
Open Items: =C2=A0I don't know of any open items.=C2=A0 = Please do read and comment!

Next Steps: I'd be= happy to see this progress to WG Last Call.=C2=A0 I think it is ready.

If you have a chance and interest, please do review a= nd send comments to the list.

Thanks,
Al= ia

_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--20cf303345f3d99605051231b147-- From nobody Thu Mar 26 07:20:29 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B761ACEC6; Thu, 26 Mar 2015 07:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seWB1R5q99JN; Thu, 26 Mar 2015 07:20:26 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2A31ACE81; Thu, 26 Mar 2015 07:20:23 -0700 (PDT) Received: by oicf142 with SMTP id f142so40923658oic.3; Thu, 26 Mar 2015 07:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GWNya3oo33ELv9I91i/drXj+qaZwwHtCi2AbCvOhDaM=; b=gdWVSCrqhOLEk5eWX8F+ZP0OL9HNmv/lKUap3n4hYWEitrgbcx/sSCHrU/RqgkE27s cm+dMt/CCv07OT656IA+ZqQZyAtqnnKf7l55jHPLQ4S5tMnxSys7WJuiR8POQiPTURlq +yFz2XYMOjiFtE5xeN8pkzapWjHU/GO1ojsd8eG3v69TJFOi0OCnMDcOHaYpViU7C007 Wzy62rPkT6FMkBi5rHjfxdgnS9dKcHAk57sKe6qR+a0K6Liad+8MiIElDO9OWrRLd11r M8Bdb0lRjSKyIYiKkLk3y8p0SreDWrGqL+0rA5g9EoVbE8ZMWxv21gmQZTs6zPfEHrR+ lZTw== MIME-Version: 1.0 X-Received: by 10.182.255.195 with SMTP id as3mr12237860obd.56.1427379622859; Thu, 26 Mar 2015 07:20:22 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Thu, 26 Mar 2015 07:20:22 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 10:20:22 -0400 Message-ID: From: Alia Atlas To: Dhruv Dhody Content-Type: multipart/alternative; boundary=001a1134a6166158ab051231b7c7 Archived-At: Cc: "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] status of draft-ietf-teas-te-express-path X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:20:27 -0000 --001a1134a6166158ab051231b7c7 Content-Type: text/plain; charset=UTF-8 Hi Dhruv, Yes - thanks. That change did get lost. I'll make it. Alia On Thu, Mar 26, 2015 at 10:18 AM, Dhruv Dhody wrote: > Hi, > > As mentioned on the mic, I think this comment got lost somewhere... > > OLD: > > For link loss, the path loss is not the sum of the used links' > losses. Instead, the path loss percentage is 100 - (100 - > loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links along > the path are L1 to Ln. > > NEW: > > For link loss, the path loss is not the sum of the used links' > losses. Instead, the path loss fraction is 1 - (1 - > loss_L1)*(1 - loss_L2)*...*(1 - loss_Ln), where the links along > the path are L1 to Ln with loss_Li in fractions. > > This also matches with http://tools.ietf.org/html/rfc6049#page-18 and > https://tools.ietf.org/id/draft-ietf-pce-pcep-service-aware-07.html#rfc.section.4.1.3 > > > Also, since these metrics can also be used in a network with a PCE, a > mention somewhere in the draft would be nice to have. > > Thanks! > > Dhruv > > On Fri, Mar 20, 2015 at 8:21 AM, Alia Atlas wrote: > >> As a co-author of draft-ietf-teas-te-express-path, I'd like to update on >> its status. >> >> Current Status: This draft has been stable for a couple years. It has >> companion >> documents in OSPF (RFC 7471 ) and ISIS ( >> draft-ietf-isis-te-metric-extensions-04 >> >> which is in WG Last Call). >> >> Open Items: I don't know of any open items. Please do read and comment! >> >> Next Steps: I'd be happy to see this progress to WG Last Call. I think >> it is ready. >> >> If you have a chance and interest, please do review and send comments to >> the list. >> >> Thanks, >> Alia >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > --001a1134a6166158ab051231b7c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dhruv,

Yes - thanks.=C2=A0 That chan= ge did get lost.=C2=A0 I'll make it.

Alia

On Thu, Ma= r 26, 2015 at 10:18 AM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
Hi,

As = mentioned on the mic,=C2=A0I think this comment got lost somewhere...=C2=A0=

OLD:

=C2=A0 =C2=A0For li= nk loss, the path loss is not the sum of the used links'
=C2=A0 =C2= =A0losses.=C2=A0 Instead, the path loss percentage is 100 - (100 -
=C2= =A0 =C2=A0loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links alo= ng=C2=A0
=C2=A0 =C2=A0the pa= th are L1 to Ln.

NEW:

=C2=A0 =C2=A0For link loss, the path loss is not the sum of the used = links'
=C2=A0 =C2=A0losses.=C2=A0 Instead, the path loss fraction is= 1 - (1 -
=C2=A0 =C2=A0loss_L1)*(1 - loss_L2)*...*(1 - loss_Ln), where t= he links along
=C2=A0 =C2=A0the path are L1 to Ln with loss_Li in fracti= ons.

This also matches with http://tools.ietf.org/html/rfc6049= #page-18 and=C2=A0https://tool= s.ietf.org/id/draft-ietf-pce-pcep-service-aware-07.html#rfc.section.4.1.3 =C2=A0



As a co-author of=C2=A0draft-= ietf-teas-te-express-path, I'd like to update on its status.

Current Status: =C2=A0This draft has been stable for a couple year= s. =C2=A0 It has companion
documents in OSPF (RFC 7471 ) and ISIS= (draft-ietf-isis-te-metric-extensions-04
which is = in WG Last Call).

Open Items: =C2=A0I don't kn= ow of any open items.=C2=A0 Please do read and comment!

Next Steps: I'd be happy to see this progress to WG Last Call.=C2= =A0 I think it is ready.

If you have a chance and = interest, please do review and send comments to the list.

Thanks,
Alia

_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas



--001a1134a6166158ab051231b7c7-- From nobody Thu Mar 26 07:53:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B991A1B1C; Thu, 26 Mar 2015 07:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz0rMTRRu_zE; Thu, 26 Mar 2015 07:53:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3E21A03A9; Thu, 26 Mar 2015 07:52:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326145218.22232.83368.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 07:52:18 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-te-express-path-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:53:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Performance-based Path Selection for Explicitly Routed LSPs using TE Metric Extensions Authors : Alia Atlas John Drake Spencer Giacalone Dave Ward Stefano Previdi Clarence Filsfils Filename : draft-ietf-teas-te-express-path-01.txt Pages : 10 Date : 2015-03-26 Abstract: In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE LSP. Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification uses network performance data, such as is advertised via the OSPF and ISIS TE metric extensions (defined outside the scope of this document) to perform such path selections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-te-express-path/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-teas-te-express-path-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-te-express-path-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 26 07:56:22 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E791A1EF3; Thu, 26 Mar 2015 07:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fnfCgB8J3hs; Thu, 26 Mar 2015 07:56:19 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1920E1ACEB3; Thu, 26 Mar 2015 07:54:14 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so47455512obd.3; Thu, 26 Mar 2015 07:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nEeYJwNEmOmAt1CCADG1aV68o6UfdkRmIRJZcLANchU=; b=YDtau7IW+RFjk0SdFVAcROQxfy/IzXC7JyeUIzFvys1E0ppVY06p09PHFLgPXMmS5L tCc1xQQRO5YLymehEpyiDHghZuNA+daS1GM1cwcqe8Esb75M1w70Aw7IDvRbqkJ6+0Vt 401On2JiiysztHHzSweAUJn/Dd//geUYfzeid00rhZ8KU5gtclPVEU5wHKmtLr0jCY59 Uy/hqSbx5vVOFRsSINNRYffs4jtfZbXmzTK8N7byhU/E+GbuL2ITXXX7/j+mWrLKd7Y0 YQZMc2CkZ0rqkMoAWVNBbYuJ6lh3RM87M3IBb/CyA1q3mkKZ1ZmzzlObPfNcHYw9QlZn O/BQ== MIME-Version: 1.0 X-Received: by 10.60.42.211 with SMTP id q19mr12367063oel.58.1427381653608; Thu, 26 Mar 2015 07:54:13 -0700 (PDT) Received: by 10.60.44.198 with HTTP; Thu, 26 Mar 2015 07:54:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Mar 2015 10:54:13 -0400 Message-ID: From: Alia Atlas To: Dhruv Dhody Content-Type: multipart/alternative; boundary=089e0111dcc26c20060512323091 Archived-At: Cc: "teas-chairs@ietf.org" , "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] status of draft-ietf-teas-te-express-path X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:56:21 -0000 --089e0111dcc26c20060512323091 Content-Type: text/plain; charset=UTF-8 I have submitted an updated version, draft-ietf-teas-te-express-path, with these changes. http://datatracker.ietf.org/doc/draft-ietf-teas-te-express-path/ Please let me know if there are any other suggestions. Thanks again! Alia On Thu, Mar 26, 2015 at 10:18 AM, Dhruv Dhody wrote: > Hi, > > As mentioned on the mic, I think this comment got lost somewhere... > > OLD: > > For link loss, the path loss is not the sum of the used links' > losses. Instead, the path loss percentage is 100 - (100 - > loss_L1)*(100 - loss_L2)*...*(100 - loss_Ln), where the links along > the path are L1 to Ln. > > NEW: > > For link loss, the path loss is not the sum of the used links' > losses. Instead, the path loss fraction is 1 - (1 - > loss_L1)*(1 - loss_L2)*...*(1 - loss_Ln), where the links along > the path are L1 to Ln with loss_Li in fractions. > > This also matches with http://tools.ietf.org/html/rfc6049#page-18 and > https://tools.ietf.org/id/draft-ietf-pce-pcep-service-aware-07.html#rfc.section.4.1.3 > > > Also, since these metrics can also be used in a network with a PCE, a > mention somewhere in the draft would be nice to have. > > Thanks! > > Dhruv > > On Fri, Mar 20, 2015 at 8:21 AM, Alia Atlas wrote: > >> As a co-author of draft-ietf-teas-te-express-path, I'd like to update on >> its status. >> >> Current Status: This draft has been stable for a couple years. It has >> companion >> documents in OSPF (RFC 7471 ) and ISIS ( >> draft-ietf-isis-te-metric-extensions-04 >> >> which is in WG Last Call). >> >> Open Items: I don't know of any open items. Please do read and comment! >> >> Next Steps: I'd be happy to see this progress to WG Last Call. I think >> it is ready. >> >> If you have a chance and interest, please do review and send comments to >> the list. >> >> Thanks, >> Alia >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > --089e0111dcc26c20060512323091 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have submitted an updated version, draft-ietf-teas-te-ex= press-path, with these changes.


Please let me know if there are any other suggestions.

Thanks again!
Alia
=
On Thu, Mar 26, 2015 at 10:18 AM, Dhruv Dhod= y <dhruv.ietf@gmail.com> wrote:
Hi,

As mentioned on the mic,=C2=A0I think= this comment got lost somewhere...=C2=A0

OLD:

=C2=A0 =C2=A0For link loss, the path loss is not the = sum of the used links'
=C2=A0 =C2=A0losses.=C2=A0 Instead, the path = loss percentage is 100 - (100 -
=C2=A0 =C2=A0loss_L1)*(100 - loss_L2)*..= .*(100 - loss_Ln), where the links along=C2=A0
=C2=A0 =C2=A0the path are L1 to Ln.

NEW: =

=C2=A0 =C2=A0For link loss, the= path loss is not the sum of the used links'
=C2=A0 =C2=A0losses.=C2= =A0 Instead, the path loss fraction is 1 - (1 -
=C2=A0 =C2=A0loss_L1)*(1= - loss_L2)*...*(1 - loss_Ln), where the links along
=C2=A0 =C2=A0the pa= th are L1 to Ln with loss_Li in fractions.

This also matches= with http://tools.ietf.org/html/rfc6049#page-18 and=C2=A0https://tools.ietf.org/id/draft-ietf-pce-pcep-ser= vice-aware-07.html#rfc.section.4.1.3 =C2=A0

Also, since t= hese metrics can also be used in a network with a PCE, a mention somewhere = in the draft would be nice to have.=C2=A0

Thanks!= =C2=A0

Dhruv =C2=A0

On Fri, Mar 2= 0, 2015 at 8:21 AM, Alia Atlas <akatlas@gmail.com> wrote:
As a co-author of=C2=A0draft-ietf-teas-te-express-path, I'd li= ke to update on its status.

Current Status: =C2=A0This d= raft has been stable for a couple years. =C2=A0 It has companion
= documents in OSPF (RFC 7471 ) and ISIS (draft-ietf-isis-te-metric= -extensions-04
which is in WG Last Call).

Open Items: =C2=A0I don't know of any open items.=C2=A0 Please do= read and comment!

Next Steps: I'd be happy to= see this progress to WG Last Call.=C2=A0 I think it is ready.
If you have a chance and interest, please do review and send c= omments to the list.

Thanks,
Alia
<= /div>
_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas



--089e0111dcc26c20060512323091-- From nobody Thu Mar 26 09:32:12 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797901A876C for ; Thu, 26 Mar 2015 09:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OskRJf00VgWf for ; Thu, 26 Mar 2015 09:32:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71FD1A875D for ; Thu, 26 Mar 2015 09:32:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2QGW6v3001983 for ; Thu, 26 Mar 2015 16:32:06 GMT Received: from 950129200 (dhcp-b383.meeting.ietf.org [31.133.179.131]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t2QGW4Zj001972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 26 Mar 2015 16:32:05 GMT From: "Adrian Farrel" To: Date: Thu, 26 Mar 2015 16:32:03 -0000 Message-ID: <020b01d067e2$654561a0$2fd024e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBn4lyZAX8YC5BgQjCBQ1zfWtK9Og== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21426.007 X-TM-AS-Result: No--1.113-10.0-31-10 X-imss-scan-details: No--1.113-10.0-31-10 X-TMASE-MatchedRID: b9K50FTGWzVqcOCJ4oqGauEbUg4xvs+wCQ3xS+zL6e267Q3uPo9KIwOR 3tZA0vji4vM1YF6AJbZcLc3sLtjOt7bmZosI/5Zy3QfwsVk0UbuGrPnef/I+ej5J/W5lWOurQFI wLyMOQrZFJXam6Mi+n8YuzsmbzL5MEimxoxTab7GvcsTuUejg0omQ2vqumwAFVUH85vIcwrl2A/ 3Nl4P8kQ== Archived-At: Subject: [Teas] Thought on draft-chen-teas-rsvp-ttz X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 16:32:10 -0000 Hi, I'd really like to see this work described in the context of draft-ietf-teas-interconnected-te-info-exchange I want to understand whether you are proposing a second architecture or something that develops from our existing architecture. Thanks, Adrian From nobody Thu Mar 26 11:05:51 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CD01B2A0E for ; Thu, 26 Mar 2015 11:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4znMV9zLIUXt for ; Thu, 26 Mar 2015 11:05:48 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624C61B29FB for ; Thu, 26 Mar 2015 11:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=243; q=dns/txt; s=iport; t=1427393143; x=1428602743; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=V1ehmXGtfFGJLe7YyQqH50sJFjPFk3tidgQUpBRsJrM=; b=R2VgfpolMIHo6JSUTVPXx78OvFtN08rEoqWO9BNxKm4oF2Tz17wHXF5o YM4TdU6hWuHOVi1bj+dVHVnLR+qNOq/tUWxKl0pwq3J1rDGS6NiTXrgM3 e7JdiiV1EDriTQGibh0LeCuD/AkrDbhKNC0XSiXtaTJ/rIQCU+I6F3K1f Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C+CwAlShRV/4sNJK1cgwZSWgEDwl2CUIVzAoFcTAEBAQEBAX1BAYNUAQQ6PxIBKhRCJgEEDg2IJw3LbgEBAQEGAQEBAQEdj28xgx6BFgWQUINvhxs6gnaPYiKDbnCBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,473,1422921600"; d="scan'208";a="135709410" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP; 26 Mar 2015 18:05:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t2QI5RQs012565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Mar 2015 18:05:28 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 13:05:27 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Minutes... Thread-Index: AdBn70c6AHkwks32RcWwrNCyMVZ4+w== Date: Thu, 26 Mar 2015 18:05:27 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BF18A4@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: [Teas] Minutes... X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:05:49 -0000 All, The minutes I took during the meeting are at http://etherpad.tools.ietf.org= :9000/p/notes-ietf-92-teas?useMonospaceFont=3Dtrue. Please have a look and = feel free to add or correct anything I missed or got wrong! Cheers Matt From nobody Thu Mar 26 12:09:51 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C691E1ABC75 for ; Thu, 26 Mar 2015 12:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA2faC1dFNRg for ; Thu, 26 Mar 2015 12:09:49 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248E81A9151 for ; Thu, 26 Mar 2015 12:09:49 -0700 (PDT) Received: by qgf60 with SMTP id 60so95373592qgf.3 for ; Thu, 26 Mar 2015 12:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rZQYpVj1gIdZK8oHqWETYocZ8/IkHqcZHP/1VC/fZrM=; b=ZWnSyXmzYB6EknZOaq6yqb0L9S8kJBmkFBveCoVxDUu33eMn2IcZfwbXvMFJGw0I4L HJunF0uyzU4HzUtHFVdsz2JOOP5WiqeKX9kDaDpsvfAE29yec57LuLf49P8BLKj0Py+d 1KnZ5T4pG5vpkV55Hxdcp5JVxFgmTUoba3nCokAJAqOYpYQjRB110NqlsYPqsUpx+cO9 lPK9jBMwfTR/AGotbzr9Ap9Zudpll0BUCsUsEJMrJjseq4s1Nj4RiAZFwB2GuYHh2zHG FoeWEBbhWNjFSgbbLWgjHagkZZxlOot85WsqO8TKTryN/ILEKbWFlCVD5pzHStg7g0ez P4VA== MIME-Version: 1.0 X-Received: by 10.140.47.1 with SMTP id l1mr19642854qga.44.1427396958972; Thu, 26 Mar 2015 12:09:18 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Thu, 26 Mar 2015 12:09:18 -0700 (PDT) Date: Thu, 26 Mar 2015 15:09:18 -0400 Message-ID: From: Vishnu Pavan Beeram To: "teas@ietf.org" Content-Type: multipart/alternative; boundary=001a11c14adeb17091051235c0a8 Archived-At: Subject: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:09:51 -0000 --001a11c14adeb17091051235c0a8 Content-Type: text/plain; charset=UTF-8 https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 Folks, Hi! was presented earlier today in the TEAS WG session. There wasn't sufficient time to take in questions at the end of the presentation (apologize for that). So, I'm opening up this thread to make sure that all those questions get answered. A few points to note: 1. These recommendations were put together for catering to current MPLS RSVP-TE Scalability needs. But since most of them have generic applicability, this draft is being discussed in TEAS. 2. There are 3 underlying principles driving these recommendations - Completely eliminate the reliance on refreshes for state sync. - Completely eliminate the reliance on refresh timeouts for stale state cleanup. - Implement per-peer flow control. 3. This is not a theoretical exercise. We have an implementation that religiously adopts these recommendations -- and the savings in terms of processing cycles for the control-plane (as a result of the significant reduction in I/O overhead) is quite significant. Please do give these recommendations some serious consideration and let us know your questions/comments. Regards, -Pavan (on behalf of the authors) --001a11c14adeb17091051235c0a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<draft-beeram-mpls= -rsvp-te-scaling> was presented earlier today in the TEAS WG session. Th= ere wasn't sufficient time to take in questions at the end of the prese= ntation (apologize for that). So, I'm opening up this thread to make su= re that all those questions get answered.

A few points to= note:

1. These recommendations were put together for cat= ering to current MPLS RSVP-TE Scalability needs. But since most of them hav= e generic applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations <= br>
- Completely eliminate the reliance on refreshes for state sy= nc.
- Completely eliminate the reliance on refresh timeouts f= or stale state cleanup.
- Implement per-peer flow control.
3. This is not a theoretical exercise. We have an implement= ation that religiously adopts these recommendations -- and the savings in t= erms of processing cycles for the control-plane (as a result of the signifi= cant reduction in I/O overhead) is quite significant.

Ple= ase do give these recommendations some serious consideration and let us kno= w your questions/comments.

Regards,
-Pavan<= br>
(on behalf of the authors)



--001a11c14adeb17091051235c0a8-- From nobody Thu Mar 26 12:28:23 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6284C1A914A for ; Thu, 26 Mar 2015 12:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phb6WPcv_JUN for ; Thu, 26 Mar 2015 12:28:20 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD82B1A8A9B for ; Thu, 26 Mar 2015 12:28:20 -0700 (PDT) Received: by qgh3 with SMTP id 3so98631306qgh.2 for ; Thu, 26 Mar 2015 12:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KZ6KsKzzde8JZ07XdeqoA0NB2RAS8dfPKBnSUsfTZkw=; b=TSfspbWht1ZQk896hhCw9klTwSGdI8IBFqy4bJpFhW5Zya3YvCpJwqdzcx9qrlQVgA EV6Bs3md8vmU0z843Eok3dVRMrSgIiGxNy+fucSl6oycp84SdsCBI5orlAYhOsXRp4S6 9a4iIROPiQRjGEO3tK5HvHc/pwjjX3RjqoPxNh8zYfeAnrj6HdvVqS8kjv14DxiHWJId 4yEPET2C4Wey9zZiv4IutNahmNU5tGODmEJzL0HZ0w0GhYHPb9GwNJqLa1FTBoh/DbWV pAS/Lu4zvgQFaBXLpc1di2/1z/XuHzBfgzzjpoVnaHoKQUHU+sG22+ozIUJLDAjnjBPG QGUQ== MIME-Version: 1.0 X-Received: by 10.55.40.87 with SMTP id o84mr32936678qkh.78.1427398097703; Thu, 26 Mar 2015 12:28:17 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Thu, 26 Mar 2015 12:28:17 -0700 (PDT) Date: Thu, 26 Mar 2015 15:28:17 -0400 Message-ID: From: Vishnu Pavan Beeram To: "teas@ietf.org" Content-Type: multipart/alternative; boundary=001a11441742911b410512360411 Archived-At: Subject: [Teas] RSVP Set-Up Retry Draft X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:28:22 -0000 --001a11441742911b410512360411 Content-Type: text/plain; charset=UTF-8 Draft: https://tools.ietf.org/html/draft-ravisingh-teas-rsvp-setup-retry-00 Presentation: http://www.ietf.org/proceedings/92/slides/slides-92-teas-13.pptx Folks, Hi! We didn't have sufficient time to cover this draft in detail in this morning's TEAS WG Session. So, opening up a thread for this on the mailing list. As stated this morning, this (BCP) draft discusses a specific implementation issue associated with the "setup retry" timer and makes some recommendations to solve it. Please do go through the draft and the associated presentation (links above) and let us know if you have any questions/comments. Regards, -Pavan (On behalf of the authors) --001a11441742911b410512360411 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We didn't have suf= ficient time to cover this draft in detail in this morning's TEAS WG Se= ssion. So, opening up a thread for this on the mailing list. As stated this= morning, this (BCP) draft discusses a specific implementation issue associated with the "setup retry" timer and makes some=20 recommendations to solve it.

Please do go through the draft and the = associated presentation (links above) and let us know if you have any quest= ions/comments.

Regards,
-Pavan
(O= n behalf of the authors)
--001a11441742911b410512360411-- From nobody Thu Mar 26 12:32:01 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23561B2B2C for ; Thu, 26 Mar 2015 12:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76ogq8TOuvuQ for ; Thu, 26 Mar 2015 12:31:56 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7A51B2B11 for ; Thu, 26 Mar 2015 12:31:48 -0700 (PDT) Received: from [31.133.164.137] (dhcp-a489.meeting.ietf.org [31.133.164.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D420018013C8; Thu, 26 Mar 2015 20:31:46 +0100 (CET) Message-ID: <55145EA1.3010905@pi.nu> Date: Thu, 26 Mar 2015 14:31:45 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Vishnu Pavan Beeram , "teas@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:31:58 -0000 Pavan, The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks" RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp- te-scaling. The topics seems close enough to make worth look at that document. /Loa On 2015-03-26 14:09, Vishnu Pavan Beeram wrote: > https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 > > Folks, Hi! > > was presented earlier today in the > TEAS WG session. There wasn't sufficient time to take in questions at > the end of the presentation (apologize for that). So, I'm opening up > this thread to make sure that all those questions get answered. > > A few points to note: > > 1. These recommendations were put together for catering to current MPLS > RSVP-TE Scalability needs. But since most of them have generic > applicability, this draft is being discussed in TEAS. > > 2. There are 3 underlying principles driving these recommendations > - Completely eliminate the reliance on refreshes for state sync. > - Completely eliminate the reliance on refresh timeouts for stale state > cleanup. > - Implement per-peer flow control. > > 3. This is not a theoretical exercise. We have an implementation that > religiously adopts these recommendations -- and the savings in terms of > processing cycles for the control-plane (as a result of the significant > reduction in I/O overhead) is quite significant. > > Please do give these recommendations some serious consideration and let > us know your questions/comments. > > Regards, > -Pavan > (on behalf of the authors) > > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Mar 26 12:39:51 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE001B2DEA for ; Thu, 26 Mar 2015 12:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sxzZeARsVlF for ; Thu, 26 Mar 2015 12:39:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0606.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:606]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB511B2DE1 for ; Thu, 26 Mar 2015 12:39:34 -0700 (PDT) Received: from CY1PR0401MB1019.namprd04.prod.outlook.com (25.160.161.11) by CY1PR0401MB1020.namprd04.prod.outlook.com (25.160.161.12) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 26 Mar 2015 19:39:14 +0000 Received: from CY1PR0401MB1019.namprd04.prod.outlook.com ([25.160.161.11]) by CY1PR0401MB1019.namprd04.prod.outlook.com ([25.160.161.11]) with mapi id 15.01.0118.022; Thu, 26 Mar 2015 19:39:14 +0000 From: Hariharan Ananthakrishnan To: "teas@ietf.org" Thread-Topic: draft-liu-teas-yang-te-topo-01 Thread-Index: AQHQZ/yJfpBR4LiHZUG+WbC1qvazAw== Date: Thu, 26 Mar 2015 19:39:13 +0000 Message-ID: <36A274A2-7611-4EF0-B68E-67ED06569696@packetdesign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.180.3] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0401MB1020; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(164054003)(50986999)(230783001)(62966003)(77156002)(2656002)(87936001)(2351001)(107886001)(54356999)(83716003)(66066001)(86362001)(106116001)(46102003)(110136001)(2501003)(229853001)(102836002)(450100001)(122556002)(16236675004)(40100003)(33656002)(2900100001)(36756003)(99286002)(92566002)(82746002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0401MB1020; H:CY1PR0401MB1019.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CY1PR0401MB1020; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0401MB1020; x-forefront-prvs: 0527DFA348 Content-Type: multipart/alternative; boundary="_000_36A274A276114EF0B68E67ED06569696packetdesigncom_" MIME-Version: 1.0 X-OriginatorOrg: packetdesign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2015 19:39:13.8123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1df5b6db-3686-4e87-9323-024e5bfe00f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0401MB1020 Archived-At: Subject: [Teas] draft-liu-teas-yang-te-topo-01 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:39:49 -0000 --_000_36A274A276114EF0B68E67ED06569696packetdesigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCg0KQ291cGxlIG9mIGNvbW1lbnRzOg0KDQpbMV0g4oCcaW1wb3J0IHRlZOKA nTogSXQgd291bGQgYmUgZ29vZCB0byBwcm92aWRlIHJlZmVyZW5jZSBmcm9tIHdoZXJlIOKAmHRl ZOKAmSBtb2R1bGUgaXMgYmVpbmcgcGlja2VkIHVwIGZyb20gKGRyYWZ0LWNsZW1tLWkycnMteWFu Zy1sMy10b3BvID8pDQpbMl0gSW1wb3J0aW5nIOKAmHRlZOKAmSBpbiB0ZS10b3BvIG1vZHVsZSB3 aWxsIG1ha2UgdGhpcyBtb2R1bGUg4oCZbm904oCZIGdlbmVyaWMsIHNpbmNlIHRlZCBoYXMgaXB2 NC9pcHY2IHJlZmVyZW5jZXMuIFNpbWlsYXIgaXNzdWVzIHdpdGggdXNhZ2Ugb2YgaW5ldDppcHY0 LWFkZHJlcyBhbmQgaW5ldDppcHY2LWFkZHJlc3MuDQpbM10gSSBhbSBub3Qgc3VyZSBoYXZpbmcg J2lzLWFic3RyYWN0JyBpbiBub2RlIGFuZCBsaW5rIGhlbHBzIGFzIHRlLXRvcG9sb2d5IGl0c2Vs ZiBpcyBzdXBwb3NlIHRvIGJlIGdlbmVyaWMgKG9yIGFic3RyYWN0KS4gSWYgdGhlcmUgaXMgcmVh bGx5IGEgdXNlLWNhc2UgdGhlbiB3ZSBzaG91bGQgbW92ZSB0aGlzIHRvIOKAnGdlbmVyaWMgbmV0 d29yay10b3BvbG9neeKAnSAoZHJhZnQtY2xlbW0taTJycy15YW5nLW5ldHdvcmstdG9wbyksIGFz c3VtaW5nIHRoaXMgdG9wb2xvZ3kgaXMgZ29pbmcgdG8gYmUgZGVyaXZlZCBmcm9tIGRyYWZ0LWNs ZW1tLWkycnMteWFuZy1uZXR3b3JrLXRvcG8uDQoNClRoYW5rcywNCi0gSGFyaQ0K --_000_36A274A276114EF0B68E67ED06569696packetdesigncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6AF5D7E5982E3C4F8D4424C6CB4601A9@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MXB4OyBmb250LWZhbWlseTogVmVyZGFuYSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIEF1dGhvcnMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Db3VwbGUgb2Yg Y29tbWVudHM6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bMV0g4oCcaW1wb3J0IHRl ZOKAnTogSXQgd291bGQgYmUgZ29vZCB0byBwcm92aWRlIHJlZmVyZW5jZSBmcm9tIHdoZXJlIOKA mHRlZOKAmSBtb2R1bGUgaXMgYmVpbmcgcGlja2VkIHVwIGZyb20gKGRyYWZ0LWNsZW1tLWkycnMt eWFuZy1sMy10b3BvID8pPC9kaXY+DQo8ZGl2PlsyXSBJbXBvcnRpbmcg4oCYdGVk4oCZIGluIHRl LXRvcG8gbW9kdWxlIHdpbGwgbWFrZSB0aGlzIG1vZHVsZSDigJlub3TigJkgZ2VuZXJpYywgc2lu Y2UgdGVkIGhhcyBpcHY0L2lwdjYgcmVmZXJlbmNlcy4gU2ltaWxhciBpc3N1ZXMgd2l0aCB1c2Fn ZSBvZiBpbmV0OmlwdjQtYWRkcmVzIGFuZCBpbmV0OmlwdjYtYWRkcmVzcy48L2Rpdj4NCjxkaXY+ WzNdIEkgYW0gbm90IHN1cmUgaGF2aW5nICdpcy1hYnN0cmFjdCcgaW4gbm9kZSBhbmQgbGluayBo ZWxwcyBhcyB0ZS10b3BvbG9neSBpdHNlbGYgaXMgc3VwcG9zZSB0byBiZSBnZW5lcmljIChvciBh YnN0cmFjdCkuIElmIHRoZXJlIGlzIHJlYWxseSBhIHVzZS1jYXNlIHRoZW4gd2Ugc2hvdWxkIG1v dmUgdGhpcyB0byDigJxnZW5lcmljIG5ldHdvcmstdG9wb2xvZ3nigJ0gKGRyYWZ0LWNsZW1tLWky cnMteWFuZy1uZXR3b3JrLXRvcG8pLCBhc3N1bWluZw0KIHRoaXMgdG9wb2xvZ3kgaXMgZ29pbmcg dG8gYmUgZGVyaXZlZCBmcm9tIGRyYWZ0LWNsZW1tLWkycnMteWFuZy1uZXR3b3JrLXRvcG8uPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2Pi0gSGFyaTwv ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_36A274A276114EF0B68E67ED06569696packetdesigncom_-- From nobody Thu Mar 26 12:56:13 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86741B2BBC for ; Thu, 26 Mar 2015 12:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pk_5SslSRmo2 for ; Thu, 26 Mar 2015 12:56:02 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05391A00E0 for ; Thu, 26 Mar 2015 12:56:01 -0700 (PDT) Received: by qgep97 with SMTP id p97so115654840qge.1 for ; Thu, 26 Mar 2015 12:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yaB1ZENnESe4NEFHZvWU1ax1JQng8eTUP9btDlDVMCY=; b=MsFAsQ3NUWlmw/6mdajlMD8aCNbgVGQOMA3V15gU1dp+KE9IoLny2nW85rlf0rZ/6F TB+LVBSwfQKB6smUuRcmmVGo9emoJftd1/ttUfcHPX1m3bg3TUfZWcwPnOGJUEoPErUr yZQKxgD5d8jBqRSZXIQuoKHRFKT68yV5tA1c8fpO/gTbjA53nz7mjhDh97p4CMyXVbm9 5C0bSM6HSjxR1xJDkXSeX+pOJwgkuDAYbhGlx64r8OO5HI9aQQmbhChJwrRiQqE6gy8x aPMItCpLSTb3OuEYAMDiXkyFgwtP6v4f0ojjrcMVAMnxzhN3jLlbQ9GV4VB6KyRUdPZ4 4pgg== MIME-Version: 1.0 X-Received: by 10.140.234.136 with SMTP id f130mr21134848qhc.49.1427399737848; Thu, 26 Mar 2015 12:55:37 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Thu, 26 Mar 2015 12:55:37 -0700 (PDT) In-Reply-To: <55145EA1.3010905@pi.nu> References: <55145EA1.3010905@pi.nu> Date: Thu, 26 Mar 2015 15:55:37 -0400 Message-ID: From: Vishnu Pavan Beeram To: Loa Andersson Content-Type: multipart/alternative; boundary=001a1135410653bbd0051236669d Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 19:56:04 -0000 --001a1135410653bbd0051236669d Content-Type: text/plain; charset=UTF-8 Loa, Hi! Thanks for pointing it out. Yes, not referencing/mentioning RFC 5439 was a mistake and that would be rectified in the next version. (But I did mention RFC5439 in this morning's presentation :)). Both RFC2961 and RFC5439 do talk about having a large refresh interval as a means of reducing the rate of messages that the control-plane has to process, but also warn about the loss of functionality associated with doing so. brings back the notion of refresh independent RSVP, but also includes recommendations that would make sure that there is no loss of functionality when a large refresh interval is used. Regards, -Pavan On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson wrote: > Pavan, > > The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks" > RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp- > te-scaling. The topics seems close enough to make worth look at that > document. > > /Loa > > > > > On 2015-03-26 14:09, Vishnu Pavan Beeram wrote: > >> https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 >> >> Folks, Hi! >> >> was presented earlier today in the >> TEAS WG session. There wasn't sufficient time to take in questions at >> the end of the presentation (apologize for that). So, I'm opening up >> this thread to make sure that all those questions get answered. >> >> A few points to note: >> >> 1. These recommendations were put together for catering to current MPLS >> RSVP-TE Scalability needs. But since most of them have generic >> applicability, this draft is being discussed in TEAS. >> >> 2. There are 3 underlying principles driving these recommendations >> - Completely eliminate the reliance on refreshes for state sync. >> - Completely eliminate the reliance on refresh timeouts for stale state >> cleanup. >> - Implement per-peer flow control. >> >> 3. This is not a theoretical exercise. We have an implementation that >> religiously adopts these recommendations -- and the savings in terms of >> processing cycles for the control-plane (as a result of the significant >> reduction in I/O overhead) is quite significant. >> >> Please do give these recommendations some serious consideration and let >> us know your questions/comments. >> >> Regards, >> -Pavan >> (on behalf of the authors) >> >> >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --001a1135410653bbd0051236669d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa, Hi!

Thanks for = pointing it out.

Yes, not referencing/mentioning RFC 5439 was = a mistake and that would be rectified in the next version. (But I did menti= on RFC5439 in this morning's presentation :)).

Both RFC296= 1 and RFC5439 do talk about having a large refresh interval as a means of r= educing the rate of messages that the control-plane has to process, but als= o warn about the loss of functionality associated with doing so. <draft-= beeram-mpls-rsvp-te-scaling> brings back the notion of refresh independe= nt RSVP, but also includes recommendations that would make sure that there = is no loss of functionality when a large refresh interval is used.

<= /div>Regards,
-Pavan


On Thu, Mar 26, = 2015 at 3:31 PM, Loa Andersson <loa@pi.nu> wrote:
Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Network= s"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa




On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:
https://tools.ietf.org/html/draft-beeram-mpls-rs= vp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented earlier toda= y in the
TEAS WG session. There wasn't sufficient time to take in questions at the end of the presentation (apologize for that). So, I'm opening up this thread to make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let
us know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)





_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--001a1135410653bbd0051236669d-- From nobody Thu Mar 26 20:07:21 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6471A90C8 for ; Thu, 26 Mar 2015 20:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_440T2TuUpj for ; Thu, 26 Mar 2015 20:07:18 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F4A1A90C7 for ; Thu, 26 Mar 2015 20:07:17 -0700 (PDT) Received: by qcto4 with SMTP id o4so7245222qct.3 for ; Thu, 26 Mar 2015 20:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LPDvuJMLA+RuVDztBgPr+olSS6XWHe+g0sSJ7wFZQG8=; b=gaDiyVWVe30693j0woX1FhGpZymt77AjE34QjpAx2BMliOxO5qi1CqC1sdtMCl65Oh L7I/8kT4i3TFCW2bI201hPHjCY2yLSFZspX6hhRRfaAkIM0vUbd0r7YK9e25wAFD0hRl Oy/zDczR1h/zBV/o9SFItcu6081ZI9nZtA/d13RD1uaqRxjvt4kkDFd7a7ipSLK84NTP rOAb+6SuQ2A2L3d4CLDQJOsElMQA32/QfwjGICvgD14yFqnKybljv9m7CzaIXnYxCFNL 0cdllgUbvUzFNY7U3KjcdtiSwe6H9b97mkAKk8yq4S8yTLxm79AMp2wRZf7Zky7i1Td6 mDYQ== MIME-Version: 1.0 X-Received: by 10.55.23.195 with SMTP id 64mr35275264qkx.76.1427425636953; Thu, 26 Mar 2015 20:07:16 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Thu, 26 Mar 2015 20:07:16 -0700 (PDT) In-Reply-To: References: <85855ba1f59f46ed83c8975869ea36bb@sv-ex13-prd1.infinera.com> Date: Thu, 26 Mar 2015 23:07:16 -0400 Message-ID: From: Vishnu Pavan Beeram To: Khuzema Pithewan , "teas@ietf.org" Content-Type: multipart/alternative; boundary=001a1147f1a208b3a405123c6eaa Archived-At: Subject: Re: [Teas] draft-beeram-mpls-rsvp-te-scaling-01 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 03:07:20 -0000 --001a1147f1a208b3a405123c6eaa Content-Type: text/plain; charset=UTF-8 + teas On Thu, Mar 26, 2015 at 11:06 PM, Vishnu Pavan Beeram wrote: > Khuzema, Hi! > > Apologize for the delayed response. I'm guessing that by now you have > already got all your doubts cleared :). > > The refresh overhead reduction procedures and recommendations defined in > [RFC2961] have had a substantial impact on RSVP-TE scalability and have > been solely responsible for all scalability specific claims that any RSVP > implementation has ever dared to make. But the scaling demands are growing > as rapidly as they ever have been and there is a definite need to refine > some of these recommendations if we have to push the envelope further on > scalability. And this is what this new draft attempts to do. Since the time > RFC2961 was published, there have a been a few other enhancements that have > been made to RSVP and RSVP-TE. This new draft discusses how an > implementation can take these existing recommendations and enhancements, > make some slight adjustments in terms of procedures and equip itself to > meet these growing scaling demands. > > I've opened a new thread to discuss all questions/comments associated with > this draft. Please do use that thread if you still have any questions. > > Regards, > -Pavan > > On Sun, Mar 22, 2015 at 2:55 AM, Khuzema Pithewan > wrote: > >> Hello Authors, >> >> >> >> I am not sure I clearly understood the value proposition of this >> contribution. Why this draft need to assume that rfc2961 is not implemented >> for scaling and recommend the implementation of it. >> >> >> >> Most of the text in the document refers to stuff in 2961. I do see few >> things that this draft may be asking in addition to 2961, but would >> appreciate if authors can crisply list those things, so that it can debated. >> >> >> >> Thanks >> >> Khuzema >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > --001a1147f1a208b3a405123c6eaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+ teas

On Thu, Mar 26, 2015 at 11:06 PM, Vishnu Pavan Beeram <vishnupavan@gmail.com> wrote:
Khuzema, Hi!

Apologize fo= r the delayed response. I'm guessing that by now you have already got a= ll your doubts cleared :).

The refresh overhead reduction procedure= s and recommendations defined in [RFC2961] have had a substantial impact on= RSVP-TE scalability and have been solely responsible for all scalability s= pecific claims that any RSVP implementation has ever dared to make. But the= scaling demands are growing as rapidly as they ever have been and there is= a definite need to refine some of these recommendations if we have to push= the envelope further on scalability. And this is what this new draft attem= pts to do. Since the time RFC2961 was published, there have a been a few ot= her enhancements that have been made to RSVP and RSVP-TE. This new draft di= scusses how an implementation can take these existing recommendations and e= nhancements, make some slight adjustments in terms of procedures and equip = itself to meet these growing scaling demands.

I've opened a new = thread to discuss all questions/comments associated=20 with this draft. Please do use that thread if you still have any=20 questions.

Regards,
-Pavan

On Sun, Ma= r 22, 2015 at 2:55 AM, Khuzema Pithewan <kpithewan@infinera.com&g= t; wrote:

Hello Authors,<= u>

=C2=A0

I am not sure I clearly u= nderstood the value proposition of this contribution. Why this draft need t= o assume that rfc2961 is not implemented for scaling and recommend the implementation of it.

=C2=A0

Most of the text in the d= ocument refers to stuff in 2961. I do see few things that this draft may be= asking in addition to 2961, but would appreciate if authors can crisply list those things, so that it can debated.

=C2=A0

Thanks

Khuzema


_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas



--001a1147f1a208b3a405123c6eaa-- From nobody Mon Mar 30 09:44:38 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8C01A700B for ; Mon, 30 Mar 2015 09:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9HM-gWL773k for ; Mon, 30 Mar 2015 09:44:35 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 519E41A011D for ; Mon, 30 Mar 2015 09:44:35 -0700 (PDT) Received: (qmail 22381 invoked by uid 0); 30 Mar 2015 16:44:34 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 30 Mar 2015 16:44:34 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 9skU1q00P2SSUrH01skXJu; Mon, 30 Mar 2015 10:44:32 -0600 X-Authority-Analysis: v=2.1 cv=QsLNgzCd c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=mlFM_a_ONtUA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=C4l4/fIr9KqBSiXWEoucexKm+sTJt0H69OgvcViSnc8=; b=iLAuvi3MS8DosNN/cQHITUdYHBd8da8TDoG59vGmOxVPw2uUDw+ZCova83EdE0P5N03pAPpgScsF+h9pAdQxIaD0WikV2ORqN5FFF6MNrlHlpM3f+NCsFYYhu08gItq1; Received: from box313.bluehost.com ([69.89.31.113]:54928 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Yccne-0004sN-5v; Mon, 30 Mar 2015 10:44:30 -0600 Message-ID: <55197D63.4050803@labn.net> Date: Mon, 30 Mar 2015 12:44:19 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Xufeng Liu , Igor Bryski , Vishnu Pavan Beeram , Tarek Saad , Himanshu Shah Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: TEAS WG Subject: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 16:44:36 -0000 Authors, Contributors, (TEAS) As part of the preparation for polling for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Mon Mar 30 09:46:19 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4151A702E for ; Mon, 30 Mar 2015 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-zf8bP0RcyD for ; Mon, 30 Mar 2015 09:46:17 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495021A8750 for ; Mon, 30 Mar 2015 09:45:55 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id t2UGiqIF005411; Mon, 30 Mar 2015 12:45:45 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1tf8v88ds3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2015 12:45:45 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 30 Mar 2015 12:45:44 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 30 Mar 2015 12:45:43 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Mon, 30 Mar 2015 12:45:43 -0400 From: "Shah, Himanshu" To: Lou Berger , Xufeng Liu , "Igor Bryski" , Vishnu Pavan Beeram , Tarek Saad , Himanshu Shah Date: Mon, 30 Mar 2015 12:45:41 -0400 Thread-Topic: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo Thread-Index: AdBrCNkFOC9bgcswT8+edtDzsY4LCwAABNew Message-ID: <40746B2300A8FC4AB04EE722A593182B87C93EA5@ONWVEXCHMB04.ciena.com> References: <55197D63.4050803@labn.net> In-Reply-To: <55197D63.4050803@labn.net> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-21436.000 X-TM-AS-Result: No--8.737900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-30_04:2015-03-30,2015-03-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503300159 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 16:46:19 -0000 No, I'm not aware of any IPR that applies to this draft /himanshu -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, March 30, 2015 12:44 PM To: Xufeng Liu; Igor Bryski; Vishnu Pavan Beeram; Tarek Saad; Himanshu Shah Cc: TEAS WG Subject: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo Authors, Contributors, (TEAS) As part of the preparation for polling for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your respons= e. _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Mar 30 12:29:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732131ACC7F for ; Mon, 30 Mar 2015 12:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUeKC_BJBFQG for ; Mon, 30 Mar 2015 12:29:27 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7911ACCE2 for ; Mon, 30 Mar 2015 12:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=242; q=dns/txt; s=iport; t=1427743767; x=1428953367; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=fviBa4MI0c33K5FFtWC5lGccRQc3zPXtYpcGmez6ey4=; b=Z1Y2Jkfnnfb4eVaBSGT+qggvOZvaPSPdOCp6dJjPlgUBBy5kmgAwBi88 /fuULfIbLf8vYN3/Yw+iyeX/QLuIUskqpZUipYcazg4QKy/V+bJQddOJc fTy78m7xNYivvBcNPZ+gh0kr/QyfTp3/P3fyKu0RFdQVkn9Sgrz/bpUFN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DpBAAxoxlV/4oNJK1cgwZSXsNmgUuFeQKBOjgUAQEBAQEBAXyEFgEEOj8SASoUQiYBBA4NiCcNzHYBAQEBBgEBAQEBHY9lMYMegRYFkE+DbocaOoJ2j14ig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,495,1422921600"; d="scan'208";a="136624503" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 30 Mar 2015 19:29:26 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2UJTQQm023721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Mar 2015 19:29:26 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 14:29:26 -0500 From: "Matt Hartley (mhartley)" To: "TEAS WG (teas@ietf.org)" Thread-Topic: Draft minutes available Thread-Index: AdBrGZpgH80+SLcIT5STibddGORDpw== Date: Mon, 30 Mar 2015 19:29:25 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BF762D@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.193.133] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "Lou Berger \(lberger@labn.net\)" , "BRUNGARD, DEBORAH A \(db3546@att.com\)" , "Vishnu Pavan Beeram \(vbeeram@juniper.net\)" Subject: [Teas] Draft minutes available X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 19:29:31 -0000 All, Draft minutes from Dallas are now available. You can find them at http://to= ols.ietf.org/wg/teas/minutes. The etherpad is still there too. Please let us (me, Pavan, Lou) know if there's any issues/corrections. Cheers Matt From nobody Tue Mar 31 08:36:08 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E260D1AC3CA for ; Tue, 31 Mar 2015 08:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dZebUWcQ43h for ; Tue, 31 Mar 2015 08:36:01 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E207A1A907B for ; Tue, 31 Mar 2015 08:36:00 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-9b-551a5c9e220a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B3.EB.17241.E9C5A155; Tue, 31 Mar 2015 10:36:47 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Tue, 31 Mar 2015 11:35:59 -0400 From: Xufeng Liu To: "Shah, Himanshu" , Lou Berger , "Igor Bryski" , Vishnu Pavan Beeram , Tarek Saad , Himanshu Shah Thread-Topic: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo Thread-Index: AQHQawjQjUJvFOO62kqrqkQC+ze0/501fuaAgAE7g+A= Date: Tue, 31 Mar 2015 15:35:58 +0000 Message-ID: References: <55197D63.4050803@labn.net> <40746B2300A8FC4AB04EE722A593182B87C93EA5@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B87C93EA5@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLonUHd+jFSowc/f7Ba7Nq5mtDjV085o 0dH8lsWi9ccOFotPJ34yWSxYM5PZgc3j7II/rB5nb/5j8ZjyeyOrx5IlP5k8rjddZff4sKmZ LYAtissmJTUnsyy1SN8ugSvj8Ba5gpmiFQu6BRoYXwp0MXJySAiYSJybNJ0ZwhaTuHBvPVsX IxeHkMBRRokJU68wQTjLGSXaVh0AquLgYBPQkrj81BEkLiJwHyj+djI7SDezgLRE29W3rCC2 sICDxPRTb1hA6kUEHCX2Tq0BCYsIWEnMbj7DBmKzCKhKvJl6EKyVV8Bb4u7SSWBHCAlkSyxu XAU2hlPAT+L3vzZGEJsR6Ljvp9YwQawSl7j1ZD4TxNECEkv2nId6QFTi5eN/rBC2osS+/ulQ p+lILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVI0dpcWpZbrqR 4SZGYMQdk2Bz3MG44JPlIUYBDkYlHl6FfslQIdbEsuLK3EOM0hwsSuK8ZVcOhggJpCeWpGan phakFsUXleakFh9iZOLglGpgFLOx+RvbJS06KXG6TEVKPWtT+RWG+A3Pts/LPi9uLeLNVXDT W059Qfhv3t1x5jd6C8Us526Z/nmN3sT3jNXV2u/4tndf3WNXcH3bOu/u2splTrzGx8NP35x0 wlxuZxZz47+razMtjoS9WhxdfH+jqRtLsG7RZ6lY1as37RhjM1eVe+byfDutxFKckWioxVxU nAgAXB01E5kCAAA= Archived-At: Cc: TEAS WG Subject: Re: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 15:36:03 -0000 No, I'm not aware of any IPR that applies to this draft. - Xufeng > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Monday, March 30, 2015 12:46 PM > To: Lou Berger; Xufeng Liu; Igor Bryski; Vishnu Pavan Beeram; Tarek Saad; > Himanshu Shah > Cc: TEAS WG > Subject: RE: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo >=20 > No, I'm not aware of any IPR that applies to this draft /himanshu >=20 > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, March 30, 2015 12:44 PM > To: Xufeng Liu; Igor Bryski; Vishnu Pavan Beeram; Tarek Saad; Himanshu Sh= ah > Cc: TEAS WG > Subject: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo >=20 > Authors, Contributors, (TEAS) >=20 > As part of the preparation for polling for WG document adoption: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the a= bove > by responding to this email regardless of whether or not you are aware of= any > relevant IPR. This document will not advance to the next stage until a r= esponse > has been received from each author and listed contributor. NOTE: THIS AP= PLIES > TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the WG email list or attend WG meetings but are not listed = as an > author or contributor, we remind you of your obligations under the IETF I= PR > rules which encourages you to notify the IETF if you are aware of IPR of = others > on an IETF contribution, or to refrain from participating in any contribu= tion or > discussion related to your undisclosed IPR. For more information, please = see the > RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > TEAS WG Chairs >=20 > PS Please include all listed in the headers of this message in your respo= nse. >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Mar 31 14:31:06 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92CF1A87A4 for ; Tue, 31 Mar 2015 14:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGHFoAOsiUGu for ; Tue, 31 Mar 2015 14:31:01 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C169A1A8768 for ; Tue, 31 Mar 2015 14:31:00 -0700 (PDT) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t2VLUu7T011381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Mar 2015 23:30:56 +0200 Received: from MUC-S-EX13B.advaoptical.com (172.20.1.17) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 31 Mar 2015 23:30:55 +0200 Received: from MUC-S-EX13B.advaoptical.com (172.20.1.17) by MUC-S-EX13B.advaoptical.com (172.20.1.17) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 31 Mar 2015 23:30:55 +0200 Received: from MUC-S-EX13B.advaoptical.com ([fe80::f1d8:4863:55fc:7577]) by MUC-S-EX13B.advaoptical.com ([fe80::f1d8:4863:55fc:7577%15]) with mapi id 15.00.1076.000; Tue, 31 Mar 2015 23:30:55 +0200 From: =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= To: Vishnu Pavan Beeram Thread-Topic: [Teas] RSVP TE Scalability - Recommendations Thread-Index: AQHQZ/hymseFyKa2RUWbwO6Imiz9GZ0vFkiAgAAGq4CACAG94A== Date: Tue, 31 Mar 2015 21:30:54 +0000 Message-ID: <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> References: <55145EA1.3010905@pi.nu> In-Reply-To: Accept-Language: pl-PL, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.27.50] Content-Type: multipart/alternative; boundary="_000_0fe4c449812b4174b42aacbdcf10a8a5MUCSEX13Badvaopticalcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-31_06:2015-03-31,2015-03-31,1970-01-01 signatures=0 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 21:31:05 -0000 --_000_0fe4c449812b4174b42aacbdcf10a8a5MUCSEX13Badvaopticalcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF2YW4sDQoNCkkgdGhpbmsgdGhpcyBpcyBncmVhdCB3b3JrIGFuZCBhcHBsaWVzIHdlbGwgdG8g dGhlIHBhY2tldCBuZXR3b3Jrcy4gSW1obyB0aGUgZHJhZnQgc2hvdWxkIGJlIGF1Z21lbnRlZCB0 byByZWZsZWN0IHRvIHdoYXQgaXMgdGhlIGRlZ3JlZSBvZiBhcHBsaWNhYmlsaXR5IHRvIHRyYW5z cG9ydCBuZXR3b3Jrcy4NCg0KWW91IHNhaWQ6DQoNCuKAnFRoZXJlIGFyZSAzIHVuZGVybHlpbmcg cHJpbmNpcGxlcyBkcml2aW5nIHRoZXNlIHJlY29tbWVuZGF0aW9uczoNCi0gQ29tcGxldGVseSBl bGltaW5hdGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2hlcyBmb3Igc3RhdGUgc3luYy4NCi0gQ29t cGxldGVseSBlbGltaW5hdGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2ggdGltZW91dHMgZm9yIHN0 YWxlIHN0YXRlDQpjbGVhbnVwLg0KLSBJbXBsZW1lbnQgcGVyLXBlZXIgZmxvdyBjb250cm9sLuKA nQ0KDQpJbiBvcmRlciB0byBhY2hpZXZlIHRoZXNlIHByaW5jaXBsZXMgeW91IHJlY29tbWVuZCDi gJxJbXBsZW1lbnRpbmcgY291cGxpbmcgdGhlIHN0YXRlIG9mIGluZGl2aWR1YWwgTFNQcyB3aXRo IHRoZSBzdGF0ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBSU1ZQLVRFIHNpZ25hbGluZyBhZGphY2Vu Y3ku4oCdIChjb3BpZWQgZnJvbSB0aGUgZHJhZnQpLiBTaW5jZSBpbiB0aGUgdHJhbnNwb3J0IG5l dHdvcmsgeW91IHJlYWxseSBzaG91bGRu4oCZdCBkbyB0aGF0LCBJ4oCZbSBpbnRlcmVzdGVkIGhv dyB5b3UgY2FuIGZ1bGZpbGwgYWJvdmUgbWVudGlvbmVkIHByaW5jaXBsZXMgd2l0aG91dCBpdC4g VG8gZ2l2ZSBhbiBleGFtcGxlOg0KDQpQcmluY2lwbGUgMjog4oCcQ29tcGxldGVseSBlbGltaW5h dGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2ggdGltZW91dHMgZm9yIHN0YWxlIHN0YXRl4oCdDQoN CkluIHRoZSBkcmFmdCB5b3UgYXNzdW1lIHRoYXQgc3RhbGUgc3RhdGUgd2lsbCBiZSByZW1vdmVk IHRoYW5rcyB0bzogYSkgcmVsaWFibGUgVGVhci9FcnIgbWVzc2FnZXMgZGVsaXZlcnkgYW5kIGIp IHJlbW92aW5nIG9mIGxzcCBzdGF0ZSBhZnRlciBhZGphY2VuY3kgbG9zcy4gU2luY2UgYikgZG9l cyBub3Qgd29yayBpbiB0cmFuc3BvcnQsIGhvdyBjYW4geW91IGNvdmVyIHNjZW5hcmlvcyBpbnZv bHZpbmcgYSByZWJvb3Qgb2YgYSBSU1ZQIHNwZWFrZXIgd2hpbGUgdGhlIHNlcnZpY2UgaXMgdG9y biBkb3duIGUuZy4gYnkgUGF0aFRlYXI/DQoNClRoYW5rcywNClBhd2VsDQoNCg0KRnJvbTogVGVh cyBbbWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpc2hudSBQYXZh biBCZWVyYW0NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjU2IFBNDQpUbzogTG9h IEFuZGVyc3Nvbg0KQ2M6IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVGVhc10gUlNWUCBU RSBTY2FsYWJpbGl0eSAtIFJlY29tbWVuZGF0aW9ucw0KDQpMb2EsIEhpIQ0KVGhhbmtzIGZvciBw b2ludGluZyBpdCBvdXQuDQpZZXMsIG5vdCByZWZlcmVuY2luZy9tZW50aW9uaW5nIFJGQyA1NDM5 IHdhcyBhIG1pc3Rha2UgYW5kIHRoYXQgd291bGQgYmUgcmVjdGlmaWVkIGluIHRoZSBuZXh0IHZl cnNpb24uIChCdXQgSSBkaWQgbWVudGlvbiBSRkM1NDM5IGluIHRoaXMgbW9ybmluZydzIHByZXNl bnRhdGlvbiA6KSkuDQpCb3RoIFJGQzI5NjEgYW5kIFJGQzU0MzkgZG8gdGFsayBhYm91dCBoYXZp bmcgYSBsYXJnZSByZWZyZXNoIGludGVydmFsIGFzIGEgbWVhbnMgb2YgcmVkdWNpbmcgdGhlIHJh dGUgb2YgbWVzc2FnZXMgdGhhdCB0aGUgY29udHJvbC1wbGFuZSBoYXMgdG8gcHJvY2VzcywgYnV0 IGFsc28gd2FybiBhYm91dCB0aGUgbG9zcyBvZiBmdW5jdGlvbmFsaXR5IGFzc29jaWF0ZWQgd2l0 aCBkb2luZyBzby4gPGRyYWZ0LWJlZXJhbS1tcGxzLXJzdnAtdGUtc2NhbGluZz4gYnJpbmdzIGJh Y2sgdGhlIG5vdGlvbiBvZiByZWZyZXNoIGluZGVwZW5kZW50IFJTVlAsIGJ1dCBhbHNvIGluY2x1 ZGVzIHJlY29tbWVuZGF0aW9ucyB0aGF0IHdvdWxkIG1ha2Ugc3VyZSB0aGF0IHRoZXJlIGlzIG5v IGxvc3Mgb2YgZnVuY3Rpb25hbGl0eSB3aGVuIGEgbGFyZ2UgcmVmcmVzaCBpbnRlcnZhbCBpcyB1 c2VkLg0KUmVnYXJkcywNCi1QYXZhbg0KDQoNCk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDM6MzEg UE0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQpQ YXZhbiwNCg0KVGhlIE1QTFMgd2cgZGlkICJBbiBBbmFseXNpcyBvZiBTY2FsaW5nIElzc3VlcyBp biBNUExTLVRFIENvcmUgTmV0d29ya3MiDQpSRkMgNTQzOS4gVGhpcyBSRkMgaXMgbm90IG1lbnRp b25lZCBpbiBkcmFmdC1iZWVyYW0tbXBscy1yc3ZwLQ0KdGUtc2NhbGluZy4gVGhlIHRvcGljcyBz ZWVtcyBjbG9zZSBlbm91Z2ggdG8gbWFrZSB3b3J0aCBsb29rIGF0IHRoYXQNCmRvY3VtZW50Lg0K DQovTG9hDQoNCg0KDQoNCk9uIDIwMTUtMDMtMjYgMTQ6MDksIFZpc2hudSBQYXZhbiBCZWVyYW0g d3JvdGU6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVlcmFtLW1wbHMtcnN2 cC10ZS1zY2FsaW5nLTAxDQoNCkZvbGtzLCBIaSENCg0KPGRyYWZ0LWJlZXJhbS1tcGxzLXJzdnAt dGUtc2NhbGluZz4gd2FzIHByZXNlbnRlZCBlYXJsaWVyIHRvZGF5IGluIHRoZQ0KVEVBUyBXRyBz ZXNzaW9uLiBUaGVyZSB3YXNuJ3Qgc3VmZmljaWVudCB0aW1lIHRvIHRha2UgaW4gcXVlc3Rpb25z IGF0DQp0aGUgZW5kIG9mIHRoZSBwcmVzZW50YXRpb24gKGFwb2xvZ2l6ZSBmb3IgdGhhdCkuIFNv LCBJJ20gb3BlbmluZyB1cA0KdGhpcyB0aHJlYWQgdG8gbWFrZSBzdXJlIHRoYXQgYWxsIHRob3Nl IHF1ZXN0aW9ucyBnZXQgYW5zd2VyZWQuDQoNCkEgZmV3IHBvaW50cyB0byBub3RlOg0KDQoxLiBU aGVzZSByZWNvbW1lbmRhdGlvbnMgd2VyZSBwdXQgdG9nZXRoZXIgZm9yIGNhdGVyaW5nIHRvIGN1 cnJlbnQgTVBMUw0KUlNWUC1URSBTY2FsYWJpbGl0eSBuZWVkcy4gQnV0IHNpbmNlIG1vc3Qgb2Yg dGhlbSBoYXZlIGdlbmVyaWMNCmFwcGxpY2FiaWxpdHksIHRoaXMgZHJhZnQgaXMgYmVpbmcgZGlz Y3Vzc2VkIGluIFRFQVMuDQoNCjIuIFRoZXJlIGFyZSAzIHVuZGVybHlpbmcgcHJpbmNpcGxlcyBk cml2aW5nIHRoZXNlIHJlY29tbWVuZGF0aW9ucw0KLSBDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUg cmVsaWFuY2Ugb24gcmVmcmVzaGVzIGZvciBzdGF0ZSBzeW5jLg0KLSBDb21wbGV0ZWx5IGVsaW1p bmF0ZSB0aGUgcmVsaWFuY2Ugb24gcmVmcmVzaCB0aW1lb3V0cyBmb3Igc3RhbGUgc3RhdGUNCmNs ZWFudXAuDQotIEltcGxlbWVudCBwZXItcGVlciBmbG93IGNvbnRyb2wuDQoNCjMuIFRoaXMgaXMg bm90IGEgdGhlb3JldGljYWwgZXhlcmNpc2UuIFdlIGhhdmUgYW4gaW1wbGVtZW50YXRpb24gdGhh dA0KcmVsaWdpb3VzbHkgYWRvcHRzIHRoZXNlIHJlY29tbWVuZGF0aW9ucyAtLSBhbmQgdGhlIHNh dmluZ3MgaW4gdGVybXMgb2YNCnByb2Nlc3NpbmcgY3ljbGVzIGZvciB0aGUgY29udHJvbC1wbGFu ZSAoYXMgYSByZXN1bHQgb2YgdGhlIHNpZ25pZmljYW50DQpyZWR1Y3Rpb24gaW4gSS9PIG92ZXJo ZWFkKSBpcyBxdWl0ZSBzaWduaWZpY2FudC4NCg0KUGxlYXNlIGRvIGdpdmUgdGhlc2UgcmVjb21t ZW5kYXRpb25zIHNvbWUgc2VyaW91cyBjb25zaWRlcmF0aW9uIGFuZCBsZXQNCnVzIGtub3cgeW91 ciBxdWVzdGlvbnMvY29tbWVudHMuDQoNClJlZ2FyZHMsDQotUGF2YW4NCihvbiBiZWhhbGYgb2Yg dGhlIGF1dGhvcnMpDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVh c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0K DQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFpbDogbG9h QG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3Ig TVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9h QHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYg NzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCg0K --_000_0fe4c449812b4174b42aacbdcf10a8a5MUCSEX13Badvaopticalcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhv ZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpQTDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3 MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJQTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhdmFuLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgdGhpbmsgdGhpcyBpcyBncmVhdCB3b3JrIGFuZCBhcHBsaWVzIHdlbGwgdG8g dGhlIHBhY2tldCBuZXR3b3Jrcy4gSW1obyB0aGUgZHJhZnQgc2hvdWxkIGJlIGF1Z21lbnRlZCB0 byByZWZsZWN0IHRvIHdoYXQgaXMgdGhlIGRlZ3JlZSBvZiBhcHBsaWNhYmlsaXR5DQogdG8gdHJh bnNwb3J0IG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3Ug c2FpZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPuKAnFRoZXJlIGFyZSAzIHVuZGVybHlpbmcgcHJp bmNpcGxlcyBkcml2aW5nIHRoZXNlIHJlY29tbWVuZGF0aW9uczo8L3NwYW4+PC9pPjxpPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIj4tIENvbXBsZXRlbHkgZWxpbWluYXRlIHRoZSByZWxpYW5jZSBvbiByZWZyZXNoZXMg Zm9yIHN0YXRlIHN5bmMuPGJyPg0KLSBDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUgcmVsaWFuY2Ug b24gcmVmcmVzaCB0aW1lb3V0cyBmb3Igc3RhbGUgc3RhdGU8YnI+DQpjbGVhbnVwLjxicj4NCi0g SW1wbGVtZW50IHBlci1wZWVyIGZsb3cgY29udHJvbC7igJ08L3NwYW4+PC9pPjxpPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBvcmRlciB0byBhY2hpZXZlIHRoZXNl IHByaW5jaXBsZXMgeW91IHJlY29tbWVuZCDigJw8aT5JbXBsZW1lbnRpbmcgY291cGxpbmcgdGhl IHN0YXRlIG9mIGluZGl2aWR1YWwgTFNQcyB3aXRoIHRoZSBzdGF0ZSBvZiB0aGUgY29ycmVzcG9u ZGluZyBSU1ZQLVRFDQogc2lnbmFsaW5nIGFkamFjZW5jeS48L2k+4oCdIChjb3BpZWQgZnJvbSB0 aGUgZHJhZnQpLiBTaW5jZSBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgeW91IHJlYWxseSBzaG91 bGRu4oCZdCBkbyB0aGF0LCBJ4oCZbSBpbnRlcmVzdGVkIGhvdyB5b3UgY2FuIGZ1bGZpbGwgYWJv dmUgbWVudGlvbmVkIHByaW5jaXBsZXMgd2l0aG91dCBpdC4gVG8gZ2l2ZSBhbiBleGFtcGxlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQpQcmluY2lwbGUgMjog4oCcQ29tcGxldGVseSBlbGltaW5hdGUgdGhlIHJl bGlhbmNlIG9uIHJlZnJlc2ggdGltZW91dHMgZm9yIHN0YWxlIHN0YXRl4oCdPC9zcGFuPjwvaT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiB0aGUgZHJhZnQgeW91IGFzc3Vt ZSB0aGF0IHN0YWxlIHN0YXRlIHdpbGwgYmUgcmVtb3ZlZCB0aGFua3MgdG86IGEpIHJlbGlhYmxl IFRlYXIvRXJyIG1lc3NhZ2VzIGRlbGl2ZXJ5IGFuZCBiKSByZW1vdmluZyBvZiBsc3Agc3RhdGUg YWZ0ZXIgYWRqYWNlbmN5DQogbG9zcy4gU2luY2UgYikgZG9lcyBub3Qgd29yayBpbiB0cmFuc3Bv cnQsIGhvdyBjYW4geW91IGNvdmVyIHNjZW5hcmlvcyBpbnZvbHZpbmcgYSByZWJvb3Qgb2YgYSBS U1ZQIHNwZWFrZXIgd2hpbGUgdGhlIHNlcnZpY2UgaXMgdG9ybiBkb3duIGUuZy4gYnkgUGF0aFRl YXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhd2VsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlZpc2hudSBQYXZhbiBCZWVyYW08YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDI2 LCAyMDE1IDM6NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IExvYSBBbmRlcnNzb248YnI+DQo8Yj5DYzo8 L2I+IHRlYXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUZWFzXSBSU1ZQIFRF IFNjYWxhYmlsaXR5IC0gUmVjb21tZW5kYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+TG9hLCBIaSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmtzIGZvciBw b2ludGluZyBpdCBvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+WWVzLCBub3QgcmVmZXJlbmNpbmcvbWVu dGlvbmluZyBSRkMgNTQzOSB3YXMgYSBtaXN0YWtlIGFuZCB0aGF0IHdvdWxkIGJlIHJlY3RpZmll ZCBpbiB0aGUgbmV4dCB2ZXJzaW9uLiAoQnV0IEkgZGlkIG1lbnRpb24gUkZDNTQzOSBpbiB0aGlz IG1vcm5pbmcncyBwcmVzZW50YXRpb24gOikpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJvdGggUkZDMjk2 MSBhbmQgUkZDNTQzOSBkbyB0YWxrIGFib3V0IGhhdmluZyBhIGxhcmdlIHJlZnJlc2ggaW50ZXJ2 YWwgYXMgYSBtZWFucyBvZiByZWR1Y2luZyB0aGUgcmF0ZSBvZiBtZXNzYWdlcyB0aGF0IHRoZSBj b250cm9sLXBsYW5lIGhhcyB0byBwcm9jZXNzLCBidXQgYWxzbyB3YXJuIGFib3V0IHRoZSBsb3Nz IG9mIGZ1bmN0aW9uYWxpdHkgYXNzb2NpYXRlZA0KIHdpdGggZG9pbmcgc28uICZsdDtkcmFmdC1i ZWVyYW0tbXBscy1yc3ZwLXRlLXNjYWxpbmcmZ3Q7IGJyaW5ncyBiYWNrIHRoZSBub3Rpb24gb2Yg cmVmcmVzaCBpbmRlcGVuZGVudCBSU1ZQLCBidXQgYWxzbyBpbmNsdWRlcyByZWNvbW1lbmRhdGlv bnMgdGhhdCB3b3VsZCBtYWtlIHN1cmUgdGhhdCB0aGVyZSBpcyBubyBsb3NzIG9mIGZ1bmN0aW9u YWxpdHkgd2hlbiBhIGxhcmdlIHJlZnJlc2ggaW50ZXJ2YWwgaXMgdXNlZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LVBhdmFuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDM6MzEgUE0sIExvYSBBbmRlcnNzb24gJmx0OzxhIGhy ZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhdmFuLDxicj4NCjxi cj4NClRoZSBNUExTIHdnIGRpZCAmcXVvdDtBbiBBbmFseXNpcyBvZiBTY2FsaW5nIElzc3VlcyBp biBNUExTLVRFIENvcmUgTmV0d29ya3MmcXVvdDs8YnI+DQpSRkMgNTQzOS4gVGhpcyBSRkMgaXMg bm90IG1lbnRpb25lZCBpbiBkcmFmdC1iZWVyYW0tbXBscy1yc3ZwLTxicj4NCnRlLXNjYWxpbmcu IFRoZSB0b3BpY3Mgc2VlbXMgY2xvc2UgZW5vdWdoIHRvIG1ha2Ugd29ydGggbG9vayBhdCB0aGF0 PGJyPg0KZG9jdW1lbnQuPGJyPg0KPGJyPg0KL0xvYTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAyMDE1 LTAzLTI2IDE0OjA5LCBWaXNobnUgUGF2YW4gQmVlcmFtIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlZXJhbS1tcGxzLXJzdnAtdGUtc2NhbGluZy0wMSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWVyYW0tbXBs cy1yc3ZwLXRlLXNjYWxpbmctMDE8L2E+PGJyPg0KPGJyPg0KRm9sa3MsIEhpITxicj4NCjxicj4N CiZsdDtkcmFmdC1iZWVyYW0tbXBscy1yc3ZwLXRlLXNjYWxpbmcmZ3Q7IHdhcyBwcmVzZW50ZWQg ZWFybGllciB0b2RheSBpbiB0aGU8YnI+DQpURUFTIFdHIHNlc3Npb24uIFRoZXJlIHdhc24ndCBz dWZmaWNpZW50IHRpbWUgdG8gdGFrZSBpbiBxdWVzdGlvbnMgYXQ8YnI+DQp0aGUgZW5kIG9mIHRo ZSBwcmVzZW50YXRpb24gKGFwb2xvZ2l6ZSBmb3IgdGhhdCkuIFNvLCBJJ20gb3BlbmluZyB1cDxi cj4NCnRoaXMgdGhyZWFkIHRvIG1ha2Ugc3VyZSB0aGF0IGFsbCB0aG9zZSBxdWVzdGlvbnMgZ2V0 IGFuc3dlcmVkLjxicj4NCjxicj4NCkEgZmV3IHBvaW50cyB0byBub3RlOjxicj4NCjxicj4NCjEu IFRoZXNlIHJlY29tbWVuZGF0aW9ucyB3ZXJlIHB1dCB0b2dldGhlciBmb3IgY2F0ZXJpbmcgdG8g Y3VycmVudCBNUExTPGJyPg0KUlNWUC1URSBTY2FsYWJpbGl0eSBuZWVkcy4gQnV0IHNpbmNlIG1v c3Qgb2YgdGhlbSBoYXZlIGdlbmVyaWM8YnI+DQphcHBsaWNhYmlsaXR5LCB0aGlzIGRyYWZ0IGlz IGJlaW5nIGRpc2N1c3NlZCBpbiBURUFTLjxicj4NCjxicj4NCjIuIFRoZXJlIGFyZSAzIHVuZGVy bHlpbmcgcHJpbmNpcGxlcyBkcml2aW5nIHRoZXNlIHJlY29tbWVuZGF0aW9uczxicj4NCi0gQ29t cGxldGVseSBlbGltaW5hdGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2hlcyBmb3Igc3RhdGUgc3lu Yy48YnI+DQotIENvbXBsZXRlbHkgZWxpbWluYXRlIHRoZSByZWxpYW5jZSBvbiByZWZyZXNoIHRp bWVvdXRzIGZvciBzdGFsZSBzdGF0ZTxicj4NCmNsZWFudXAuPGJyPg0KLSBJbXBsZW1lbnQgcGVy LXBlZXIgZmxvdyBjb250cm9sLjxicj4NCjxicj4NCjMuIFRoaXMgaXMgbm90IGEgdGhlb3JldGlj YWwgZXhlcmNpc2UuIFdlIGhhdmUgYW4gaW1wbGVtZW50YXRpb24gdGhhdDxicj4NCnJlbGlnaW91 c2x5IGFkb3B0cyB0aGVzZSByZWNvbW1lbmRhdGlvbnMgLS0gYW5kIHRoZSBzYXZpbmdzIGluIHRl cm1zIG9mPGJyPg0KcHJvY2Vzc2luZyBjeWNsZXMgZm9yIHRoZSBjb250cm9sLXBsYW5lIChhcyBh IHJlc3VsdCBvZiB0aGUgc2lnbmlmaWNhbnQ8YnI+DQpyZWR1Y3Rpb24gaW4gSS9PIG92ZXJoZWFk KSBpcyBxdWl0ZSBzaWduaWZpY2FudC48YnI+DQo8YnI+DQpQbGVhc2UgZG8gZ2l2ZSB0aGVzZSBy ZWNvbW1lbmRhdGlvbnMgc29tZSBzZXJpb3VzIGNvbnNpZGVyYXRpb24gYW5kIGxldDxicj4NCnVz IGtub3cgeW91ciBxdWVzdGlvbnMvY29tbWVudHMuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQot UGF2YW48YnI+DQoob24gYmVoYWxmIG9mIHRoZSBhdXRob3JzKTxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUZWFzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpUZWFzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VGVhc0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RlYXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RlYXM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9Imhv ZW56YiI+LS0gPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPkxv YSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFp bHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWwwMS5o dWF3ZWkuY29tPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5TZW5pb3IgTVBM UyBFeHBlcnQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRv OmxvYUBwaS5udSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQHBpLm51PC9hPjwvc3Bhbj48YnI+DQo8 c3BhbiBjbGFzcz0iaG9lbnpiIj5IdWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSZuYnNw OyAmbmJzcDsgJm5ic3A7cGhvbmU6IDxhIGhyZWY9InRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjEl MjA2NCIgdGFyZ2V0PSJfYmxhbmsiPg0KJiM0Mzs0NiA3MzkgODEgMjEgNjQ8L2E+PC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0fe4c449812b4174b42aacbdcf10a8a5MUCSEX13Badvaopticalcom_-- From nobody Tue Mar 31 18:37:55 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0221D1A1B7A for ; Tue, 31 Mar 2015 18:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-7dB_bGo6y9 for ; Tue, 31 Mar 2015 18:37:52 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591541A1B28 for ; Tue, 31 Mar 2015 18:37:52 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-70-551ae9a82c56 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 73.3E.17241.8A9EA155; Tue, 31 Mar 2015 20:38:33 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0210.002; Tue, 31 Mar 2015 21:37:50 -0400 From: Xufeng Liu To: Hariharan Ananthakrishnan , "teas@ietf.org" Thread-Topic: draft-liu-teas-yang-te-topo-01 Thread-Index: AQHQZ/yJfpBR4LiHZUG+WbC1qvazA503aMLA Date: Wed, 1 Apr 2015 01:37:49 +0000 Message-ID: References: <36A274A2-7611-4EF0-B68E-67ED06569696@packetdesign.com> In-Reply-To: <36A274A2-7611-4EF0-B68E-67ED06569696@packetdesign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_AAB1CC9C17CBA440BDFA169056B93B9EB9888Eeusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPgu7Kl1KhBvNvCVnsunuYxaL1xw4W ByaPJUt+MnlMaN7JFsAUxWWTkpqTWZZapG+XwJUxa8lH9oItXhWX9mxga2Bc49HFyMkhIWAi 8erTHVYIW0ziwr31bF2MXBxCAkcZJZ61/2CHcJYzSiw9+YC5i5GDg01AS+LyU0eQBhGBCIk/ 92azgNjCAtoSq990sUDEdSRmtO5lhrCNJM6vew1mswioSPQc2wJWwyvgLXFy0WVGEFtIwFni 1ctDYDangIvE+pcrwQ5iBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/qAeUJD7+ ns8OUZ8vMeXPHHaIXYISJ2c+YZnAKDILyahZSMpmISmbBfQls4CmxPpd+hAlihJTuh+yQ9ga Eq1z5rIjiy9gZF/FyFFanFqWm25kuIkRGDvHJNgcdzAu+GR5iFGAg1GJh1ehXzJUiDWxrLgy 9xCjNAeLkjhv2ZWDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY9wrsSrfauTjdra7656WF 0iK5i59fLHy4jfWR3EUOYeeeRz9VbA8VyyTN/qoRaTPxWplipP2B9z3PGPR2B/Qkr7C/VtaQ /GB7Nl+0i6JpEYfpPzZGm2cJT3evFFX6e91aro9NvMio7frXBW1FPlJJa7c+W2/3P/Ae2yqd 7DPigoeFpKeZ5+QpsRRnJBpqMRcVJwIA9D45z34CAAA= Archived-At: Subject: Re: [Teas] draft-liu-teas-yang-te-topo-01 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 01:37:54 -0000 --_000_AAB1CC9C17CBA440BDFA169056B93B9EB9888Eeusaamb107ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFyaSwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoZXNlIGlzc3VlcyB3aWxsIGJl IGFkZHJlc3NlZCwgYW1vbmcgb3RoZXJzLg0KDQotIFh1ZmVuZw0KDQpGcm9tOiBUZWFzIFttYWls dG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFyaWhhcmFuIEFuYW50aGFr cmlzaG5hbg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IDM6MzkgUE0NClRvOiB0ZWFz QGlldGYub3JnDQpTdWJqZWN0OiBbVGVhc10gZHJhZnQtbGl1LXRlYXMteWFuZy10ZS10b3BvLTAx DQoNCkhpIEF1dGhvcnMsDQoNCkNvdXBsZSBvZiBjb21tZW50czoNCg0KWzFdIOKAnGltcG9ydCB0 ZWTigJ06IEl0IHdvdWxkIGJlIGdvb2QgdG8gcHJvdmlkZSByZWZlcmVuY2UgZnJvbSB3aGVyZSDi gJh0ZWTigJkgbW9kdWxlIGlzIGJlaW5nIHBpY2tlZCB1cCBmcm9tIChkcmFmdC1jbGVtbS1pMnJz LXlhbmctbDMtdG9wbyA/KQ0KWzJdIEltcG9ydGluZyDigJh0ZWTigJkgaW4gdGUtdG9wbyBtb2R1 bGUgd2lsbCBtYWtlIHRoaXMgbW9kdWxlIOKAmW5vdOKAmSBnZW5lcmljLCBzaW5jZSB0ZWQgaGFz IGlwdjQvaXB2NiByZWZlcmVuY2VzLiBTaW1pbGFyIGlzc3VlcyB3aXRoIHVzYWdlIG9mIGluZXQ6 aXB2NC1hZGRyZXMgYW5kIGluZXQ6aXB2Ni1hZGRyZXNzLg0KWzNdIEkgYW0gbm90IHN1cmUgaGF2 aW5nICdpcy1hYnN0cmFjdCcgaW4gbm9kZSBhbmQgbGluayBoZWxwcyBhcyB0ZS10b3BvbG9neSBp dHNlbGYgaXMgc3VwcG9zZSB0byBiZSBnZW5lcmljIChvciBhYnN0cmFjdCkuIElmIHRoZXJlIGlz IHJlYWxseSBhIHVzZS1jYXNlIHRoZW4gd2Ugc2hvdWxkIG1vdmUgdGhpcyB0byDigJxnZW5lcmlj IG5ldHdvcmstdG9wb2xvZ3nigJ0gKGRyYWZ0LWNsZW1tLWkycnMteWFuZy1uZXR3b3JrLXRvcG8p LCBhc3N1bWluZyB0aGlzIHRvcG9sb2d5IGlzIGdvaW5nIHRvIGJlIGRlcml2ZWQgZnJvbSBkcmFm dC1jbGVtbS1pMnJzLXlhbmctbmV0d29yay10b3BvLg0KDQpUaGFua3MsDQotIEhhcmkNCg== --_000_AAB1CC9C17CBA440BDFA169056B93B9EB9888Eeusaamb107ericsso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEhhcmksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MgZm9yIHRoZSBjb21tZW50cy4gVGhlc2UgaXNzdWVzIHdpbGwgYmUgYWRkcmVzc2VkLCBh bW9uZyBvdGhlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LSBYdWZlbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUZWFzIFttYWlsdG86dGVhcy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IYXJpaGFyYW4gQW5hbnRoYWtyaXNo bmFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjM5IFBNPGJy Pg0KPGI+VG86PC9iPiB0ZWFzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUZWFzXSBk cmFmdC1saXUtdGVhcy15YW5nLXRlLXRvcG8tMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkgQXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkNvdXBsZSBvZiBjb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlsxXSDigJxpbXBvcnQgdGVk4oCdOiBJdCB3b3VsZCBiZSBnb29kIHRvIHByb3Zp ZGUgcmVmZXJlbmNlIGZyb20gd2hlcmUg4oCYdGVk4oCZIG1vZHVsZSBpcyBiZWluZyBwaWNrZWQg dXAgZnJvbSAoZHJhZnQtY2xlbW0taTJycy15YW5nLWwzLXRvcG8gPyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+WzJdIEltcG9ydGluZyDigJh0ZWTigJkgaW4gdGUt dG9wbyBtb2R1bGUgd2lsbCBtYWtlIHRoaXMgbW9kdWxlIOKAmW5vdOKAmSBnZW5lcmljLCBzaW5j ZSB0ZWQgaGFzIGlwdjQvaXB2NiByZWZlcmVuY2VzLiBTaW1pbGFyIGlzc3VlcyB3aXRoIHVzYWdl IG9mIGluZXQ6aXB2NC1hZGRyZXMgYW5kDQogaW5ldDppcHY2LWFkZHJlc3MuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlszXSBJIGFtIG5vdCBzdXJlIGhhdmluZyAn aXMtYWJzdHJhY3QnIGluIG5vZGUgYW5kIGxpbmsgaGVscHMgYXMgdGUtdG9wb2xvZ3kgaXRzZWxm IGlzIHN1cHBvc2UgdG8gYmUgZ2VuZXJpYyAob3IgYWJzdHJhY3QpLiBJZiB0aGVyZSBpcyByZWFs bHkgYSB1c2UtY2FzZSB0aGVuDQogd2Ugc2hvdWxkIG1vdmUgdGhpcyB0byDigJxnZW5lcmljIG5l dHdvcmstdG9wb2xvZ3nigJ0gKGRyYWZ0LWNsZW1tLWkycnMteWFuZy1uZXR3b3JrLXRvcG8pLCBh c3N1bWluZyB0aGlzIHRvcG9sb2d5IGlzIGdvaW5nIHRvIGJlIGRlcml2ZWQgZnJvbSBkcmFmdC1j bGVtbS1pMnJzLXlhbmctbmV0d29yay10b3BvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4t IEhhcmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AAB1CC9C17CBA440BDFA169056B93B9EB9888Eeusaamb107ericsso_-- From nobody Tue Mar 31 20:01:30 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3C71A1EF7 for ; Tue, 31 Mar 2015 20:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63b84Nl7EwKR for ; Tue, 31 Mar 2015 20:01:28 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E61D1A1EEA for ; Tue, 31 Mar 2015 20:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1873; q=dns/txt; s=iport; t=1427857289; x=1429066889; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zi8BJpbcCH2qrZLnJwoI6gt4JASstp6DOEO6DDZqq3M=; b=SDHstcrZUIIzEQblql85PoFoDVlQEnll/XezMzwQL2BeObTnfFP0wYuR nJhHyZ/bj7wGHwwVJuRUS3q01c+yIFRw76+JK9eZn4Z/7vCeGyA+rjylv 1fEZiTiQ6DcYY9JxGIvXa9hUWY7EFFQNAgGiMGIMLKQLmllyhGJLxEM1E E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASBQAmXxtV/4ENJK1cgwZSXAXGBYVzAoFCTAEBAQEBAX2EFQEBBDo6BRACAQgOKBAyJQIEAQ0FiC8NzXwBAQEBAQEBAQEBAQEBAQEBAQEaiymEFhEBUAeELQWQYoNyhgOBHTqCeIwkg0gig25vAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="137199363" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 01 Apr 2015 03:01:28 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t3131Rsw010864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 03:01:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.61]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 22:01:27 -0500 From: "Tarek Saad (tsaad)" To: Lou Berger , Xufeng Liu , "Igor Bryski" , Vishnu Pavan Beeram Thread-Topic: Regarding IPR on draft-liu-teas-yang-te-topo Thread-Index: AQHQawjQq3l3sMxi/ka6DbiB/Wm5q503iv0A Date: Wed, 1 Apr 2015 03:01:26 +0000 Message-ID: References: <55197D63.4050803@labn.net> In-Reply-To: <55197D63.4050803@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.24.193.58] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 03:01:29 -0000 No, I'm not aware of any IPR that applies to this draft. Regards, Tarek On 2015-03-30, 12:44 PM, "Lou Berger" wrote: >Authors, Contributors, (TEAS) > >As part of the preparation for polling for WG document adoption: > >Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details)? > >If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > >If you answer no, please provide any additional details you think > appropriate. > >If you are listed as a document author or contributor please answer the >above by responding to this email regardless of whether or not you are >aware of any relevant IPR. This document will not advance to the next >stage until a response has been received from each author and listed >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S >TO LINES. > >If you are on the WG email list or attend WG meetings but are not listed >as an author or contributor, we remind you of your obligations under >the IETF IPR rules which encourages you to notify the IETF if you are >aware of IPR of others on an IETF contribution, or to refrain from >participating in any contribution or discussion related to your >undisclosed IPR. For more information, please see the RFCs listed above >and >http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >Thank you, >TEAS WG Chairs > >PS Please include all listed in the headers of this message in your >response. > From nobody Tue Mar 31 21:13:23 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C6E1A8758 for ; Tue, 31 Mar 2015 21:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqr21CV51XRw for ; Tue, 31 Mar 2015 21:13:20 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF7D1A875D for ; Tue, 31 Mar 2015 21:13:20 -0700 (PDT) Received: by qcrf4 with SMTP id f4so19414228qcr.0 for ; Tue, 31 Mar 2015 21:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6sI1LOKU7+lIu2sJqoNjD+F8m0AIiSt+RoE88Ndug1U=; b=tABcLKyYVfw0GwlnTTdSA63byDZXbNoAdz3gYpDEaLWLYFcxP69VYPMwTHIa2Bq75s Nhpu5PUhETSGQKNbBVwE74UkBMBBdP0a6E5r8G04vpeVyrmUFBYU2SynMaKbOcXt3bZA FduWfcqA6bxm5GH5xFc7FFkhRvgkmDR9kSXXLetkVfkcm1RFBH2YinF6q6Kn69ZRZyBj 1RdKO+XDZiP76DgX7LnCGgqIvyhlNn3G/mBhuBbhXkK3DapilNdfEUyA4WJtC94aRnpb fE8zVIUFvqf2AuQhvsGtyJ/vOkdzCxZ8krfvsuoVesJ5gN8UOICoZdYGxnhfK3F8zYK7 mMPQ== MIME-Version: 1.0 X-Received: by 10.140.28.203 with SMTP id 69mr52481132qgz.5.1427861599447; Tue, 31 Mar 2015 21:13:19 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Tue, 31 Mar 2015 21:13:19 -0700 (PDT) In-Reply-To: <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> Date: Wed, 1 Apr 2015 00:13:19 -0400 Message-ID: From: Vishnu Pavan Beeram To: =?UTF-8?Q?Pawe=C5=82_Brzozowski?= Content-Type: multipart/alternative; boundary=001a1139bcd86c71a90512a1ef55 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 04:13:23 -0000 --001a1139bcd86c71a90512a1ef55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pawel, Hi! Thanks for the response. Please see inline. Regards, -Pavan On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski < PBrzozowski@advaoptical.com> wrote: > Pavan, > > > > I think this is great work and applies well to the packet networks. Imho > the draft should be augmented to reflect to what is the degree of > applicability to transport networks. > VPB <=3D> As mentioned earlier, the recommendations in the draft were put together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the applicability of these recommendations to non-psc GMPLS LSPs at all in the initial revision -- we simply didn't care :). But since it was pointed out to us that most of these recommendations have generic applicability, I agree that it would be useful to clarify the degree of applicability to such networks in the next revision of the draft. At a high-level, everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert for Paths) and Section 2.6 (there are different ways of checking data-plane readiness for non psc LSPs) should have generic applicability. > > You said: > > > > *=E2=80=9CThere are 3 underlying principles driving these recommendations= :* > > > > > *- Completely eliminate the reliance on refreshes for state sync. - > Completely eliminate the reliance on refresh timeouts for stale state > cleanup. - Implement per-peer flow control.=E2=80=9D* > > > > In order to achieve these principles you recommend =E2=80=9C*Implementing > coupling the state of individual LSPs with the state of the corresponding > RSVP-TE signaling adjacency.*=E2=80=9D (copied from the draft). Since in = the > transport network you really shouldn=E2=80=99t do that, I=E2=80=99m inter= ested how you can > fulfill above mentioned principles without it. > VPB<=3D> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those). To give an example: > > > * Principle 2: =E2=80=9CCompletely eliminate the reliance on refresh time= outs for > stale state=E2=80=9D* > > > > In the draft you assume that stale state will be removed thanks to: a) > reliable Tear/Err messages delivery and b) removing of lsp state after > adjacency loss. Since b) does not work in transport, how can you cover > scenarios involving a reboot of a RSVP speaker while the service is torn > down e.g. by PathTear? > > > VPB <=3D> Again, please elaborate why you cannot remove LSP after adjacency loss if you are using standard GMPLS RSVP-TE. > Thanks, > > Pawel > > > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* Thursday, March 26, 2015 3:56 PM > *To:* Loa Andersson > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Loa, Hi! > > Thanks for pointing it out. > > Yes, not referencing/mentioning RFC 5439 was a mistake and that would be > rectified in the next version. (But I did mention RFC5439 in this morning= 's > presentation :)). > > Both RFC2961 and RFC5439 do talk about having a large refresh interval as > a means of reducing the rate of messages that the control-plane has to > process, but also warn about the loss of functionality associated with > doing so. brings back the notion of > refresh independent RSVP, but also includes recommendations that would ma= ke > sure that there is no loss of functionality when a large refresh interval > is used. > > Regards, > > -Pavan > > > > > > On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson wrote: > > Pavan, > > The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks" > RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp- > te-scaling. The topics seems close enough to make worth look at that > document. > > /Loa > > > > > > On 2015-03-26 14:09, Vishnu Pavan Beeram wrote: > > https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 > > Folks, Hi! > > was presented earlier today in the > TEAS WG session. There wasn't sufficient time to take in questions at > the end of the presentation (apologize for that). So, I'm opening up > this thread to make sure that all those questions get answered. > > A few points to note: > > 1. These recommendations were put together for catering to current MPLS > RSVP-TE Scalability needs. But since most of them have generic > applicability, this draft is being discussed in TEAS. > > 2. There are 3 underlying principles driving these recommendations > - Completely eliminate the reliance on refreshes for state sync. > - Completely eliminate the reliance on refresh timeouts for stale state > cleanup. > - Implement per-peer flow control. > > 3. This is not a theoretical exercise. We have an implementation that > religiously adopts these recommendations -- and the savings in terms of > processing cycles for the control-plane (as a result of the significant > reduction in I/O overhead) is quite significant. > > Please do give these recommendations some serious consideration and let > us know your questions/comments. > > Regards, > -Pavan > (on behalf of the authors) > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > --001a1139bcd86c71a90512a1ef55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pawel, Hi!

Thanks for the resp= onse. Please see inline.

Regards,
-Pavan

On Tue= , Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski <PBrzozowski@ad= vaoptical.com> wrote:

Pavan,

=C2=A0

I think th= is is great work and applies well to the packet networks. Imho the draft sh= ould be augmented to reflect to what is the degree of applicability to transport networks.


<= div>VPB <=3D> As mentioned earlier, the recommendations in the draft = were put together to cater to MPLS RSVP-TE LSPs. The authors didn't con= sider the applicability of these recommendations to non-psc GMPLS LSPs at a= ll in the initial revision -- we simply didn't care :). But since it wa= s pointed out to us that most of these recommendations have generic applica= bility, I agree that it would be useful to clarify the degree of applicabil= ity to such networks in the next revision of the draft. At a high-level, ev= erything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert for= Paths) and Section 2.6 (there are different ways of checking data-plane re= adiness for non psc LSPs) should have generic applicability.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2= =A0

You said:<= u>

=C2=A0

=E2=80=9CThere are 3 underly= ing principles driving these recommendations:

- Completel= y eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
 - Implement per-peer flow control.=E2=80=9D

=C2= =A0

In order t= o achieve these principles you recommend =E2=80=9CImplementing coupling = the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency.=E2=80=9D (copied from the draft). Since in the tr= ansport network you really shouldn=E2=80=99t do that, I=E2=80=99m intereste= d how you can fulfill above mentioned principles without it.


VPB<=3D> If the elements in= this transport network of yours are running standard GMPLS Control-Plane (= not some GMPLS based proprietary version), please elaborate why you can'= ;t couple the state of individual LSPs with the state of the corresponding = RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state= when the refresh times out, then it should also be able to cleanup the LSP= -state when the hello-adjacency goes down. I understand that there are prop= rietary implementations that do not cleanup the LSP-state when the refresh = times out -- those proprietary implementations might need some additional p= rocedures (this draft will not furnish those).

To give an examp= le:


Principle 2: =E2=80=9CCompletely eliminate the reliance on refresh timeouts= for stale state=E2=80=9D

=C2= =A0

In the dra= ft you assume that stale state will be removed thanks to: a) reliable Tear/= Err messages delivery and b) removing of lsp state after adjacency loss. Since b) does not work in transport, how can you cover scenarios inv= olving a reboot of a RSVP speaker while the service is torn down e.g. by Pa= thTear?

=C2= =A0


VPB <=3D> = Again, please elaborate why you cannot remove LSP after adjacency loss if y= ou are using standard GMPLS RSVP-TE.=C2=A0
=C2=A0

Thanks,=

Pawel

=C2= =A0

=C2= =A0

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: teas@ietf.org=
Subject: Re: [Teas] RSVP TE Scalability - Recommendations<= /u>

=C2=A0

Loa, Hi!

Thanks for pointing i= t out.

Yes, not referencing/= mentioning RFC 5439 was a mistake and that would be rectified in the next v= ersion. (But I did mention RFC5439 in this morning's presentation :)).<= u>

Both RFC2961 and RFC5= 439 do talk about having a large refresh interval as a means of reducing th= e rate of messages that the control-plane has to process, but also warn abo= ut the loss of functionality associated with doing so. <draft-beeram-mpls-rsvp-te-scaling> brings back the n= otion of refresh independent RSVP, but also includes recommendations that w= ould make sure that there is no loss of functionality when a large refresh = interval is used.

Regards,

-Pavan

=C2=A0

=C2=A0

On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrote:

Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Network= s"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa





On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:

h= ttps://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented earlier today in th= e
TEAS WG session. There wasn't sufficient time to take in questions at the end of the presentation (apologize for that). So, I'm opening up this thread to make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let
us know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)




_____________________= __________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0


--001a1139bcd86c71a90512a1ef55-- From nobody Tue Mar 31 21:14:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4D01A8761 for ; Tue, 31 Mar 2015 21:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlAPwtNzUEb4 for ; Tue, 31 Mar 2015 21:14:17 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9AC1A875E for ; Tue, 31 Mar 2015 21:14:16 -0700 (PDT) Received: by qgfa8 with SMTP id a8so33302409qgf.0 for ; Tue, 31 Mar 2015 21:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jHHDOBrOIhby5boeDd0OnMjmQ1Ooj6zqL6pxbpTB0cQ=; b=xLHqKXx2PqYbvekx9hDwHsFgmLwNqE6ZvASYn29XOQoSBCAieG04w+gzxiYKfZI1IJ 2aiofeV9xjI1l2aEEAzQ6E9kIW7pvVLWfsqrMkVO9/na4dJ91uGi2VmCG3N+TivRUyFk NVXkzt6ooI98Tz4P74UP3LeiXdB2tYPxz+zkcDaYKJKNfFo6Ff8fdP6ymsdgDjoHuax8 GGJiM0kWVAuJGxaYAgyboRNUk0w0kfa5444Sgtg8RLv6eZLuPPqi63BUrhJrLOij9qG6 HHLAiXFpEg1ZkibdxjEkicTEUBrIHCw0OhvAhS5x9KBADs4DLweffeQxJvg3fj6h7J7L XNFQ== MIME-Version: 1.0 X-Received: by 10.140.233.71 with SMTP id e68mr54883575qhc.56.1427861656101; Tue, 31 Mar 2015 21:14:16 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Tue, 31 Mar 2015 21:14:16 -0700 (PDT) In-Reply-To: <55197D63.4050803@labn.net> References: <55197D63.4050803@labn.net> Date: Wed, 1 Apr 2015 00:14:16 -0400 Message-ID: From: Vishnu Pavan Beeram To: Lou Berger Content-Type: multipart/alternative; boundary=001a113551aacce7760512a1f267 Archived-At: Cc: Himanshu Shah , Vishnu Pavan Beeram , Igor Bryski , TEAS WG , Xufeng Liu Subject: Re: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 04:14:19 -0000 --001a113551aacce7760512a1f267 Content-Type: text/plain; charset=UTF-8 No, I'm not aware of any IPR that applies to this draft. Regards, -Pavan On Mon, Mar 30, 2015 at 12:44 PM, Lou Berger wrote: > Authors, Contributors, (TEAS) > > As part of the preparation for polling for WG document adoption: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > TEAS WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a113551aacce7760512a1f267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, I'm not aware of any IPR that applies to= this draft.

Regards,
-Pavan

On Mon, Mar 30, 2015 at 12:44 PM= , Lou Berger <lberger@labn.net> wrote:
Authors, Contributors, (TEAS)

As part of the preparation for polling for WG document adoption:

Are you aware of any IPR that applies to draft identified above?

=C2=A0 Please state either:

=C2=A0 "No, I'm not aware of any IPR that applies to this draft&qu= ot;
=C2=A0 or
=C2=A0 "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

=C2=A0 "Yes, the IPR has been disclosed in compliance with IETF IPR ru= les"
=C2=A0 or
=C2=A0 "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
=C2=A0 appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR.=C2=A0 This document will not advance to the next=
stage until a response has been received from each author and listed
contributor.=C2=A0 NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE&= #39;S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/Int= ellectualProperty.

Thank you,
TEAS WG Chairs

PS Please include all listed in the headers of this message in your
response.

_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

--001a113551aacce7760512a1f267--