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

Tom Taylor <tom.taylor.stds@gmail.com> Thu, 19 June 2014 02:09 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3681A018C for <ancp@ietfa.amsl.com>; 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 <ancp@ietfa.amsl.com>; 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 <ancp@ietf.org>; Wed, 18 Jun 2014 19:09:40 -0700 (PDT)
Received: by mail-ig0-f176.google.com with SMTP id c1so365028igq.15 for <ancp@ietf.org>; 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 <multiple recipients> (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 <tom.taylor.stds@gmail.com>
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)" <robmgl@cisco.com>, "ancp@ietf.org" <ancp@ietf.org>, "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
References: <538F1897.1090702@gmail.com> <8A31814E-05BC-41F2-8484-3977A9CDE122@cisco.com> <CAKOT5KpVzDQBR9KkHCZEPZ-TmAL0WBz4iYRTSNDVx=QXCeURYw@mail.gmail.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 <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: 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)* <flefauch@cisco.com
> <mailto:flefauch@cisco.com>>
> Date: Wed, Jun 4, 2014 at 7:18 AM
> Subject: Re: [ANCP] Inconsistency in draft-ietf-ancp-mc-extensions-16
> To: Tom Taylor <tom.taylor.stds@gmail.com
> <mailto:tom.taylor.stds@gmail.com>>
> Cc: "ancp@ietf.org <mailto:ancp@ietf.org>" <ancp@ietf.org
> <mailto: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 <tom.taylor.stds@gmail.com
> <mailto: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 <mailto:ANCP@ietf.org>
>  > https://www.ietf.org/mailman/listinfo/ancp
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org <mailto:ANCP@ietf.org>
> https://www.ietf.org/mailman/listinfo/ancp
>