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

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)* <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
>