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

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
>