Subject: Re: [ANCP] DOA (was: ANCP Framework update)

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 3 Nov 2008 14:53:28 +0100

Alan, all,
 
Based on the feedback I am now updating the framework - I will upload a
revised version later today. It captures the notion of Delegation of
Authority, and explains how "Bandwidth Delegation" is one form of such
authoritty delegation.
 
See additional feedback inline.

      *  In case of Admission Control with AN Bandwidth Delegation, the
         NAS (possibly with interactions with a Policy Server) manages
         total bandwidth for video admission, performs unicast admission
         control and uses ANCP to delegate a certain amount of bandwidth
         for some multicast flows to the Access Node.  In this scenario,
         upon receiving a join to a multicast flow which matches an
         entry in the White or Grey List, the AN must perform the
         necessary bandwidth admission control check for the new
         multicast flow, before starting the multicast flow replication.

{A.K}--> The AN "MAY" perform the necessary bandwidth adm ctl check, i
think this is more a deployment issue where some Service Providers may
decide that they allocate the max required b/w to satisfy all services
within the White/Grey lists. So if i say that i allocate 16MB od b/w
which should be sufficent for SD adn HD type TV channels, why would i
need to always check for necessary bandwidth, this is not required, and
should be a MAY only.  

<Sven> If sufficient resources are set aside to make sure that under
normal circumstances bandwdith is always available, then I agree that
Admission Control would never have to reject a request. However, the
functionality is there to protect against abnormal circumstances, e.g.
if a rogue device in the home network starts sending IGMP reports. The
home network - just like the access/aggregation network - need to be
protected against that. Hence, if bandwdith delegation is used, I
consider the Access Node must effectively perform Admission Control.
 
If you don't want to perform admission control on the Access Node, then
I would put the entries in a White List, and indicate that Bandwidth
Delegation does not apply.

   o  Upon receiving a join to a multicast flow which matches the White
      List whose and for which Bandwidth Delegation is required, the AN
      must perform the necessary bandwidth admission control check for
      the new flow before starting the multicast flow replication. 
 
{A.K}--> same as my above comment, this is a MAY. 
 
   o  In case of Admission Control with AN Bandwidth Delegation, the AN
      must support using ANCP to query the NAS to request additional
      delegated multicast bandwidth on a given Access Port; the AN
      should be able to specify both the minimum and the preferred
      amount of additional multicast bandwidth requested. 
 
{A.K} I see this as more the NAS informing the AN of additional b/w
available for a given service type, not the AN requesting additional
b/w.  
 
<Sven> Yes, I think that's another interpretation.
 
   o  In case of Admission Control with AN Bandwidth Delegation, upon
      receiving a Bandwidth Delegation Request from the NAS querying or
      instructing to decrease the delegated multicast bandwidth on a
      given Access Port, the AN must support using ANCP to send a
      Bandwidth Delegation Response indicating the new delegated
      multicast bandwidth. 
 
{A.K}--> wait so here you are saying the NAS will request, same as aboev
comment, this is more about the NAS informing/delegating the AN on what
services it can make local decisions upon and that a given service may
have this associated b/w. I think we just need to make this clearer
here. 
 
<Sven> This is about the case where the NAS needs to revoke part of the
delegated bandwidth from the AN. Some of that bandwidth may however be
in use by multicast services. That's why the Access Node needs to reply
to the NAS, indicating how much of the delegated bandwidth can be
returned to the NAS without impacting multicast services that are
currently running. I will clarify this in the requirement.
 
   o  In case of Admission Control with AN Bandwidth Delegation, the AN
      must support using ANCP to send a Bandwidth Release message to the
      NAS in order to release unused delegated multicast bandwidth on a
      given Access Port. 
 
{A.K}--> So this i do not see how this would work if the NAS has
delegated a "given amount of b/w" to the AN, then the AN maintains this
delegated b/w CAP regardless if it is used or not. The AN may inform the
NAS of what b/w is currently consumed from the delageted b/w but nothing
more than this, so i do not agree with this requirement.  
 
<Sven> This requirement is put in place to allow the AN to return some
unused delegated bandwidth after a certain amount of time. This could be
considered an optimization. If people believe it should be dropped, then
I will do so.
 
Regards,
Sven
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Peter Arberg <[email-masked]>
Date: Mon, 3 Nov 2008 10:00:57 -0800

