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

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