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

Tom Taylor <tom.taylor.stds@gmail.com> Wed, 04 June 2014 13:01 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: ancp@ietfa.amsl.com
Delivered-To: ancp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F33711A01D5 for <ancp@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cFrMYUdHpWuc for <ancp@ietfa.amsl.com>; 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 <ancp@ietf.org>; Wed, 4 Jun 2014 06:01:24 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id hn18so6233737igb.6 for <ancp@ietf.org>; 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 with SMTP id u8mr6805645ige.1.1401886878030; Wed, 04 Jun 2014 06:01:18 -0700 (PDT)
Received: from [] (dsl-173-206-0-110.tor.primus.ca. []) by mx.google.com with ESMTPSA id y7sm44889500igl.13.2014. for <ancp@ietf.org> (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 <tom.taylor.stds@gmail.com>
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" <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 <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 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

Case 2: bandwidth assigned by Bandwidth Transfer message

AN behaviour as receiver is described in Section 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 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