Hi Sven,

one comments inline for your first item.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of OOGHE Sven
Sent: 3. november 2008 05:53
To: Alan Kavanagh; [email-masked]
Subject: Re: [ANCP] DOA (was: ANCP Framework update)

Alan, all,

Based on the feedback I am now updating the framework - I will upload a revised version later today. It captures the notion of Delegation of Authority, and explains how "Bandwidth Delegation" is one form of such authoritty delegation.

I do not see why the AN  must perform the admission check for joins which match
the Grey list.  The Grey list have to be communicated to the NAS for decision, the
NAS could possibly increase the BW delegation when aa Grey list join is received,
so having the requirement as above is not accurate in my mind.

I would prefer you just said something like:
.... In this scenario, upon receiving a request for a multicast flow replication which
matches an entry in the White or Grey List, the AN must perform the necessary ...

I think by changing the "join" to "request", then for the White list the request is
the actual "join", but the "request" for the Grey list is the communication trigger
from the NAS.

cheers,
Peter

 {A.K}--> The AN "MAY" perform the necessary bandwidth adm ctl check, i think this is more a deployment issue where some Service Providers may decide that they allocate the max required b/w to satisfy all services within the White/Grey lists. So if i say that i allocate 16MB od b/w which should be sufficent for SD adn HD type TV channels, why would i need to always check for necessary bandwidth, this is not required, and should be a MAY only.

<Sven> If sufficient resources are set aside to make sure that under normal circumstances bandwdith is always available, then I agree that Admission Control would never have to reject a request. However, the functionality is there to protect against abnormal circumstances, e.g. if a rogue device in the home network starts sending IGMP reports. The home network - just like the access/aggregation network - need to be protected against that. Hence, if bandwdith delegation is used, I consider the Access Node must effectively perform Admission Control.

If you don't want to perform admission control on the Access Node, then I would put the entries in a White List, and indicate that Bandwidth Delegation does not apply.

{A.K} I see this as more the NAS informing the AN of additional b/w available for a given service type, not the AN requesting additional b/w.

{A.K}--> wait so here you are saying the NAS will request, same as aboev comment, this is more about the NAS informing/delegating the AN on what services it can make local decisions upon and that a given service may have this associated b/w. I think we just need to make this clearer here.

<Sven> This is about the case where the NAS needs to revoke part of the delegated bandwidth from the AN. Some of that bandwidth may however be in use by multicast services. That's why the Access Node needs to reply to the NAS, indicating how much of the delegated bandwidth can be returned to the NAS without impacting multicast services that are currently running. I will clarify this in the requirement.

{A.K}--> So this i do not see how this would work if the NAS has delegated a "given amount of b/w" to the AN, then the AN maintains this delegated b/w CAP regardless if it is used or not. The AN may inform the NAS of what b/w is currently consumed from the delageted b/w but nothing more than this, so i do not agree with this requirement.

<Sven> This requirement is put in place to allow the AN to return some unused delegated bandwidth after a certain amount of time. This could be considered an optimization. If people believe it should be dropped, then I will do so.

Regards,
Sven

---

From: Tom Taylor <[email-masked]>
Date: Mon, 03 Nov 2008 19:08:27 -0500

My comments below, marked with [PTT].

> Delegation does not apply.

[PTT] Basically I support this view. As far as I am concerned, bandwidth 
delegation is either active or not active. If bandwidth delegation is active, 
the checks are MUSTs, by definition of the capability. You MAY activate 
bandwidth delegation.
> {A.K}--> same as my above comment, this is a MAY. 

[PTT] Again, by definition of bandwidth delegation, it is a MUST. I would 
rephrase the requirement slightly:

         "Upon receiving a join to a multicast flow which matches the White
         List when Bandwidth Delegation has been activated, the AN
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         MUST perform the necessary bandwidth admission control check for
         the new flow before starting the multicast flow replication.
> <Sven> Yes, I think that's another interpretation.

[PTT] No, it is a more active behaviour on the part of the AN. The AN determines 
what additional multicast bandwidth it needs and asks for it.
> currently running. I will clarify this in the requirement.

[PTT] Agreed.
> considered an optimization. If people believe it should be dropped, then

[PTT] I think it should be kept. Release can be governed by policy. Idle time is 
certainly one possibility, but another is that the AN releases extra bandwidth 
that it requested and was granted previously.
>  
> Regards,
> Sven
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 4 Nov 2008 09:19:53 +0100

