From nobody Wed Jun 4 06:01:33 2014 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33711A01D5 for ; Wed, 4 Jun 2014 06:01:28 -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 cFrMYUdHpWuc for ; Wed, 4 Jun 2014 06:01:24 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EF31A0225 for ; Wed, 4 Jun 2014 06:01:24 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id hn18so6233737igb.6 for ; Wed, 04 Jun 2014 06:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=c+JBtWDWF4ks0loPyuy+8ZWxzoYPxEmrhfATM/fMa+I=; b=Q/qfXXi9x1v3qgkz0Mer2fZA9rGUTJbFC7wHFjudWCryfDpQdAQ28ojPLBY0YQsWz8 HmkPhTI0fv4HEaVDy02Ijgq0IN9+NYkbtZ793Qq04+D9/VkZN8ff/LFYxiHUxRO+YOjm W9jaSydku/oKf1nU9z3mgfLsQwHnjvBs9CzemUg8ffyrGRcFxvQcgUSYb0ku+FcS/M1C gBLS4W6Kg68TZHiEtLKqqGY0JUOfLKuUxEHAYvhXjtz8LtGPmhf1TJh+y3UBdHxCjb2g sK9mFDSWdgWpmPDxO9X1yhBTOH17AArwH03M1Qr38c9llKZ6rKOw4vkuBP721c1WRNt+ G4fg== X-Received: by 10.50.21.104 with SMTP id u8mr6805645ige.1.1401886878030; Wed, 04 Jun 2014 06:01:18 -0700 (PDT) Received: from [192.168.0.100] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id y7sm44889500igl.13.2014.06.04.06.01.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 06:01:17 -0700 (PDT) Message-ID: <538F1897.1090702@gmail.com> Date: Wed, 04 Jun 2014 09:01:11 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ancp/dJ8eL7j5090rvS-_h02htyKzrRw Subject: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:01:29 -0000 Doing my AUTH48 review for draft-ietf-ancp-mc-extensions-16, I noticed an inconsistency in treatment between three different cases where the AN is assigned a value of multicast bandwidth that is lower than the AN has already committed to a given subscriber. The question to the Working Group is whether: (a) no change is needed; or (b) local policy should determine whether established connections should be taken down to meet bandwidth limits set by the NAS in all cases; or (c) established connections should never be taken down until terminated by the subscriber (no provision for local policy in any case). The context in each instance is that the NAS has sent a multicast bandwidth allocation to the AN. If the AN does not conform to that allocation, the NAS does not have a correct view of the amount of bandwidth available for admission control (e.g., of unicast services) at the NAS itself. That should probably be fixed independently of the question stated above. And, of course, the over-commitment at the AN means that less bandwidth is available for services admitted at the NAS. Here are the three cases in question: Case 1: bandwidth assigned by Port Management message ===================================================== Receiver behaviour is described in Section 4.2.2. Note the provision for local policy in the quoted text: "If the Port Management message contains a Bandwidth-Allocation TLV, the AN adopts this as the current value of its total multicast bandwidth limit for the target port. If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth- Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV." Case 2: bandwidth assigned by Bandwidth Transfer message ======================================================== AN behaviour as receiver is described in Section 4.6.2.2. There is no provision for local policy: "If as the result of the procedures just described the AN determines that it has over-committed multicast bandwidth, it MUST NOT terminate any currently-active programs, but MUST NOT honour any more "join" requests until it is possible to do so within the limit set by its current value of delegated bandwidth." Case 3: bandwidth assigned by Delegated Bandwidth Query Response message ======================================================================== AN behaviour as receiver is described in Section 4.8.2.2. There is no provision for local policy: "... If the AN has currently committed more than this amount to active programs, it MUST NOT cease replicating the flows concerned, but MUST NOT honour any more Join requests until possible to do so within the new limit." Tom Taylor From nobody Wed Jun 4 07:19:09 2014 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DC01A0274 for ; Wed, 4 Jun 2014 07:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 5-DiJb2i9VPb for ; Wed, 4 Jun 2014 07:19:06 -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 9C5691A01F6 for ; Wed, 4 Jun 2014 07:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5339; q=dns/txt; s=iport; t=1401891540; x=1403101140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oluPGXJMklELolTUwtZuTvI4P5Hnm+w/ioIVlHcgPgk=; b=JIDFKSxxyrI7doMqitfRxZR9MfKVybAd/ezpY05ve7bqm5ATuZdaqd6F JTqqGJE0UgODpZrkJVf9T1WA135hjJMsLtKhgd8oSmvyYUN6hpffvIviL CVgWdJfddXTNYJivgWkltCiK+sBq3w2DMA7dAjZi2CBBHCxQ7/MaQglQ8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAC8qj1OtJV2a/2dsb2JhbABZgwdSWLs7hzkBgQsWdIIlAQEBAwEBAQFrCwULAgEIRiEGCyUCBAoEBYguAwkIDctxDYYIEwSMPIE/JDMHgyuBFQSWCYIQgXqNQoV3gzhsgQJB X-IronPort-AV: E=Sophos;i="4.98,973,1392163200"; d="scan'208";a="50125056" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 04 Jun 2014 14:19:00 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s54EIxpW030293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 14:19:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 09:18:59 -0500 From: "Francois Le Faucheur (flefauch)" To: Tom Taylor Thread-Topic: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 Thread-Index: AQHPf/Uh5lZdhsetkEy4XK4IlwubRJthU8AA Date: Wed, 4 Jun 2014 14:18:59 +0000 Message-ID: <8A31814E-05BC-41F2-8484-3977A9CDE122@cisco.com> References: <538F1897.1090702@gmail.com> In-Reply-To: <538F1897.1090702@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4B6CFE62F4278E458CC784CC0BAF4024@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ancp/l96LMjKWQUQ5qgUXLGkMZsL-Jig Cc: "ancp@ietf.org" Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 14:19:08 -0000 Tom and all, In the considered scenario where: * the AN receives a new Bandwidth-Allocation TLV * the AN has already committed more multicast bandwidth I would suggest that the AN first attempts to increase the delegated bandwi= dth by sending to the NAS a Bandwidth Reallocation Request message. This is= the behavior already specified (1) for the AN in the situation where the d= elegated bandwidth has not been modified but there is a new multicast join = that would result in committing more bandwidth than delegated. Would you agree?=20 If this attempt does not result in obtaining sufficient bandwidth to avoid = any over-commitment, I would recommend retaining the behavior currently spe= cified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast streams in= order to bring bandwidth down to within the new limit, unless such action = is required by local policy.) and align the text of teh sections that are = inconsistent with that. Francois (1) section 6.2.5.2. : =93 When the AN receives a join request, it checks whether it has sufficient remaining uncommitted multicast bandwidth on the access line to accommodate the new multicast flow. If not, it MAY send a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message. The NAS MUST return a Bandwidth Transfer message indicating whether it has granted the request and, if so, the new amount of delegated bandwidth. " On 4 Jun 2014, at 15:01, Tom Taylor wrote: > Doing my AUTH48 review for draft-ietf-ancp-mc-extensions-16, I noticed an= inconsistency in treatment between three different cases where the AN is a= ssigned a value of multicast bandwidth that is lower than the AN has alread= y committed to a given subscriber. The question to the Working Group is whe= ther: > (a) no change is needed; or > (b) local policy should determine whether established connections should= be taken down to meet bandwidth limits set by the NAS in all cases; or > (c) established connections should never be taken down until terminated = by the subscriber (no provision for local policy in any case). >=20 > The context in each instance is that the NAS has sent a multicast bandwid= th allocation to the AN. If the AN does not conform to that allocation, the= NAS does not have a correct view of the amount of bandwidth available for = admission control (e.g., of unicast services) at the NAS itself. That shoul= d probably be fixed independently of the question stated above. And, of co= urse, the over-commitment at the AN means that less bandwidth is available = for services admitted at the NAS. >=20 > Here are the three cases in question: >=20 > Case 1: bandwidth assigned by Port Management message > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > Receiver behaviour is described in Section 4.2.2. Note the provision for = local policy in the quoted text: >=20 > "If the Port Management message contains a Bandwidth-Allocation TLV, > the AN adopts this as the current value of its total multicast > bandwidth limit for the target port. If the AN has already committed > multicast bandwidth exceeding the amount given in the Bandwidth- > Allocation TLV, the AN SHOULD NOT discontinue any multicast streams > in order to bring bandwidth down to within the new limit, unless such > action is required by local policy. However, the AN MUST NOT admit > new multicast streams that are subject to admission control until it > can do so within the limit specified by the Bandwidth-Allocation > TLV." >=20 > Case 2: bandwidth assigned by Bandwidth Transfer message > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > AN behaviour as receiver is described in Section 4.6.2.2. There is no pro= vision for local policy: >=20 > "If as the result of the procedures just described the AN determines > that it has over-committed multicast bandwidth, it MUST NOT terminate > any currently-active programs, but MUST NOT honour any more "join" > requests until it is possible to do so within the limit set by its > current value of delegated bandwidth." >=20 > Case 3: bandwidth assigned by Delegated Bandwidth Query Response message > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > AN behaviour as receiver is described in Section 4.8.2.2. There is no pro= vision for local policy: >=20 > "... If the AN has > currently committed more than this amount to active programs, it MUST > NOT cease replicating the flows concerned, but MUST NOT honour any > more Join requests until possible to do so within the new limit." >=20 >=20 > Tom Taylor >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From nobody Wed Jun 18 05:34:30 2014 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9792C1A01DE for ; Wed, 18 Jun 2014 05:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 xH64_2yfotki for ; Wed, 18 Jun 2014 05:34:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D3D1A0127 for ; Wed, 18 Jun 2014 05:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26148; q=dns/txt; s=iport; t=1403094865; x=1404304465; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7zzAStljnFanCtIbrnK3eP/qPGIkukV3ZvCM2HdBqjM=; b=g6ZZfYYVfguyQgzg8gFwCONpRjN3wWIvQ5MS7h1GKgsBY2/lpwfW9NJe o0iQ/xu51qriCIAhv7EI7WHSMvCWj0DEXb0U/DdeMRcM57YaQxDroHfFD nDMDHzEGe5XmhKSYNlAwG5QRcuQin0hR1xz48VrO+YDRESj5pTdEwUvwZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMIAAqHoVOtJA2F/2dsb2JhbABagkZHUlqCbKcoAQEBAQEBBQGRaQGHPgEZchZ1g3wHAQEBAwEBAQEgCkEQCwIBCBEDAQILHQMCAgIfBgsUCQgCBAEJCQiFQQeCXgMJCA2tDZhEDYY2EwSFYoZwgUwmIA0KAQaCcTaBFgSFXpBWghaPUYYAg0JsgQNB X-IronPort-AV: E=Sophos; i="5.01,499,1400025600"; d="scan'208,217"; a="54056378" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 18 Jun 2014 12:34:17 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5ICYHBd022361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 12:34:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.126]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 07:34:17 -0500 From: "Roberta Maglione (robmgl)" To: "ancp@ietf.org" , "Francois Le Faucheur (flefauch)" , "tom.taylor.stds@gmail.com" Thread-Topic: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 Thread-Index: AQHPiu+VV4iIhvcvPEW7FqcVPEZGd5t2y2iA Date: Wed, 18 Jun 2014 12:34:16 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59@xmb-rcd-x01.cisco.com> References: <538F1897.1090702@gmail.com> <8A31814E-05BC-41F2-8484-3977A9CDE122@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.50] Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ancp/nFubRm9BcvRIzAyM8mkcV-6JaII Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 12:34:28 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9tLCBGcmFuY29pcyBhbmQgQWxsLA0KU29ycnkgZm9yIG15IGxhdGUgcmVwbHksIGNvbW1lbnRz IGlubGluZS4NCg0KPkkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBBTiBmaXJzdCBhdHRlbXB0cyB0 byBpbmNyZWFzZSB0aGUgZGVsZWdhdGVkIGJhbmR3aWR0aCBieSBzZW5kaW5nIHRvIHRoZSBOQVMg YSA+QmFuZHdpZHRoIFJlYWxsb2NhdGlvbiA+UmVxdWVzdCBtZXNzYWdlLiBUaGlzIGlzIHRoZSBi ZWhhdmlvciBhbHJlYWR5IHNwZWNpZmllZCAoMSkgZm9yIHRoZSBBTiBpbiB0aGUgc2l0dWF0aW9u IHdoZXJlIHRoZSBkZWxlZ2F0ZWQgYmFuZHdpZHRoIGhhcyBub3QgYmVlbiA+bW9kaWZpZWQgYnV0 IHRoZXJlIGlzIGEgbmV3IG11bHRpY2FzdCBqb2luIHRoYXQgd291bGQgcmVzdWx0IGluIGNvbW1p dHRpbmcgbW9yZSBiYW5kd2lkdGggdGhhbiBkZWxlZ2F0ZWQuDQo+V291bGQgeW91IGFncmVlPw0K DQpJIGFncmVlIHdpdGggdGhpcyBhcHByb2FjaC4NCg0KPklmIHRoaXMgYXR0ZW1wdCBkb2VzIG5v dCByZXN1bHQgaW4gb2J0YWluaW5nIHN1ZmZpY2llbnQgYmFuZHdpZHRoIHRvIGF2b2lkIGFueSBv dmVyLWNvbW1pdG1lbnQsIEkgd291bGQgcmVjb21tZW5kIHJldGFpbmluZyB0aGUgYmVoYXZpb3Ig PmN1cnJlbnRseSBzcGVjaWZpZWQgaW4gNC4yLjIgKGllICJ0aGUgQU4gU0hPVUxEIE5PVCBkaXNj b250aW51ZSBhbnkgbXVsdGljYXN0IHN0cmVhbXMgaW4gb3JkZXIgdG8gYnJpbmcgYmFuZHdpZHRo IGRvd24gdG8gd2l0aGluIHRoZSA+bmV3IGxpbWl0LCB1bmxlc3Mgc3VjaCBhY3Rpb24gaXMgcmVx dWlyZWQgYnkgbG9jYWwgcG9saWN5LikgIGFuZCBhbGlnbiB0aGUgdGV4dCBvZiB0ZWggc2VjdGlv bnMgdGhhdCBhcmUgaW5jb25zaXN0ZW50IHdpdGggdGhhdC4NCg0KSW4gb3BpbmlvbiBpdCB3b3Vs ZCBtYWtlIHNlbnNlIHRvIG1haW50YWluIHRoZSBiZWhhdmlvciBjdXJyZW50bHkgc3BlY2lmaWVk IGluIDQuMi4yIChpZSAidGhlIEFOIFNIT1VMRCBOT1QgZGlzY29udGludWUgYW55IG11bHRpY2Fz dCBzdHJlYW1zIGluIG9yZGVyIHRvIGJyaW5nIGJhbmR3aWR0aCBkb3duIHRvIHdpdGhpbiB0aGUg Pm5ldyBsaW1pdCwgdW5sZXNzIHN1Y2ggYWN0aW9uIGlzIHJlcXVpcmVkIGJ5IGxvY2FsIHBvbGlj eSksIHRoZXJlZm9yZSBJIHdvdWxkIHN1cHBvcnQgdGhlIHByb3Bvc2FsIG9mIGFsaWduaW5nIGFs bCB0aGUgc2VjdGlvbnMgd2l0aCB0aGlzIGJlaGF2aW9yLg0KDQpUaGFua3MNCkJlc3QgUmVnYXJk cw0KUm9iZXJ0YQ0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZy b206IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkgPGZsZWZhdWNoQGNpc2NvLmNvbTxt YWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tPj4NCkRhdGU6IFdlZCwgSnVuIDQsIDIwMTQgYXQgNzox OCBBTQ0KU3ViamVjdDogUmU6IFtBTkNQXSBJbmNvbnNpc3RlbmN5IGluIGRyYWZ0LWlldGYtYW5j cC1tYy1leHRlbnNpb25zLTE2DQpUbzogVG9tIFRheWxvciA8dG9tLnRheWxvci5zdGRzQGdtYWls LmNvbTxtYWlsdG86dG9tLnRheWxvci5zdGRzQGdtYWlsLmNvbT4+DQpDYzogImFuY3BAaWV0Zi5v cmc8bWFpbHRvOmFuY3BAaWV0Zi5vcmc+IiA8YW5jcEBpZXRmLm9yZzxtYWlsdG86YW5jcEBpZXRm Lm9yZz4+DQoNCg0KVG9tIGFuZCBhbGwsDQoNCkluIHRoZSBjb25zaWRlcmVkIHNjZW5hcmlvIHdo ZXJlOg0KICAgICAgICAqIHRoZSBBTiByZWNlaXZlcyBhIG5ldyBCYW5kd2lkdGgtQWxsb2NhdGlv biBUTFYNCiAgICAgICAgKiB0aGUgQU4gaGFzIGFscmVhZHkgY29tbWl0dGVkIG1vcmUgbXVsdGlj YXN0IGJhbmR3aWR0aA0KSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIEFOIGZpcnN0IGF0dGVtcHRz IHRvIGluY3JlYXNlIHRoZSBkZWxlZ2F0ZWQgYmFuZHdpZHRoIGJ5IHNlbmRpbmcgdG8gdGhlIE5B UyBhIEJhbmR3aWR0aCBSZWFsbG9jYXRpb24gUmVxdWVzdCBtZXNzYWdlLiBUaGlzIGlzIHRoZSBi ZWhhdmlvciBhbHJlYWR5IHNwZWNpZmllZCAoMSkgZm9yIHRoZSBBTiBpbiB0aGUgc2l0dWF0aW9u IHdoZXJlIHRoZSBkZWxlZ2F0ZWQgYmFuZHdpZHRoIGhhcyBub3QgYmVlbiBtb2RpZmllZCBidXQg dGhlcmUgaXMgYSBuZXcgbXVsdGljYXN0IGpvaW4gdGhhdCB3b3VsZCByZXN1bHQgaW4gY29tbWl0 dGluZyBtb3JlIGJhbmR3aWR0aCB0aGFuIGRlbGVnYXRlZC4NCldvdWxkIHlvdSBhZ3JlZT8NCg0K SWYgdGhpcyBhdHRlbXB0IGRvZXMgbm90IHJlc3VsdCBpbiBvYnRhaW5pbmcgc3VmZmljaWVudCBi YW5kd2lkdGggdG8gYXZvaWQgYW55IG92ZXItY29tbWl0bWVudCwgSSB3b3VsZCByZWNvbW1lbmQg cmV0YWluaW5nIHRoZSBiZWhhdmlvciBjdXJyZW50bHkgc3BlY2lmaWVkIGluIDQuMi4yIChpZSAi dGhlIEFOIFNIT1VMRCBOT1QgZGlzY29udGludWUgYW55IG11bHRpY2FzdCBzdHJlYW1zIGluIG9y ZGVyIHRvIGJyaW5nIGJhbmR3aWR0aCBkb3duIHRvIHdpdGhpbiB0aGUgbmV3IGxpbWl0LCB1bmxl c3Mgc3VjaCBhY3Rpb24gaXMgcmVxdWlyZWQgYnkgbG9jYWwgcG9saWN5LikgIGFuZCBhbGlnbiB0 aGUgdGV4dCBvZiB0ZWggc2VjdGlvbnMgdGhhdCBhcmUgaW5jb25zaXN0ZW50IHdpdGggdGhhdC4N Cg0KDQpGcmFuY29pcw0KDQoNCigxKSBzZWN0aW9uIDYuMi41LjIuIDoNCuKAnA0KV2hlbiB0aGUg QU4gcmVjZWl2ZXMgYSBqb2luIHJlcXVlc3QsIGl0DQogICBjaGVja3Mgd2hldGhlciBpdCBoYXMg c3VmZmljaWVudCByZW1haW5pbmcgdW5jb21taXR0ZWQgbXVsdGljYXN0DQogICBiYW5kd2lkdGgg b24gdGhlIGFjY2VzcyBsaW5lIHRvIGFjY29tbW9kYXRlIHRoZSBuZXcgbXVsdGljYXN0IGZsb3cu DQogICBJZiBub3QsIGl0IE1BWSBzZW5kIGEgcmVxdWVzdCB0byB0aGUgTkFTIGZvciBhbiBpbmNy ZWFzZWQgYWxsb2NhdGlvbg0KICAgb2YgZGVsZWdhdGVkIGJhbmR3aWR0aCB1c2luZyB0aGUgQmFu ZHdpZHRoIFJlYWxsb2NhdGlvbiBSZXF1ZXN0DQogICBtZXNzYWdlLiAgVGhlIE5BUyBNVVNUIHJl dHVybiBhIEJhbmR3aWR0aCBUcmFuc2ZlciBtZXNzYWdlIGluZGljYXRpbmcNCiAgIHdoZXRoZXIg aXQgaGFzIGdyYW50ZWQgdGhlIHJlcXVlc3QgYW5kLCBpZiBzbywgdGhlIG5ldyBhbW91bnQgb2YN CiAgIGRlbGVnYXRlZCBiYW5kd2lkdGguDQoiDQoNCg0KT24gNCBKdW4gMjAxNCwgYXQgMTU6MDEs IFRvbSBUYXlsb3IgPHRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb208bWFpbHRvOnRvbS50YXlsb3Iu c3Rkc0BnbWFpbC5jb20+PiB3cm90ZToNCg0KPiBEb2luZyBteSBBVVRINDggcmV2aWV3IGZvciBk cmFmdC1pZXRmLWFuY3AtbWMtZXh0ZW5zaW9ucy0xNiwgSSBub3RpY2VkIGFuIGluY29uc2lzdGVu Y3kgaW4gdHJlYXRtZW50IGJldHdlZW4gdGhyZWUgZGlmZmVyZW50IGNhc2VzIHdoZXJlIHRoZSBB TiBpcyBhc3NpZ25lZCBhIHZhbHVlIG9mIG11bHRpY2FzdCBiYW5kd2lkdGggdGhhdCBpcyBsb3dl ciB0aGFuIHRoZSBBTiBoYXMgYWxyZWFkeSBjb21taXR0ZWQgdG8gYSBnaXZlbiBzdWJzY3JpYmVy LiBUaGUgcXVlc3Rpb24gdG8gdGhlIFdvcmtpbmcgR3JvdXAgaXMgd2hldGhlcjoNCj4gIChhKSBu byBjaGFuZ2UgaXMgbmVlZGVkOyBvcg0KPiAgKGIpIGxvY2FsIHBvbGljeSBzaG91bGQgZGV0ZXJt aW5lIHdoZXRoZXIgZXN0YWJsaXNoZWQgY29ubmVjdGlvbnMgc2hvdWxkIGJlIHRha2VuIGRvd24g dG8gbWVldCBiYW5kd2lkdGggbGltaXRzIHNldCBieSB0aGUgTkFTIGluIGFsbCBjYXNlczsgb3IN Cj4gIChjKSBlc3RhYmxpc2hlZCBjb25uZWN0aW9ucyBzaG91bGQgbmV2ZXIgYmUgdGFrZW4gZG93 biB1bnRpbCB0ZXJtaW5hdGVkIGJ5IHRoZSBzdWJzY3JpYmVyIChubyBwcm92aXNpb24gZm9yIGxv Y2FsIHBvbGljeSBpbiBhbnkgY2FzZSkuDQo+DQo+IFRoZSBjb250ZXh0IGluIGVhY2ggaW5zdGFu Y2UgaXMgdGhhdCB0aGUgTkFTIGhhcyBzZW50IGEgbXVsdGljYXN0IGJhbmR3aWR0aCBhbGxvY2F0 aW9uIHRvIHRoZSBBTi4gSWYgdGhlIEFOIGRvZXMgbm90IGNvbmZvcm0gdG8gdGhhdCBhbGxvY2F0 aW9uLCB0aGUgTkFTIGRvZXMgbm90IGhhdmUgYSBjb3JyZWN0IHZpZXcgb2YgdGhlIGFtb3VudCBv ZiBiYW5kd2lkdGggYXZhaWxhYmxlIGZvciBhZG1pc3Npb24gY29udHJvbCAoZS5nLiwgb2YgdW5p Y2FzdCBzZXJ2aWNlcykgYXQgdGhlIE5BUyBpdHNlbGYuIFRoYXQgc2hvdWxkIHByb2JhYmx5IGJl IGZpeGVkIGluZGVwZW5kZW50bHkgb2YgdGhlIHF1ZXN0aW9uIHN0YXRlZCBhYm92ZS4gIEFuZCwg b2YgY291cnNlLCB0aGUgb3Zlci1jb21taXRtZW50IGF0IHRoZSBBTiBtZWFucyB0aGF0IGxlc3Mg YmFuZHdpZHRoIGlzIGF2YWlsYWJsZSBmb3Igc2VydmljZXMgYWRtaXR0ZWQgYXQgdGhlIE5BUy4N Cj4NCj4gSGVyZSBhcmUgdGhlIHRocmVlIGNhc2VzIGluIHF1ZXN0aW9uOg0KPg0KPiBDYXNlIDE6 IGJhbmR3aWR0aCBhc3NpZ25lZCBieSBQb3J0IE1hbmFnZW1lbnQgbWVzc2FnZQ0KPiA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPiBSZWNl aXZlciBiZWhhdmlvdXIgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4yLjIuIE5vdGUgdGhlIHBy b3Zpc2lvbiBmb3IgbG9jYWwgcG9saWN5IGluIHRoZSBxdW90ZWQgdGV4dDoNCj4NCj4gICJJZiB0 aGUgUG9ydCBNYW5hZ2VtZW50IG1lc3NhZ2UgY29udGFpbnMgYSBCYW5kd2lkdGgtQWxsb2NhdGlv biBUTFYsDQo+ICAgdGhlIEFOIGFkb3B0cyB0aGlzIGFzIHRoZSBjdXJyZW50IHZhbHVlIG9mIGl0 cyB0b3RhbCBtdWx0aWNhc3QNCj4gICBiYW5kd2lkdGggbGltaXQgZm9yIHRoZSB0YXJnZXQgcG9y dC4gIElmIHRoZSBBTiBoYXMgYWxyZWFkeSBjb21taXR0ZWQNCj4gICBtdWx0aWNhc3QgYmFuZHdp ZHRoIGV4Y2VlZGluZyB0aGUgYW1vdW50IGdpdmVuIGluIHRoZSBCYW5kd2lkdGgtDQo+ICAgQWxs b2NhdGlvbiBUTFYsIHRoZSBBTiBTSE9VTEQgTk9UIGRpc2NvbnRpbnVlIGFueSBtdWx0aWNhc3Qg c3RyZWFtcw0KPiAgIGluIG9yZGVyIHRvIGJyaW5nIGJhbmR3aWR0aCBkb3duIHRvIHdpdGhpbiB0 aGUgbmV3IGxpbWl0LCB1bmxlc3Mgc3VjaA0KPiAgIGFjdGlvbiBpcyByZXF1aXJlZCBieSBsb2Nh bCBwb2xpY3kuICBIb3dldmVyLCB0aGUgQU4gTVVTVCBOT1QgYWRtaXQNCj4gICBuZXcgbXVsdGlj YXN0IHN0cmVhbXMgdGhhdCBhcmUgc3ViamVjdCB0byBhZG1pc3Npb24gY29udHJvbCB1bnRpbCBp dA0KPiAgIGNhbiBkbyBzbyB3aXRoaW4gdGhlIGxpbWl0IHNwZWNpZmllZCBieSB0aGUgQmFuZHdp ZHRoLUFsbG9jYXRpb24NCj4gICBUTFYuIg0KPg0KPiBDYXNlIDI6IGJhbmR3aWR0aCBhc3NpZ25l ZCBieSBCYW5kd2lkdGggVHJhbnNmZXIgbWVzc2FnZQ0KPiA9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPiBBTiBiZWhhdmlvdXIgYXMg cmVjZWl2ZXIgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC42LjIuMi4gVGhlcmUgaXMgbm8gcHJv dmlzaW9uIGZvciBsb2NhbCBwb2xpY3k6DQo+DQo+ICAiSWYgYXMgdGhlIHJlc3VsdCBvZiB0aGUg cHJvY2VkdXJlcyBqdXN0IGRlc2NyaWJlZCB0aGUgQU4gZGV0ZXJtaW5lcw0KPiAgIHRoYXQgaXQg aGFzIG92ZXItY29tbWl0dGVkIG11bHRpY2FzdCBiYW5kd2lkdGgsIGl0IE1VU1QgTk9UIHRlcm1p bmF0ZQ0KPiAgIGFueSBjdXJyZW50bHktYWN0aXZlIHByb2dyYW1zLCBidXQgTVVTVCBOT1QgaG9u b3VyIGFueSBtb3JlICJqb2luIg0KPiAgIHJlcXVlc3RzIHVudGlsIGl0IGlzIHBvc3NpYmxlIHRv IGRvIHNvIHdpdGhpbiB0aGUgbGltaXQgc2V0IGJ5IGl0cw0KPiAgIGN1cnJlbnQgdmFsdWUgb2Yg ZGVsZWdhdGVkIGJhbmR3aWR0aC4iDQo+DQo+IENhc2UgMzogYmFuZHdpZHRoIGFzc2lnbmVkIGJ5 IERlbGVnYXRlZCBCYW5kd2lkdGggUXVlcnkgUmVzcG9uc2UgbWVzc2FnZQ0KPiA9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCj4NCj4gQU4gYmVoYXZpb3VyIGFzIHJlY2VpdmVyIGlzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuOC4yLjIuIFRoZXJlIGlzIG5vIHByb3Zpc2lvbiBmb3IgbG9jYWwgcG9saWN5Og0KPg0K PiAgIi4uLiBJZiB0aGUgQU4gaGFzDQo+ICAgY3VycmVudGx5IGNvbW1pdHRlZCBtb3JlIHRoYW4g dGhpcyBhbW91bnQgdG8gYWN0aXZlIHByb2dyYW1zLCBpdCBNVVNUDQo+ICAgTk9UIGNlYXNlIHJl cGxpY2F0aW5nIHRoZSBmbG93cyBjb25jZXJuZWQsIGJ1dCBNVVNUIE5PVCBob25vdXIgYW55DQo+ ICAgbW9yZSBKb2luIHJlcXVlc3RzIHVudGlsIHBvc3NpYmxlIHRvIGRvIHNvIHdpdGhpbiB0aGUg bmV3IGxpbWl0LiINCj4NCj4NCj4gVG9tIFRheWxvcg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBTkNQIG1haWxpbmcgbGlzdA0KPiBBTkNQ QGlldGYub3JnPG1haWx0bzpBTkNQQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FuY3ANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkFOQ1AgbWFpbGluZyBsaXN0DQpBTkNQQGlldGYub3JnPG1haWx0bzpB TkNQQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmNw DQoNCg== --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59xmbrcdx01ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Ub20sIEZyYW5jb2lzIGFuZCBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvcnJ5IGZvciBteSBsYXRlIHJlcGx5LCBjb21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7SSB3b3VsZCBzdWdn ZXN0IHRoYXQgdGhlIEFOIGZpcnN0IGF0dGVtcHRzIHRvIGluY3JlYXNlIHRoZSBkZWxlZ2F0ZWQg YmFuZHdpZHRoIGJ5IHNlbmRpbmcgdG8gdGhlIE5BUyBhICZndDtCYW5kd2lkdGggUmVhbGxvY2F0 aW9uICZndDtSZXF1ZXN0IG1lc3NhZ2UuIFRoaXMgaXMgdGhlIGJlaGF2aW9yIGFscmVhZHkgc3Bl Y2lmaWVkICgxKSBmb3IgdGhlIEFOIGluIHRoZQ0KIHNpdHVhdGlvbiB3aGVyZSB0aGUgZGVsZWdh dGVkIGJhbmR3aWR0aCBoYXMgbm90IGJlZW4gJmd0O21vZGlmaWVkIGJ1dCB0aGVyZSBpcyBhIG5l dyBtdWx0aWNhc3Qgam9pbiB0aGF0IHdvdWxkIHJlc3VsdCBpbiBjb21taXR0aW5nIG1vcmUgYmFu ZHdpZHRoIHRoYW4gZGVsZWdhdGVkLjxicj4NCiZndDtXb3VsZCB5b3UgYWdyZWU/PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdy ZWUgd2l0aCB0aGlzIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0O0lmIHRoaXMgYXR0ZW1wdCBkb2VzIG5vdCByZXN1bHQg aW4gb2J0YWluaW5nIHN1ZmZpY2llbnQgYmFuZHdpZHRoIHRvIGF2b2lkIGFueSBvdmVyLWNvbW1p dG1lbnQsIEkgd291bGQgcmVjb21tZW5kIHJldGFpbmluZyB0aGUgYmVoYXZpb3IgJmd0O2N1cnJl bnRseSBzcGVjaWZpZWQgaW4gNC4yLjIgKGllICZxdW90O3RoZSBBTiBTSE9VTEQgTk9UIGRpc2Nv bnRpbnVlIGFueQ0KIG11bHRpY2FzdCBzdHJlYW1zIGluIG9yZGVyIHRvIGJyaW5nIGJhbmR3aWR0 aCBkb3duIHRvIHdpdGhpbiB0aGUgJmd0O25ldyBsaW1pdCwgdW5sZXNzIHN1Y2ggYWN0aW9uIGlz IHJlcXVpcmVkIGJ5IGxvY2FsIHBvbGljeS4pICZuYnNwO2FuZCBhbGlnbiB0aGUgdGV4dCBvZiB0 ZWggc2VjdGlvbnMgdGhhdCBhcmUgaW5jb25zaXN0ZW50IHdpdGggdGhhdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIG9waW5pb24gaXQg d291bGQgbWFrZSBzZW5zZSB0byBtYWludGFpbiB0aGUgYmVoYXZpb3IgY3VycmVudGx5IHNwZWNp ZmllZCBpbiA0LjIuMiAoaWUgJnF1b3Q7dGhlIEFOIFNIT1VMRCBOT1QgZGlzY29udGludWUgYW55 IG11bHRpY2FzdCBzdHJlYW1zIGluIG9yZGVyIHRvIGJyaW5nDQogYmFuZHdpZHRoIGRvd24gdG8g d2l0aGluIHRoZSAmZ3Q7bmV3IGxpbWl0LCB1bmxlc3Mgc3VjaCBhY3Rpb24gaXMgcmVxdWlyZWQg YnkgbG9jYWwgcG9saWN5KSwgdGhlcmVmb3JlIEkgd291bGQgc3VwcG9ydCB0aGUgcHJvcG9zYWwg b2YgYWxpZ25pbmcgYWxsIHRoZSBzZWN0aW9ucyB3aXRoIHRoaXMgYmVoYXZpb3IuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvYmVydGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+ DQpGcm9tOiA8Yj5GcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpPC9iPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbSI+ZmxlZmF1Y2hAY2lzY28uY29tPC9hPiZndDs8 YnI+DQpEYXRlOiBXZWQsIEp1biA0LCAyMDE0IGF0IDc6MTggQU08YnI+DQpTdWJqZWN0OiBSZTog W0FOQ1BdIEluY29uc2lzdGVuY3kgaW4gZHJhZnQtaWV0Zi1hbmNwLW1jLWV4dGVuc2lvbnMtMTY8 YnI+DQpUbzogVG9tIFRheWxvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbS50YXlsb3Iuc3Rkc0Bn bWFpbC5jb20iPnRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCkNjOiAmcXVv dDs8YSBocmVmPSJtYWlsdG86YW5jcEBpZXRmLm9yZyI+YW5jcEBpZXRmLm9yZzwvYT4mcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzphbmNwQGlldGYub3JnIj5hbmNwQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8YnI+DQo8YnI+DQpUb20gYW5kIGFsbCw8YnI+DQo8YnI+DQpJbiB0aGUgY29uc2lkZXJl ZCBzY2VuYXJpbyB3aGVyZTo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKiB0aGUg QU4gcmVjZWl2ZXMgYSBuZXcgQmFuZHdpZHRoLUFsbG9jYXRpb24gVExWPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICogdGhlIEFOIGhhcyBhbHJlYWR5IGNvbW1pdHRlZCBtb3JlIG11 bHRpY2FzdCBiYW5kd2lkdGg8YnI+DQpJIHdvdWxkIHN1Z2dlc3QgdGhhdCB0aGUgQU4gZmlyc3Qg YXR0ZW1wdHMgdG8gaW5jcmVhc2UgdGhlIGRlbGVnYXRlZCBiYW5kd2lkdGggYnkgc2VuZGluZyB0 byB0aGUgTkFTIGEgQmFuZHdpZHRoIFJlYWxsb2NhdGlvbiBSZXF1ZXN0IG1lc3NhZ2UuIFRoaXMg aXMgdGhlIGJlaGF2aW9yIGFscmVhZHkgc3BlY2lmaWVkICgxKSBmb3IgdGhlIEFOIGluIHRoZSBz aXR1YXRpb24gd2hlcmUgdGhlIGRlbGVnYXRlZCBiYW5kd2lkdGggaGFzIG5vdCBiZWVuDQogbW9k aWZpZWQgYnV0IHRoZXJlIGlzIGEgbmV3IG11bHRpY2FzdCBqb2luIHRoYXQgd291bGQgcmVzdWx0 IGluIGNvbW1pdHRpbmcgbW9yZSBiYW5kd2lkdGggdGhhbiBkZWxlZ2F0ZWQuPGJyPg0KV291bGQg eW91IGFncmVlPzxicj4NCjxicj4NCklmIHRoaXMgYXR0ZW1wdCBkb2VzIG5vdCByZXN1bHQgaW4g b2J0YWluaW5nIHN1ZmZpY2llbnQgYmFuZHdpZHRoIHRvIGF2b2lkIGFueSBvdmVyLWNvbW1pdG1l bnQsIEkgd291bGQgcmVjb21tZW5kIHJldGFpbmluZyB0aGUgYmVoYXZpb3IgY3VycmVudGx5IHNw ZWNpZmllZCBpbiA0LjIuMiAoaWUgJnF1b3Q7dGhlIEFOIFNIT1VMRCBOT1QgZGlzY29udGludWUg YW55IG11bHRpY2FzdCBzdHJlYW1zIGluIG9yZGVyIHRvIGJyaW5nIGJhbmR3aWR0aCBkb3duIHRv DQogd2l0aGluIHRoZSBuZXcgbGltaXQsIHVubGVzcyBzdWNoIGFjdGlvbiBpcyByZXF1aXJlZCBi eSBsb2NhbCBwb2xpY3kuKSAmbmJzcDthbmQgYWxpZ24gdGhlIHRleHQgb2YgdGVoIHNlY3Rpb25z IHRoYXQgYXJlIGluY29uc2lzdGVudCB3aXRoIHRoYXQuPGJyPg0KPGJyPg0KPGJyPg0KRnJhbmNv aXM8YnI+DQo8YnI+DQo8YnI+DQooMSkgc2VjdGlvbiA2LjIuNS4yLiA6PGJyPg0K4oCcPGJyPg0K V2hlbiB0aGUgQU4gcmVjZWl2ZXMgYSBqb2luIHJlcXVlc3QsIGl0PGJyPg0KJm5ic3A7ICZuYnNw O2NoZWNrcyB3aGV0aGVyIGl0IGhhcyBzdWZmaWNpZW50IHJlbWFpbmluZyB1bmNvbW1pdHRlZCBt dWx0aWNhc3Q8YnI+DQombmJzcDsgJm5ic3A7YmFuZHdpZHRoIG9uIHRoZSBhY2Nlc3MgbGluZSB0 byBhY2NvbW1vZGF0ZSB0aGUgbmV3IG11bHRpY2FzdCBmbG93Ljxicj4NCiZuYnNwOyAmbmJzcDtJ ZiBub3QsIGl0IE1BWSBzZW5kIGEgcmVxdWVzdCB0byB0aGUgTkFTIGZvciBhbiBpbmNyZWFzZWQg YWxsb2NhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDtvZiBkZWxlZ2F0ZWQgYmFuZHdpZHRoIHVzaW5n IHRoZSBCYW5kd2lkdGggUmVhbGxvY2F0aW9uIFJlcXVlc3Q8YnI+DQombmJzcDsgJm5ic3A7bWVz c2FnZS4gJm5ic3A7VGhlIE5BUyBNVVNUIHJldHVybiBhIEJhbmR3aWR0aCBUcmFuc2ZlciBtZXNz YWdlIGluZGljYXRpbmc8YnI+DQombmJzcDsgJm5ic3A7d2hldGhlciBpdCBoYXMgZ3JhbnRlZCB0 aGUgcmVxdWVzdCBhbmQsIGlmIHNvLCB0aGUgbmV3IGFtb3VudCBvZjxicj4NCiZuYnNwOyAmbmJz cDtkZWxlZ2F0ZWQgYmFuZHdpZHRoLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mcXVvdDs8YnI+DQo8YnI+DQo8YnI+DQpPbiA0IEp1biAyMDE0LCBh dCAxNTowMSwgVG9tIFRheWxvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbS50YXlsb3Iuc3Rkc0Bn bWFpbC5jb20iPnRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8 YnI+DQomZ3Q7IERvaW5nIG15IEFVVEg0OCByZXZpZXcgZm9yIGRyYWZ0LWlldGYtYW5jcC1tYy1l eHRlbnNpb25zLTE2LCBJIG5vdGljZWQgYW4gaW5jb25zaXN0ZW5jeSBpbiB0cmVhdG1lbnQgYmV0 d2VlbiB0aHJlZSBkaWZmZXJlbnQgY2FzZXMgd2hlcmUgdGhlIEFOIGlzIGFzc2lnbmVkIGEgdmFs dWUgb2YgbXVsdGljYXN0IGJhbmR3aWR0aCB0aGF0IGlzIGxvd2VyIHRoYW4gdGhlIEFOIGhhcyBh bHJlYWR5IGNvbW1pdHRlZCB0byBhIGdpdmVuIHN1YnNjcmliZXIuDQogVGhlIHF1ZXN0aW9uIHRv IHRoZSBXb3JraW5nIEdyb3VwIGlzIHdoZXRoZXI6PGJyPg0KJmd0OyAmbmJzcDsoYSkgbm8gY2hh bmdlIGlzIG5lZWRlZDsgb3I8YnI+DQomZ3Q7ICZuYnNwOyhiKSBsb2NhbCBwb2xpY3kgc2hvdWxk IGRldGVybWluZSB3aGV0aGVyIGVzdGFibGlzaGVkIGNvbm5lY3Rpb25zIHNob3VsZCBiZSB0YWtl biBkb3duIHRvIG1lZXQgYmFuZHdpZHRoIGxpbWl0cyBzZXQgYnkgdGhlIE5BUyBpbiBhbGwgY2Fz ZXM7IG9yPGJyPg0KJmd0OyAmbmJzcDsoYykgZXN0YWJsaXNoZWQgY29ubmVjdGlvbnMgc2hvdWxk IG5ldmVyIGJlIHRha2VuIGRvd24gdW50aWwgdGVybWluYXRlZCBieSB0aGUgc3Vic2NyaWJlciAo bm8gcHJvdmlzaW9uIGZvciBsb2NhbCBwb2xpY3kgaW4gYW55IGNhc2UpLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZSBjb250ZXh0IGluIGVhY2ggaW5zdGFuY2UgaXMgdGhhdCB0aGUgTkFTIGhhcyBz ZW50IGEgbXVsdGljYXN0IGJhbmR3aWR0aCBhbGxvY2F0aW9uIHRvIHRoZSBBTi4gSWYgdGhlIEFO IGRvZXMgbm90IGNvbmZvcm0gdG8gdGhhdCBhbGxvY2F0aW9uLCB0aGUgTkFTIGRvZXMgbm90IGhh dmUgYSBjb3JyZWN0IHZpZXcgb2YgdGhlIGFtb3VudCBvZiBiYW5kd2lkdGggYXZhaWxhYmxlIGZv ciBhZG1pc3Npb24gY29udHJvbCAoZS5nLiwgb2YgdW5pY2FzdA0KIHNlcnZpY2VzKSBhdCB0aGUg TkFTIGl0c2VsZi4gVGhhdCBzaG91bGQgcHJvYmFibHkgYmUgZml4ZWQgaW5kZXBlbmRlbnRseSBv ZiB0aGUgcXVlc3Rpb24gc3RhdGVkIGFib3ZlLiAmbmJzcDtBbmQsIG9mIGNvdXJzZSwgdGhlIG92 ZXItY29tbWl0bWVudCBhdCB0aGUgQU4gbWVhbnMgdGhhdCBsZXNzIGJhbmR3aWR0aCBpcyBhdmFp bGFibGUgZm9yIHNlcnZpY2VzIGFkbWl0dGVkIGF0IHRoZSBOQVMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgSGVyZSBhcmUgdGhlIHRocmVlIGNhc2VzIGluIHF1ZXN0aW9uOjxicj4NCiZndDs8YnI+DQom Z3Q7IENhc2UgMTogYmFuZHdpZHRoIGFzc2lnbmVkIGJ5IFBvcnQgTWFuYWdlbWVudCBtZXNzYWdl PGJyPg0KJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTxicj4NCiZndDs8YnI+DQomZ3Q7IFJlY2VpdmVyIGJlaGF2aW91ciBpcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiA0LjIuMi4gTm90ZSB0aGUgcHJvdmlzaW9uIGZvciBsb2NhbCBwb2xpY3kg aW4gdGhlIHF1b3RlZCB0ZXh0Ojxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyZxdW90O0lmIHRo ZSBQb3J0IE1hbmFnZW1lbnQgbWVzc2FnZSBjb250YWlucyBhIEJhbmR3aWR0aC1BbGxvY2F0aW9u IFRMViw8YnI+DQomZ3Q7ICZuYnNwOyB0aGUgQU4gYWRvcHRzIHRoaXMgYXMgdGhlIGN1cnJlbnQg dmFsdWUgb2YgaXRzIHRvdGFsIG11bHRpY2FzdDxicj4NCiZndDsgJm5ic3A7IGJhbmR3aWR0aCBs aW1pdCBmb3IgdGhlIHRhcmdldCBwb3J0LiAmbmJzcDtJZiB0aGUgQU4gaGFzIGFscmVhZHkgY29t bWl0dGVkPGJyPg0KJmd0OyAmbmJzcDsgbXVsdGljYXN0IGJhbmR3aWR0aCBleGNlZWRpbmcgdGhl IGFtb3VudCBnaXZlbiBpbiB0aGUgQmFuZHdpZHRoLTxicj4NCiZndDsgJm5ic3A7IEFsbG9jYXRp b24gVExWLCB0aGUgQU4gU0hPVUxEIE5PVCBkaXNjb250aW51ZSBhbnkgbXVsdGljYXN0IHN0cmVh bXM8YnI+DQomZ3Q7ICZuYnNwOyBpbiBvcmRlciB0byBicmluZyBiYW5kd2lkdGggZG93biB0byB3 aXRoaW4gdGhlIG5ldyBsaW1pdCwgdW5sZXNzIHN1Y2g8YnI+DQomZ3Q7ICZuYnNwOyBhY3Rpb24g aXMgcmVxdWlyZWQgYnkgbG9jYWwgcG9saWN5LiAmbmJzcDtIb3dldmVyLCB0aGUgQU4gTVVTVCBO T1QgYWRtaXQ8YnI+DQomZ3Q7ICZuYnNwOyBuZXcgbXVsdGljYXN0IHN0cmVhbXMgdGhhdCBhcmUg c3ViamVjdCB0byBhZG1pc3Npb24gY29udHJvbCB1bnRpbCBpdDxicj4NCiZndDsgJm5ic3A7IGNh biBkbyBzbyB3aXRoaW4gdGhlIGxpbWl0IHNwZWNpZmllZCBieSB0aGUgQmFuZHdpZHRoLUFsbG9j YXRpb248YnI+DQomZ3Q7ICZuYnNwOyBUTFYuJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQ2Fz ZSAyOiBiYW5kd2lkdGggYXNzaWduZWQgYnkgQmFuZHdpZHRoIFRyYW5zZmVyIG1lc3NhZ2U8YnI+ DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PGJyPg0KJmd0Ozxicj4NCiZndDsgQU4gYmVoYXZpb3VyIGFzIHJlY2VpdmVyIGlzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDQuNi4yLjIuIFRoZXJlIGlzIG5vIHByb3Zpc2lvbiBmb3IgbG9j YWwgcG9saWN5Ojxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyZxdW90O0lmIGFzIHRoZSByZXN1 bHQgb2YgdGhlIHByb2NlZHVyZXMganVzdCBkZXNjcmliZWQgdGhlIEFOIGRldGVybWluZXM8YnI+ DQomZ3Q7ICZuYnNwOyB0aGF0IGl0IGhhcyBvdmVyLWNvbW1pdHRlZCBtdWx0aWNhc3QgYmFuZHdp ZHRoLCBpdCBNVVNUIE5PVCB0ZXJtaW5hdGU8YnI+DQomZ3Q7ICZuYnNwOyBhbnkgY3VycmVudGx5 LWFjdGl2ZSBwcm9ncmFtcywgYnV0IE1VU1QgTk9UIGhvbm91ciBhbnkgbW9yZSAmcXVvdDtqb2lu JnF1b3Q7PGJyPg0KJmd0OyAmbmJzcDsgcmVxdWVzdHMgdW50aWwgaXQgaXMgcG9zc2libGUgdG8g ZG8gc28gd2l0aGluIHRoZSBsaW1pdCBzZXQgYnkgaXRzPGJyPg0KJmd0OyAmbmJzcDsgY3VycmVu dCB2YWx1ZSBvZiBkZWxlZ2F0ZWQgYmFuZHdpZHRoLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IENhc2UgMzogYmFuZHdpZHRoIGFzc2lnbmVkIGJ5IERlbGVnYXRlZCBCYW5kd2lkdGggUXVlcnkg UmVzcG9uc2UgbWVzc2FnZTxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0Ozxicj4N CiZndDsgQU4gYmVoYXZpb3VyIGFzIHJlY2VpdmVyIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQu OC4yLjIuIFRoZXJlIGlzIG5vIHByb3Zpc2lvbiBmb3IgbG9jYWwgcG9saWN5Ojxicj4NCiZndDs8 YnI+DQomZ3Q7ICZuYnNwOyZxdW90Oy4uLiBJZiB0aGUgQU4gaGFzPGJyPg0KJmd0OyAmbmJzcDsg Y3VycmVudGx5IGNvbW1pdHRlZCBtb3JlIHRoYW4gdGhpcyBhbW91bnQgdG8gYWN0aXZlIHByb2dy YW1zLCBpdCBNVVNUPGJyPg0KJmd0OyAmbmJzcDsgTk9UIGNlYXNlIHJlcGxpY2F0aW5nIHRoZSBm bG93cyBjb25jZXJuZWQsIGJ1dCBNVVNUIE5PVCBob25vdXIgYW55PGJyPg0KJmd0OyAmbmJzcDsg bW9yZSBKb2luIHJlcXVlc3RzIHVudGlsIHBvc3NpYmxlIHRvIGRvIHNvIHdpdGhpbiB0aGUgbmV3 IGxpbWl0LiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUb20gVGF5bG9yPGJy Pg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IEFOQ1AgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJt YWlsdG86QU5DUEBpZXRmLm9yZyI+QU5DUEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5jcCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5jcDwvYT48YnI+DQo8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CkFOQ1AgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFOQ1BAaWV0Zi5vcmciPkFO Q1BAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hbmNwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hbmNwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59xmbrcdx01ciscoc_-- From nobody Wed Jun 18 19:09:47 2014 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3681A018C for ; Wed, 18 Jun 2014 19:09:43 -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 vogLaCXoKyWm for ; Wed, 18 Jun 2014 19:09:41 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBDE1A0089 for ; Wed, 18 Jun 2014 19:09:40 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id c1so365028igq.15 for ; Wed, 18 Jun 2014 19:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iAlt7mxIV/gFC8pOFl4fWCGWSzfXzSzommP9Ohb8Bns=; b=f0PaTzyHr9hAb/XV+Nem3PZmLT/unRmWN+nxvrRqggEA6li0QxksiEnN8L8TFO2nad Lb5/7nuX4bEYuR0zEvKS/ijA+COSSwUjJJ44T9ngkXnFGI798vsb//5o7lVAxBNvozRw /PZyV4fUiW+P4HmOCYgV5tLPSJXcbAvjKxqAAoUk5OXVbnXYl6UmdzLaFGaVF93kn80F SmAL34z3HazyevzLbrCUn/kD3o1DMJHmPVikKzR45SiYPj/f5my/4tuE01yqgsWxjcBX a1NLiM1PTa5JdUARq/1gnZUyaVumcxYt7njj5num9vUhAbRbPysEJIsIqu/ZRqltB7F/ KD8A== X-Received: by 10.50.28.51 with SMTP id y19mr3490153igg.5.1403143780097; Wed, 18 Jun 2014 19:09:40 -0700 (PDT) Received: from [192.168.0.100] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id 2sm2899664igs.17.2014.06.18.19.09.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Jun 2014 19:09:39 -0700 (PDT) Message-ID: <53A24663.5080602@gmail.com> Date: Wed, 18 Jun 2014 22:09:39 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Roberta Maglione (robmgl)" , "ancp@ietf.org" , "Francois Le Faucheur (flefauch)" References: <538F1897.1090702@gmail.com> <8A31814E-05BC-41F2-8484-3977A9CDE122@cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59@xmb-rcd-x01.cisco.com> In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59@xmb-rcd-x01.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ancp/lQrOZ1fM7o5Kf5xNNCW6XfPidsU Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 02:09:43 -0000 Time I brought this to a close. I will modify the text as suggested and let RFC publication proceed. Tom Taylor On 18/06/2014 8:34 AM, Roberta Maglione (robmgl) wrote: > Tom, Francois and All, > > Sorry for my late reply, comments inline. > >>I would suggest that the AN first attempts to increase the delegated bandwidth by sending to the NAS a >Bandwidth Reallocation >Request message. This is the behavior already specified (1) for the AN in the situation where the delegated bandwidth has not been >modified but > there is a new multicast join that would result in committing more > bandwidth than delegated. >>Would you agree? > > I agree with this approach. > >>If this attempt does not result in obtaining sufficient bandwidth to avoid any over-commitment, I would recommend retaining the behavior >currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the >new > limit, unless such action is required by local policy.) and align the > text of teh sections that are inconsistent with that. > > In opinion it would make sense to maintain the behavior currently > specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast > streams in order to bring bandwidth down to within the >new limit, > unless such action is required by local policy), therefore I would > support the proposal of aligning all the sections with this behavior. > > Thanks > > Best Regards > > Roberta > > ---------- Forwarded message ---------- > From: *Francois Le Faucheur (flefauch)* > > Date: Wed, Jun 4, 2014 at 7:18 AM > Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 > To: Tom Taylor > > Cc: "ancp@ietf.org " > > > > Tom and all, > > In the considered scenario where: > * the AN receives a new Bandwidth-Allocation TLV > * the AN has already committed more multicast bandwidth > I would suggest that the AN first attempts to increase the delegated > bandwidth by sending to the NAS a Bandwidth Reallocation Request > message. This is the behavior already specified (1) for the AN in the > situation where the delegated bandwidth has not been modified but there > is a new multicast join that would result in committing more bandwidth > than delegated. > Would you agree? > > If this attempt does not result in obtaining sufficient bandwidth to > avoid any over-commitment, I would recommend retaining the behavior > currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any > multicast streams in order to bring bandwidth down to within the new > limit, unless such action is required by local policy.) and align the > text of teh sections that are inconsistent with that. > > > Francois > > > (1) section 6.2.5.2. : > “ > When the AN receives a join request, it > checks whether it has sufficient remaining uncommitted multicast > bandwidth on the access line to accommodate the new multicast flow. > If not, it MAY send a request to the NAS for an increased allocation > of delegated bandwidth using the Bandwidth Reallocation Request > message. The NAS MUST return a Bandwidth Transfer message indicating > whether it has granted the request and, if so, the new amount of > delegated bandwidth. > > " > > > On 4 Jun 2014, at 15:01, Tom Taylor > wrote: > > > Doing my AUTH48 review for draft-ietf-ancp-mc-extensions-16, I > noticed an inconsistency in treatment between three different cases > where the AN is assigned a value of multicast bandwidth that is lower > than the AN has already committed to a given subscriber. The question to > the Working Group is whether: > > (a) no change is needed; or > > (b) local policy should determine whether established connections > should be taken down to meet bandwidth limits set by the NAS in all > cases; or > > (c) established connections should never be taken down until > terminated by the subscriber (no provision for local policy in any case). > > > > The context in each instance is that the NAS has sent a multicast > bandwidth allocation to the AN. If the AN does not conform to that > allocation, the NAS does not have a correct view of the amount of > bandwidth available for admission control (e.g., of unicast services) at > the NAS itself. That should probably be fixed independently of the > question stated above. And, of course, the over-commitment at the AN > means that less bandwidth is available for services admitted at the NAS. > > > > Here are the three cases in question: > > > > Case 1: bandwidth assigned by Port Management message > > ===================================================== > > > > Receiver behaviour is described in Section 4.2.2. Note the provision > for local policy in the quoted text: > > > > "If the Port Management message contains a Bandwidth-Allocation TLV, > > the AN adopts this as the current value of its total multicast > > bandwidth limit for the target port. If the AN has already committed > > multicast bandwidth exceeding the amount given in the Bandwidth- > > Allocation TLV, the AN SHOULD NOT discontinue any multicast streams > > in order to bring bandwidth down to within the new limit, unless such > > action is required by local policy. However, the AN MUST NOT admit > > new multicast streams that are subject to admission control until it > > can do so within the limit specified by the Bandwidth-Allocation > > TLV." > > > > Case 2: bandwidth assigned by Bandwidth Transfer message > > ======================================================== > > > > AN behaviour as receiver is described in Section 4.6.2.2. There is no > provision for local policy: > > > > "If as the result of the procedures just described the AN determines > > that it has over-committed multicast bandwidth, it MUST NOT terminate > > any currently-active programs, but MUST NOT honour any more "join" > > requests until it is possible to do so within the limit set by its > > current value of delegated bandwidth." > > > > Case 3: bandwidth assigned by Delegated Bandwidth Query Response message > > ======================================================================== > > > > AN behaviour as receiver is described in Section 4.8.2.2. There is no > provision for local policy: > > > > "... If the AN has > > currently committed more than this amount to active programs, it MUST > > NOT cease replicating the flows concerned, but MUST NOT honour any > > more Join requests until possible to do so within the new limit." > > > > > > Tom Taylor > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www.ietf.org/mailman/listinfo/ancp > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > From nobody Fri Jun 20 12:22:07 2014 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B4D1B28DE for ; Fri, 20 Jun 2014 12:22:03 -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 i8Bj9oC5_nFl for ; Fri, 20 Jun 2014 12:22:01 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F171B28ED for ; Fri, 20 Jun 2014 12:22:00 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id lx4so3664931iec.33 for ; Fri, 20 Jun 2014 12:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Vm4e6gpbGDRZb4ReumxQvpmgeUWwll5EsaMJY6lAfCM=; b=HUf0nNcPXqnDsQ4ej4id89Jt/CWKM/ESos4q8ye7Q8m9cbMPUFJB6ZDzfqaRQRtGh6 nsqIZG8penMOArCiR30Q2CftLF/Y8TCwDpEIfx9NHDo50hn2/5oiFwepcZ1tvsLTCrWo +LerB5HO7Y1hl09jwQ7GElkf4tWrfyrYRl3epRt+Mal2XazZsLuaX7tXdP9HZ+nrR+Dl 4t6vlsRlGQrygoHBnmE/WPqGRlTbzOVddBzKAFnl3UJCT5RgVbcLqOcNl7jzURWFXf0a FU5rsAM2gkv1iAQgIQPWrrXMvALh/v1t9qSrBQH13bO5IMiJqmhsW4tK1w6EFLNe+QDO WBAQ== X-Received: by 10.42.186.2 with SMTP id cq2mr6019194icb.25.1403292120398; Fri, 20 Jun 2014 12:22:00 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id f9sm6723517igc.15.2014.06.20.12.21.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 12:22:00 -0700 (PDT) Message-ID: <53A489D2.2040601@gmail.com> Date: Fri, 20 Jun 2014 15:21:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Roberta Maglione (robmgl)" , "ancp@ietf.org" , "Francois Le Faucheur (flefauch)" References: <538F1897.1090702@gmail.com> <8A31814E-05BC-41F2-8484-3977A9CDE122@cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59@xmb-rcd-x01.cisco.com> In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1EB9DE59@xmb-rcd-x01.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ancp/5_JhAT-9n6aZRLr8qsv94TfEaoM Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:22:04 -0000 I have made the following changes to the RFC Editor's version of the document. Basically they propagate the Section 4.2.2 text to Sections 4.6.2.2 and 4.8.2.2, with an extra reference to procedures in 6.2.5.2. In Section 4.6.2.2: OLD If, as the result of the procedures just described, the AN determines that it has over-committed multicast bandwidth, it MUST NOT terminate any currently active programs but MUST NOT honor any more join requests until it is possible to do so within the limit set by its current value of delegated bandwidth. NEW If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN MAY attempt to correct the situation by sending a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message. In Section 4.8.2.2: OLD If the AN has currently committed more than this amount to active programs, it MUST NOT cease replicating the flows concerned but MUST NOT honor any more join requests until possible to do so within the new limit. NEW If the AN has already committed multicast bandwidth exceeding the amount given in the Bandwidth-Allocation TLV, the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the new limit, unless such action is required by local policy. However, the AN MUST NOT admit new multicast streams that are subject to admission control until it can do so within the limit specified by the Bandwidth-Allocation TLV. As specified in Section 6.2.5.2, the AN MAY attempt to correct the situation by sending a request to the NAS for an increased allocation of delegated bandwidth using the Bandwidth Reallocation Request message. Tom Taylor On 18/06/2014 8:34 AM, Roberta Maglione (robmgl) wrote: > Tom, Francois and All, > > Sorry for my late reply, comments inline. > >>I would suggest that the AN first attempts to increase the delegated bandwidth by sending to the NAS a >Bandwidth Reallocation >Request message. This is the behavior already specified (1) for the AN in the situation where the delegated bandwidth has not been >modified but > there is a new multicast join that would result in committing more > bandwidth than delegated. >>Would you agree? > > I agree with this approach. > >>If this attempt does not result in obtaining sufficient bandwidth to avoid any over-commitment, I would recommend retaining the behavior >currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast streams in order to bring bandwidth down to within the >new > limit, unless such action is required by local policy.) and align the > text of teh sections that are inconsistent with that. > > In opinion it would make sense to maintain the behavior currently > specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any multicast > streams in order to bring bandwidth down to within the >new limit, > unless such action is required by local policy), therefore I would > support the proposal of aligning all the sections with this behavior. > > Thanks > > Best Regards > > Roberta > > ---------- Forwarded message ---------- > From: *Francois Le Faucheur (flefauch)* > > Date: Wed, Jun 4, 2014 at 7:18 AM > Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16 > To: Tom Taylor > > Cc: "ancp@ietf.org " > > > > Tom and all, > > In the considered scenario where: > * the AN receives a new Bandwidth-Allocation TLV > * the AN has already committed more multicast bandwidth > I would suggest that the AN first attempts to increase the delegated > bandwidth by sending to the NAS a Bandwidth Reallocation Request > message. This is the behavior already specified (1) for the AN in the > situation where the delegated bandwidth has not been modified but there > is a new multicast join that would result in committing more bandwidth > than delegated. > Would you agree? > > If this attempt does not result in obtaining sufficient bandwidth to > avoid any over-commitment, I would recommend retaining the behavior > currently specified in 4.2.2 (ie "the AN SHOULD NOT discontinue any > multicast streams in order to bring bandwidth down to within the new > limit, unless such action is required by local policy.) and align the > text of teh sections that are inconsistent with that. > > > Francois > > > (1) section 6.2.5.2. : > “ > When the AN receives a join request, it > checks whether it has sufficient remaining uncommitted multicast > bandwidth on the access line to accommodate the new multicast flow. > If not, it MAY send a request to the NAS for an increased allocation > of delegated bandwidth using the Bandwidth Reallocation Request > message. The NAS MUST return a Bandwidth Transfer message indicating > whether it has granted the request and, if so, the new amount of > delegated bandwidth. > > " > > > On 4 Jun 2014, at 15:01, Tom Taylor > wrote: > > > Doing my AUTH48 review for draft-ietf-ancp-mc-extensions-16, I > noticed an inconsistency in treatment between three different cases > where the AN is assigned a value of multicast bandwidth that is lower > than the AN has already committed to a given subscriber. The question to > the Working Group is whether: > > (a) no change is needed; or > > (b) local policy should determine whether established connections > should be taken down to meet bandwidth limits set by the NAS in all > cases; or > > (c) established connections should never be taken down until > terminated by the subscriber (no provision for local policy in any case). > > > > The context in each instance is that the NAS has sent a multicast > bandwidth allocation to the AN. If the AN does not conform to that > allocation, the NAS does not have a correct view of the amount of > bandwidth available for admission control (e.g., of unicast services) at > the NAS itself. That should probably be fixed independently of the > question stated above. And, of course, the over-commitment at the AN > means that less bandwidth is available for services admitted at the NAS. > > > > Here are the three cases in question: > > > > Case 1: bandwidth assigned by Port Management message > > ===================================================== > > > > Receiver behaviour is described in Section 4.2.2. Note the provision > for local policy in the quoted text: > > > > "If the Port Management message contains a Bandwidth-Allocation TLV, > > the AN adopts this as the current value of its total multicast > > bandwidth limit for the target port. If the AN has already committed > > multicast bandwidth exceeding the amount given in the Bandwidth- > > Allocation TLV, the AN SHOULD NOT discontinue any multicast streams > > in order to bring bandwidth down to within the new limit, unless such > > action is required by local policy. However, the AN MUST NOT admit > > new multicast streams that are subject to admission control until it > > can do so within the limit specified by the Bandwidth-Allocation > > TLV." > > > > Case 2: bandwidth assigned by Bandwidth Transfer message > > ======================================================== > > > > AN behaviour as receiver is described in Section 4.6.2.2. There is no > provision for local policy: > > > > "If as the result of the procedures just described the AN determines > > that it has over-committed multicast bandwidth, it MUST NOT terminate > > any currently-active programs, but MUST NOT honour any more "join" > > requests until it is possible to do so within the limit set by its > > current value of delegated bandwidth." > > > > Case 3: bandwidth assigned by Delegated Bandwidth Query Response message > > ======================================================================== > > > > AN behaviour as receiver is described in Section 4.8.2.2. There is no > provision for local policy: > > > > "... If the AN has > > currently committed more than this amount to active programs, it MUST > > NOT cease replicating the flows concerned, but MUST NOT honour any > > more Join requests until possible to do so within the new limit." > > > > > > Tom Taylor > > > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www.ietf.org/mailman/listinfo/ancp > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp >