Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16

"Francois Le Faucheur (flefauch)" <flefauch@cisco.com> Wed, 04 June 2014 14:19 UTC

Return-Path: <flefauch@cisco.com>
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 <ancp@ietfa.amsl.com>; 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 <ancp@ietfa.amsl.com>; 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 <ancp@ietf.org>; 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)" <flefauch@cisco.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>
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" <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 <ancp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ancp/>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=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 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 <tom.taylor.stds@gmail.com> 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