Subject: Re: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt

From: Toerless Eckert <[email-masked]>
Date: Mon, 16 Jul 2007 09:51:53 -0700

Thomas,

What you are asking for should already covered by what the draft
intends to introduce into the ANCP spec/requirements documents. 

It is perfectly valid to only use in an ANCP deployment the
profile you are implying: Provisioning on a per-subscriber basis
a whitelist (permitted channels) and blacklist (denied channels).

The draft just also includes requirements and functionality that
goes beyond what you are asking for, because not every deployment
may be able to statically split up the bandwidth to the home
devices with individual static bandwidth tools.

In fact, the draft tries to exactly provide the most simple
signaling for each of the varying deployment models we have
come to see being required.

Not quite sure on the authentication piece...

Cheers
    Toerless

On Mon, Jul 16, 2007 at 04:33:08PM +0200, Haag, T wrote:
> All,
> 
>  
> 
> Operating Multicast in conjunction with conditional access is very
> useful. But it is important to design such scenario in a less complex
> way.
> 
> I think simplifying the message flow by adding local decision control in
> the access node triggered by user authentication result archived by
> NAS/RADIUS decision when starting a session can be a way out to solve
> the estimated zapping performance issue, the complex maintenance issue
> and decouples user session from DSL Port authentication.  
> 
>  
> 
> Operation/Performance:
> 
> >From an operational standpoint these features/message flows must be
> simple and less complex in operation respectively maintenance and fault
> location. Sending each event by joining a group an ANCP message from the
> AN towards the NAS and receiving the policy decision implies to me a
> very busy zapping scenario (section 5.2.)
> 
>  
> 
> Also with respect to operational complexity I have some concerns
> regarding performance and maintenance. The main concern is regarding
> three elements (RADIUS, NAS, AN) participating in the dynamic IGMP
> triggered policy decision process. 
> 
>  
> 
> Authentication:
> 
> Running Start Accounting/ Stop Accounting can be done Port_ID related or
> user related (see fig.4, fig.5). Both methods require different features
> with respect to CPE/DSL/AN. Considering figure 6 implies to me that port
> based authentication is required for running multicast. If not RADIUS
> has to correlate between user ID and DSL Port ID.
> 
> In the document the reference is missing which authentication method the
> use cases require. Is it user/session based or is it port based?
> 
>  
> 
> I think the draft can be reworked according the comments still meeting
> basics of ANCP framework.
> 
>  
> 
> Regards,
> 
> Thomas

_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: "Haag, T" <[email-masked]>
Date: Thu, 19 Jul 2007 08:59:39 +0200

Toerless,

Thanks for your reply. Please see my answers inline:

Regards
Thomas
 
-----Ursprüngliche Nachricht-----
Von: Toerless Eckert [mailto:[email-masked]] 
Gesendet: Montag, 16. Juli 2007 18:52
An: Haag, Thomas
Cc: [email-masked]; [email-masked]
Betreff: Re: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt

Thomas,

>>TH: 
	I hoped it would cover but I think at the moment that is not the case. 
	Considering 4.1 Conditional access with local access node decision: 
	The listed requirements base on the assumption that the customer has 	to be authenticated somehow and to be known by the network. There has 	to be done a correlation between user credentials and DSL Port ID and 	Profile ID. The message flow in section 5.1.1 shows that the push 	profile command comes before DSL is in sync. So the customer cannot be 	authenticated before and send a RADIUS request. In other words I 	cannot push a profile to a port which the NAS does not know by a port 	up message except the case that NAS does local administration and 	configuration tasks for the AN.

>>TH: 
	Regarding my concerns of IGMP triggered request from AN to NAS I 	cannot share your view in having a simple signalling. This may be the 	case considering the message itself but not in operating large scale 	networks having thousands of AN per NAS having flows on a per IGMP 	request base. Also for fault location I don't see features to handle 	localize malfunction in that process because two network elements are 	involved which are not necessarily in the same operational domain. 

>>TH: 
	The draft assumes basic authentication requirements which can be read 	between the lines but not mentioned explicitly...  

Cheers
    Toerless