Hi Peter,
 
>> matches an entry in the White or Grey List, the AN must perform the
necessary ...
 
This makes sense to me. I will update.
 
Regards,
Sven

From: Peter Arberg [mailto:[email-masked]] 
Sent: maandag 3 november 2008 19:01
To: OOGHE Sven; Alan Kavanagh; [email-masked]
Subject: RE: Re: [ANCP] DOA (was: ANCP Framework update)

Hi Sven,

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of OOGHE Sven
	Sent: 3. november 2008 05:53
	To: Alan Kavanagh; [email-masked]
	Subject: Re: [ANCP] DOA (was: ANCP Framework update)

	Alan, all,
	 
	Based on the feedback I am now updating the framework - I will
upload a revised version later today. It captures the notion of
Delegation of Authority, and explains how "Bandwidth Delegation" is one
form of such authoritty delegation.

	      *  In case of Admission Control with AN Bandwidth
Delegation, the
	         NAS (possibly with interactions with a Policy Server)
manages
	         total bandwidth for video admission, performs unicast
admission
	         control and uses ANCP to delegate a certain amount of
bandwidth
	         for some multicast flows to the Access Node.  In this
scenario,
	         upon receiving a join to a multicast flow which matches
an
	         entry in the White or Grey List, the AN must perform
the
	         necessary bandwidth admission control check for the new
	         multicast flow, before starting the multicast flow
replication. 

I do not see why the AN  must perform the admission check for joins
which match
the Grey list.  The Grey list have to be communicated to the NAS for
decision, the
NAS could possibly increase the BW delegation when aa Grey list join is
received, 
so having the requirement as above is not accurate in my mind.
 
I would prefer you just said something like:
.... In this scenario, upon receiving a request for a multicast flow
replication which 
matches an entry in the White or Grey List, the AN must perform the
necessary ...

I think by changing the "join" to "request", then for the White list the
request is 
the actual "join", but the "request" for the Grey list is the
communication trigger
from the NAS.
 
cheers,
Peter

	 {A.K}--> The AN "MAY" perform the necessary bandwidth adm ctl
check, i think this is more a deployment issue where some Service
Providers may decide that they allocate the max required b/w to satisfy
all services within the White/Grey lists. So if i say that i allocate
16MB od b/w which should be sufficent for SD adn HD type TV channels,
why would i need to always check for necessary bandwidth, this is not
required, and should be a MAY only.  

	<Sven> If sufficient resources are set aside to make sure that
under normal circumstances bandwdith is always available, then I agree
that Admission Control would never have to reject a request. However,
the functionality is there to protect against abnormal circumstances,
e.g. if a rogue device in the home network starts sending IGMP reports.
The home network - just like the access/aggregation network - need to be
protected against that. Hence, if bandwdith delegation is used, I
consider the Access Node must effectively perform Admission Control.
	 
	If you don't want to perform admission control on the Access
Node, then I would put the entries in a White List, and indicate that
Bandwidth Delegation does not apply.

	   o  Upon receiving a join to a multicast flow which matches
the White
	      List whose and for which Bandwidth Delegation is required,
the AN
	      must perform the necessary bandwidth admission control
check for
	      the new flow before starting the multicast flow
replication. 

	   o  In case of Admission Control with AN Bandwidth Delegation,
the AN
	      must support using ANCP to query the NAS to request
additional
	      delegated multicast bandwidth on a given Access Port; the
AN
	      should be able to specify both the minimum and the
preferred
	      amount of additional multicast bandwidth requested. 
	 
	{A.K} I see this as more the NAS informing the AN of additional
b/w available for a given service type, not the AN requesting additional
b/w.  

	   o  In case of Admission Control with AN Bandwidth Delegation,
upon
	      receiving a Bandwidth Delegation Request from the NAS
querying or
	      instructing to decrease the delegated multicast bandwidth
on a
	      given Access Port, the AN must support using ANCP to send
a
	      Bandwidth Delegation Response indicating the new delegated
	      multicast bandwidth. 
	 
	{A.K}--> wait so here you are saying the NAS will request, same
as aboev comment, this is more about the NAS informing/delegating the AN
on what services it can make local decisions upon and that a given
service may have this associated b/w. I think we just need to make this
clearer here. 
	 
	<Sven> This is about the case where the NAS needs to revoke part
