Subject: Re: [ANCP] Comments on draft-lefaucheur-ancp-mc-extensions-01.txt

From: Tom Taylor <[email-masked]>
Date: Thu, 09 Apr 2009 15:47:05 -0400

Sorry for not responding sooner. I lost track of this one.

Shridhar Rao (shrirao) wrote:
> Hi Francois ,  et al , 
>  
> Queries/comments/observations :
> 
> 1. Program limit (I guess the number of multicast flows allowed for a
> subscriber ) - It is mentioned only once in the draft. There is no TLV
> mentioned for this. Is this to be configured locally on AN? 

[PTT] I suppose for consistency it should be provisioned from the NAS. We can 
add it on the next cycle.
> 
> 2. Timing of bandwidth reallocation and multicast admission control
> messages : if AN is waiting for a response to bandwidth reallocation can
> it send MCAST admission control in the middle (for the same subscriber
> port)? What happens if the NAS answers positively to the Mcast Admission
> control message (i.e. Access Control is OK) but responds negatively to
> the Bandwidth Allocation message (and thus AN has to reject flow).
> 
[PTT] The flow as presented in the document made the admission request follow 
the response to the bandwidth allocation request. I suppose, though, that they 
could proceed in parallel. The AN would then have to wait until both responses 
came back before admitting the flow.

> The draft mentions running a timer at AN after it sends a Multicast
> admission control but how long can we wait at AN for bandwidth
> reallocation response?

[PTT] It's a human factor thing, rather than a protocol issue, so I don't think 
we should specify it.
> 
> 3. What would happen when bandwidth delegation control TLV is turned on
> whereas the capability negotiated between AN and NAS through
> transactional multicast cap. is only 2 (meaning no bandwidth delegation
> but only admission control) ?
> 
> If the negotiated Capability is not equal to 3, then NAS should not send
> bandwidth delegation TLV to activate it.

[PTT] Agreed. I expect the AN should provide a protocol error response. We can 
add that.
> 
> 		
> 4. Discovering IPV6 multicast joins/leaves:  Perhaps it wouldn't hurt to
> replace "IGMP" by "IGMP/MLD" everywhere so we keep it clear.

[PTT] Thanks, will do.
> 
> 
> Thanks and regards,
> 
> -shridhar-
> 
> 	
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp
> 
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 10 Apr 2009 14:45:45 +0200

Tom, Shridhar,

> [PTT] The flow as presented in the document made the admission  
> request follow the response to the bandwidth allocation request. I  
> suppose, though, that they could proceed in parallel. The AN would  
> then have to wait until both responses came back before admitting  
> the flow.

In the scenario described by Shridhar (ie NAS says yes to Admission  
Control request but says No to Bandwidth Allocation message):
	* the AN knows what to do: reject the join because of insufficient  
bandwidth
	* But the NAS may be confused because it would assume that the  
actually succeeded. So far we have always kept the NAS fully aware of  
current join/leave state for a Grey Flow and I think we want to  
maintain that.

A simple solution to that it to mandate that the "admission control"  
decision is completed and positive before the ANCP Admission Control  
message is sent by the AN.
The call flow diagram (Fig 23) already shows it that way.
Looking back at section 4.1.1, I think the text pretty much implies  
that ordering already.
If that works for all, we can simply make the text more explicit about  
the strict ordering

I concur with all the other points/proposal.

Francois