of the delegated bandwidth from the AN. Some of that bandwidth may
however be in use by multicast services. That's why the Access Node
needs to reply to the NAS, indicating how much of the delegated
bandwidth can be returned to the NAS without impacting multicast
services that are currently running. I will clarify this in the
requirement.
	 
	   o  In case of Admission Control with AN Bandwidth Delegation,
the AN
	      must support using ANCP to send a Bandwidth Release
message to the
	      NAS in order to release unused delegated multicast
bandwidth on a
	      given Access Port. 

	<Sven> This requirement is put in place to allow the AN to
return some unused delegated bandwidth after a certain amount of time.
This could be considered an optimization. If people believe it should be
dropped, then I will do so.
	 
	Regards,
	Sven

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 4 Nov 2008 09:28:32 +0100

Tom,

See inline. 

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: dinsdag 4 november 2008 1:08
To: OOGHE Sven
Cc: Alan Kavanagh; [email-masked]
Subject: Re: [ANCP] DOA

OOGHE Sven wrote:
> Alan, all,
>  
> Based on the feedback I am now updating the framework - I will upload 
> a revised version later today. It captures the notion of Delegation of

admission
bandwidth
scenario,
replication.

> need to always check for necessary bandwidth, this is not required, 
> and should be a MAY only.
> 
>  

> If you don't want to perform admission control on the Access Node, 
> then I would put the entries in a White List, and indicate that 

[PTT] Basically I support this view. As far as I am concerned, bandwidth
delegation is either active or not active. If bandwidth delegation is
active, the checks are MUSTs, by definition of the capability. You MAY
activate bandwidth delegation.

<Sven> I agree.

> {A.K}--> same as my above comment, this is a MAY. 

[PTT] Again, by definition of bandwidth delegation, it is a MUST. I
would rephrase the requirement slightly:

         "Upon receiving a join to a multicast flow which matches the
White
         List when Bandwidth Delegation has been activated, the AN
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         MUST perform the necessary bandwidth admission control check
for
         the new flow before starting the multicast flow replication.

<Sven> I will reword throughout the document. I prefer changing to
"...when Bandwith Delegation is used..." to capture that the delegated
bandwidth could change over time. ("activated" might be interpreted by
some people as referring to all of the access line bandwidth).

> <Sven> Yes, I think that's another interpretation.

[PTT] No, it is a more active behaviour on the part of the AN. The AN
determines what additional multicast bandwidth it needs and asks for it.

<Sven> The net result is the same though. I think this is a matter of
who takes initiative.

> {A.K}--> wait so here you are saying the NAS will request, same as 
> aboev comment, this is more about the NAS informing/delegating the AN 
> service may have this associated b/w. I think we just need to make 
> this clearer here.
>  
> <Sven> This is about the case where the NAS needs to revoke part of 
> the delegated bandwidth from the AN. Some of that bandwidth may 
requirement.

[PTT] Agreed.
> delegated a "given amount of b/w" to the AN, then the AN maintains 
> this delegated b/w CAP regardless if it is used or not. The AN may 
> inform the NAS of what b/w is currently consumed from the delageted 
> b/w but nothing more than this, so i do not agree with this
requirement.

> unused delegated bandwidth after a certain amount of time. This could 
> be considered an optimization. If people believe it should be dropped,

> then I will do so.

[PTT] I think it should be kept. Release can be governed by policy. Idle
time is certainly one possibility, but another is that the AN releases
extra bandwidth that it requested and was granted previously.

---

From: "Reith, Lothar" <[email-masked]>
Date: Tue, 4 Nov 2008 10:07:57 +0100

Sven,

 
<Lothar> I agree with Tom, that it is a more active behaviour on the part of the AN. The AN determines what additional multicast bandwidth it needs that exceeds the delegated bandwidth for which the AN has received a "delegation of authority to perform admission control on a subset of the actual net data rate". 
(I like this "blue formulation" proposed by Sven in a recent mail). In case of  the demand for multicast traffic exceeding the delegated bandwidth, the AN must (or  may??) request the NAS for delegation of additional bandwidth (or even better: for delegation of authority to perform admission control on an extended subset of the actual net data rate.
 
Best Regards, Lothar Reith
Detecon International GmbH (Deutsche Telekom Group)

Von: [email-masked] im Auftrag von OOGHE Sven
Gesendet: Di 04.11.2008 09:28
An: Tom Taylor
Cc: [email-masked]
Betreff: Re: [ANCP] DOA

Tom,

See inline.

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]]
Sent: dinsdag 4 november 2008 1:08
To: OOGHE Sven
Cc: Alan Kavanagh; [email-masked]
Subject: Re: [ANCP] DOA

admission
bandwidth
scenario,
replication.

<Sven> I agree.

requirement.

[PTT] Agreed.
requirement.

---

From: "OOGHE Sven" <[email-masked]>
Date: Tue, 4 Nov 2008 10:55:10 +0100

Lothar,
 
I'm in line with the formulation in blue below. Version 07 has been
updated to reflect this.
 
Regards,
Sven

From: Reith, Lothar [mailto:[email-masked]] 
Sent: dinsdag 4 november 2008 10:08
To: OOGHE Sven; Tom Taylor
Cc: [email-masked]
Subject: AW: [ANCP] DOA

Sven,
 
regarding the following point I rather agree with Tom, but would suggest

 
<Lothar> I agree with Tom, that it is a more active behaviour on the
part of the AN. The AN determines what additional multicast bandwidth it
needs that exceeds the delegated bandwidth for which the AN has received
a "delegation of authority to perform admission control on a subset of
the actual net data rate". 
(I like this "blue formulation" proposed by Sven in a recent mail). In
case of  the demand for multicast traffic exceeding the delegated
bandwidth, the AN must (or  may??) request the NAS for delegation of
additional bandwidth (or even better: for delegation of authority to
perform admission control on an extended subset of the actual net data
rate.

Tom,

See inline.

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]]
Sent: dinsdag 4 november 2008 1:08
To: OOGHE Sven
Cc: Alan Kavanagh; [email-masked]
Subject: Re: [ANCP] DOA

admission
bandwidth
scenario,
replication.

<Sven> I agree.

requirement.

[PTT] Agreed.
requirement.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 5 Nov 2008 13:49:14 -0500

Hi Sven
 
My response in line below {A.K.}, sorry for the BOLD text  Sven ;-)

From: OOGHE Sven [mailto:[email-masked]] 
Sent: November 3, 2008 8:53 AM
To: Alan Kavanagh; [email-masked]
Subject: RE: [ANCP] DOA (was: ANCP Framework update)

Alan, all,

 
{A.K}--> This really is a deployment scenario here, one of many possible
scenarios. I could also say that the subscriber receives 2 multicast
streams, so my question here is again, is the AN aware of all bandwidth
available on the first mile link? And what about other unicast services
running paralles with this??? This is why im saying that the bandwidth
check is a May/Should not a MUST. For the Rogue device its nothing we
should consider, you could just see it as another STB/host initiating a
multicast stream, or the same host doing x number of multicast streams,
for example Picture-in-Picture ;-)

{A.K}--> Agree on this, it should be captured in the text to reflect
that two options are possible. I would also clarify that this bandwidth
admission control is restricted to multicast traffic only.

 

 
{A.K}--> Agree so both options should be captured in the text to reflect
thus! 

 
 
{A.K}--> and my point here was that are we doing this for all service
types, unicast and multicast???? because its just multicast and that is
what i was asking you to clarify, so i think you see the point, thanks. 

 
 
{A.K} So i can understand why we want this but i dont see the benefit of
it, for example, if the user has NOT SENT any IGMP_Report for a join to
a given multicast address/channel.....and we take this delegated b/w
away, when the subscriber then sends an IGMP_Report to join a given
multicast address........how would we handle this???? NAS now needs to
be involved to re allocate/delegate the b/w.....AN must
wait....subscriber must wait....etc...i see too many issues with
endorsing this scenario for it to be beneficial.
 
Regards,
Sven

---

From: Tom Taylor <[email-masked]>
Date: Wed, 05 Nov 2008 14:12:51 -0500

Global comment: bandwidth delegation applies to multicast service only. There is 
no advantage to doing unicast admission control at the AN.

Alan Kavanagh wrote:
> Hi Sven
>  
> My response in line below {A.K.}, sorry for the *BOLD* text  Sven ;-)
> 
> *From:* OOGHE Sven [mailto:[email-masked]]
> *Sent:* November 3, 2008 8:53 AM
> *To:* Alan Kavanagh; [email-masked]
> *Subject:* RE: [ANCP] DOA (was: ANCP Framework update)
> 
> Alan, all,
>  
> /      *  In case of Admission Control with AN Bandwidth Delegation, the
>          multicast flow, before starting the multicast flow replication./ 
> // 
> /{A.K}--> The AN "MAY" perform the necessary bandwidth adm ctl check, i 
> should be a MAY only. / 
> *<Sven> If sufficient resources are set aside to make sure that under 
> consider the Access Node must effectively perform Admission Control.*
> ** 
> *_{A.K}--> This really is a deployment scenario here, one of many 
> possible scenarios. I could also say that the subscriber receives 2 
> multicast streams, so my question here is again, is the AN aware of all 
> bandwidth available on the first mile link? And what about other unicast 
> services running paralles with this??? This is why im saying that the 
> bandwidth check is a May/Should not a MUST. For the Rogue device its 
> nothing we should consider, you could just see it as another STB/host 
> initiating a multicast stream, or the same host doing x number of 
> multicast streams, for example Picture-in-Picture ;-)_*
> ** 
> *If you don't want to perform admission control on the Access Node, then 
> Delegation does not apply.*
>  
> _*{A.K}--> Agree on this, it should be captured in the text to reflect 
> admission control is restricted to multicast traffic only.*_
>  
> /   o  Upon receiving a join to a multicast flow which matches the White
>       the new flow before starting the multicast flow replication./ 
> // 
> /{A.K}--> same as my above comment, this is a MAY./ 
>  
> available for a given service type, not the AN requesting additional b/w.  
>  
> *<Sven> Yes, I think that's another interpretation.* 
> ** 
> *_{A.K}--> Agree so both options should be captured in the text to 
> reflect thus! _*
> 
> have this associated b/w. I think we just need to make this clearer here. 
>  
> *<Sven> This is about the case where the NAS needs to revoke part of the 
> currently running. I will clarify this in the requirement.* 
>  
> _*{A.K}--> and my point here was that are we doing this for all service 
> what i was asking you to clarify, so i think you see the point, thanks.* _
>  
> *<Sven> This requirement is put in place to allow the AN to return some 
> I will do so.* 
> *_{A.K} So i can understand why we want this but i dont see the benefit 
> of it, for example, if the user has NOT SENT any IGMP_Report for a join 
> to a given multicast address/channel.....and we take this delegated b/w 
> endorsing this scenario for it to be beneficial._*
> ** 
> *Regards,*
> *Sven*
> 
>

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 5 Nov 2008 14:33:26 -0500

My responses inline!!! 

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: November 3, 2008 7:08 PM
To: OOGHE Sven
Cc: Alan Kavanagh; [email-masked]
Subject: Re: [ANCP] DOA

admission
bandwidth
scenario,
replication.

{A.K.} I still see this as a deployment issue not an association of ANCP
mandates that we MUST do this, that is a bad choice imho.

{A.K}--> So if I look at this a bit differently, why would we reauire
that the AN MUST check for b/w for a service on the White List.....I
don't see any case that is explicitly requiring I MUST have the AN
check......everytime I see an IGMP_ Report requesting a join to a
service on the white list.....that to me is questionable.

[PTT] No, it is a more active behaviour on the part of the AN. The AN
determines what additional multicast bandwidth it needs and asks for it.
{A.K}In large I can agree with this, but I don't see how the AN would
know what additional b/w to request in the first place, so im assuming
you mean here that it checks that a given service request is not
granted....due to b/w and should send the request to the NAS
anyway......i don't see the "AN determining what additional b/w is
required".
requirement.

[PTT] Agreed.
requirement.

[PTT] I think it should be kept. Release can be governed by policy. Idle
time is certainly one possibility, but another is that the AN releases
extra bandwidth that it requested and was granted previously.
{A.K.} I can see a trade off here for a user experience !!! So I think
we should be mindful on what we see as being deployable and what is more
a "nice to have" feature.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 05 Nov 2008 15:23:37 -0500

We are not mandating the MUST for ANCP in general, only if the multicast 
bandwidth delegation feature has been activated. The deployment issue is whether 
the operator deploys ANs with this capability and whether this feature is 
activated. But the definition of the feature/capability is that the AN does the 
check.

> mandates that we MUST do this, that is a bad choice imho.
...