Subject: [ANCP] Multicast Accounting

From: Stefaan DE CNODDER <[email-masked]>
Date: Tue, 08 Jan 2008 14:13:16 +0100

Hi,

At the last IETF meeting, there was a discussion about multicast 
accounting is supposed to work.  Currently, the framework document 
mentions 2 options in section 3.4.3:

---
    o  The AN keeps track of when replication starts or stops, and
       generates the time and/or volume based accounting information per
       Access Loop and per multicast flow, before sending it to a central
       accounting system for logging.  Since the AN communicates with
       this accounting system directly, the approach doesn't require the
       use of ANCP.  It is therefore beyond the scope of this document;

    o  The AN keeps track of when replication starts or stops, and
       reports this information to the NAS for further processing.  In
       this case, ANCP can be used to send the information from the AN to
       the NAS.  This can be done with the Information Report message.
       The NAS can then generate the appropriate time and/or volume
       accounting information per Access Loop and per multicast flow, to
       be sent to the accounting system.  The ANCP requirements to
       support this approach are specified in this document.
---

Is everyone Ok with this?  Is more needed, or less, or more 
clarrification on what it means?

Personally, it looks Ok to me but I have a comment for extra 
clarrification on the first bullet: Does it require any impact on the 
ANCP protocol?  For the second bullet, I would expect that in a white 
list entry there is a flag indicating whether accounting is needed or 
not.  Is something similar needed to support the first bullet in a white 
list entry (e.g., need for time and/or volume based accounting with the 
IP address of acct server)?  Whatever is fine for me, but it has to be 
decided.

regards,
Stefaan

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

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 14 Jan 2008 13:46:50 +0100

Hi Stefaan,

it doesn't seem that we have agreement on this text, and an alternative
proposal is presented in
http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html.

---snip---
in Section "3.4.3 Multicast Accounting"

replace:
"
o The AN keeps track of when replication starts or stops, and
reports this information to the NAS for further processing. In
this case, ANCP can be used to send the information from the AN to
the NAS. This can be done with the Information Report message.
The NAS can then generate the appropriate time and/or volume
accounting information per Access Loop and per multicast flow, to
be sent to the accounting system. The ANCP requirements to
support this approach are specified in this document.
"
by
"
o The AN keeps track of when replication for a given multicast flow
starts or stops and then the AN can convey time and/or volume
information to
the NAS for further processing. This approach relies on ANCP and is
discussed below. 

---snip---

In general for accounting to be of use it needs to be fairly accurate,
hence it is highly desirable for the access node to present to the NAS
the time and/or volume information for further processing. Granted that
if access nodes are not capable of providing such information, they will
only signal simple start/stop events. I however don't see why the
framework and protocol should be limited only to this latter variant. Is
there a reason why the proposal presented by Francois is inadequate?

Regards,
Woj.

> -----Original Message-----
> From: Stefaan DE CNODDER 
> [mailto:[email-masked]] 
> Sent: 08 January 2008 14:13
> To: [email-masked]
> Subject: [ANCP] Multicast Accounting
> 
> 
> Hi,
> 
> At the last IETF meeting, there was a discussion about 
> multicast accounting is supposed to work.  Currently, the 
> framework document mentions 2 options in section 3.4.3:
> 
> ---
> clarrification on the first bullet: Does it require any 
> impact on the ANCP protocol?  For the second bullet, I would 
> expect that in a white list entry there is a flag indicating 
> whether accounting is needed or not.  Is something similar 
> needed to support the first bullet in a white list entry 
> (e.g., need for time and/or volume based accounting with the 
> IP address of acct server)?  Whatever is fine for me, but it 
> has to be decided.
> 
> regards,
> Stefaan
> 
> 
>

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 14 Jan 2008 14:00:12 +0100

Woj,

The framework draft currently does not exclude anything.  Both options 
are possible.  The case where the AN is counting the packets and 
measuring the time is also in the framework and this information can be 
sent directly from the AN to the accounting server (which might be the 
NAS itself of course) with another protocol than ANCP like Radius for 
instance.  Actually, section 3.4.3 has to be read as whole and not just 
the part I copy/pasted in the email.  The question is basically if this 
section is Ok for everyone.

 From a protocol point of view, this means that each entry in the white 
list has the following information: indication whether accounting is 
needed or not, and if needed, whehter the accounting is performed by the 
NAS or by the AN.  In the latter case, also the IP address of the 
accounting servers are specified.

regards,
Stefaan

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 14 Jan 2008 14:22:26 +0100

Stefaan,

then you're saying that you agree with Francois' proposal for Section
3.4.3?

-Woj. 

> Sent: 14 January 2008 14:00
> To: Wojciech Dec (wdec)
> Cc: [email-masked]
> Subject: Re: [ANCP] Multicast Accounting
> 
> 
> Woj,
> 
> The framework draft currently does not exclude anything.  
> Both options are possible.  The case where the AN is counting 
> the packets and measuring the time is also in the framework 
> and this information can be sent directly from the AN to the 
> accounting server (which might be the NAS itself of course) 
> with another protocol than ANCP like Radius for instance.  
> Actually, section 3.4.3 has to be read as whole and not just 
> the part I copy/pasted in the email.  The question is 
> basically if this section is Ok for everyone.
> 
>  From a protocol point of view, this means that each entry in 
> the white list has the following information: indication 
> whether accounting is needed or not, and if needed, whehter 
> the accounting is performed by the NAS or by the AN.  In the 
> latter case, also the IP address of the accounting servers 
> are specified.
> 
> regards,
> Stefaan
> 
> 
> > it doesn't seem that we have agreement on this text, and an 
> > alternative proposal is presented in 
> > o The AN keeps track of when replication starts or stops, 
> and reports 
> > this information to the NAS for further processing. In this 
> case, ANCP 
> > can be used to send the information from the AN to the NAS. 
> This can 
> > be done with the Information Report message.
> > accounting information per Access Loop and per multicast 
> flow, to be 
> > sent to the accounting system. The ANCP requirements to 
> support this 
> > information to the NAS for further processing. This 
> approach relies on 
> > ANCP and is discussed below.
> > 
> > ---snip---
> > 
> > the time and/or volume information for further processing. Granted 
> > that if access nodes are not capable of providing such information, 
> > they will only signal simple start/stop events. I however don't see 
> > why the framework and protocol should be limited only to 
> this latter 
> > variant. Is there a reason why the proposal presented by 
> Francois is inadequate?
> > 
> > Regards,
> > Woj.
> > 
> > 
> >>       generates the time and/or volume based accounting 
> information 
> >>per
> >>       this accounting system directly, the approach 
> doesn't require 
> >>the
> >>       this case, ANCP can be used to send the information 
> from the AN 
> >>to
> >>       accounting information per Access Loop and per 
> multicast flow, 
> >>to
> impact on the 
> >>not.  Is something similar needed to support the first bullet in a 
> >>white list entry (e.g., need for time and/or volume based 
> accounting 
> >>with the IP address of acct server)?  Whatever is fine for 
> me, but it 
> >>has to be decided.
> >>
> >>regards,
> >>Stefaan
> >>
> >>
> >>

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 14 Jan 2008 14:56:24 +0100

Woj,

 From a functional point of view it is Ok but the comment was to change 
the second bullet of section 3.4.3 into what is already in the first 
bullet of section 3.4.3 (although there it is generalised that the AN 
can send this info to any acct server and not just the NAS).

My question is whether we can remove the first bullet.  If the AN has to 
do the multicast accounting, then it can also do the unicast accounting 
and I thought ANCP was about moving all of this to the NAS.  And if the 
AN can do the unicast accounting, then it can do the appropriate QoS 
queueing as well....  Anyhow, I am fine with the current text in the 
framework and if we believe that the comment below was on the wrong 
bullet, then it is all Ok.

I have more problems with the capabilities negotiated with ANCP. 
Implementation will not support all or nothing but that is what is 
negotiated in the capabilities.  Have the capabilities to be more 
fine-grained or should support/non-support be reflected in error codes?

regards,
Stefaan

Wojciech Dec (wdec) wrote:

>>support this 
>>>approach are specified in this document.
>>>"
>>>by
>>>"
>>>In general for accounting to be of use it needs to be 
>>
>>fairly accurate, 
>>
>>>hence it is highly desirable for the access node to present 
>>
>>to the NAS 
>>
>>>>      accounting system for logging.  Since the AN 
>>
>>communicates with
>>
>>>>      reports this information to the NAS for further 
>>
>>processing.  In
>>
>>>>      the NAS.  This can be done with the Information 
>>
>>Report message.
>>
>>>>ANCP protocol?  For the second bullet, I would expect that 
>>
>>in a white 
>>
>>>>list entry there is a flag indicating whether accounting is 
>>
>>needed or 
>>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 14 Jan 2008 16:39:10 +0100

Stefaan,

I'll let Francois & Roberta comment on whether their proposal was to
obly replace a bullet in Sec3.4.3, or both of them. In either case
however, the proposal is very clear in removing the restrcition that
mcast traffic accounting is out of scope, hence based on that reading
the *current* framework text is not agreed to.

As for the philosphy behind ANCP, it's useful to keep in mind the black
box principle: ANCP should provide functionality to make the combination
of NAS + L2 Access-Node look like one black box. Hence, irrespective of
whether the AN can or cannot do unicat accounting, for the purpose of
ANCP and multicast it appears rather useful to address the scenario
where an AN *is* able to provide detailed mcast replication stats per
port, beyond the basic case where it isn't.

In terms of capabilities, such detailed stat reports could indeed be the
subject of an additional negotiated capability, but on this I'd like the
WG to provide some comments. 
- Does anyone forsee a use for only simple start/stop mcast ANCP
accounting messages vs start/stop accounting with detailed info? 
- And does anyone forsee a deployment model where a mix of the modes is
used, eg AN1 supporting detailed-mode and AN2 supporting
not-detailed-mode?

Regards,
Woj.

> Sent: 14 January 2008 14:56
> To: Wojciech Dec (wdec)
> Cc: [email-masked]
>  From a functional point of view it is Ok but the comment was 
> to change the second bullet of section 3.4.3 into what is 
> already in the first bullet of section 3.4.3 (although there 
> it is generalised that the AN can send this info to any acct 
> server and not just the NAS).
> 
> My question is whether we can remove the first bullet.  If 
> the AN has to do the multicast accounting, then it can also 
> do the unicast accounting and I thought ANCP was about moving 
> all of this to the NAS.  And if the AN can do the unicast 
> accounting, then it can do the appropriate QoS queueing as 
> well....  Anyhow, I am fine with the current text in the 
> framework and if we believe that the comment below was on the 
> wrong bullet, then it is all Ok.
> 
> Implementation will not support all or nothing but that is 
> what is negotiated in the capabilities.  Have the 
> capabilities to be more fine-grained or should 
> support/non-support be reflected in error codes?
> 
> regards,
> Stefaan
> 
> 
> >>Both options are possible.  The case where the AN is counting the 
> >>packets and measuring the time is also in the framework and this 
> >>information can be sent directly from the AN to the 
> accounting server 
> >>(which might be the NAS itself of course) with another 
> protocol than 
> >>ANCP like Radius for instance.
> >>Actually, section 3.4.3 has to be read as whole and not 
> just the part 
> >>I copy/pasted in the email.  The question is basically if 
> this section 
> >>is Ok for everyone.
> >>
> >> From a protocol point of view, this means that each entry in the 
> >>white list has the following information: indication whether 
> >>accounting is needed or not, and if needed, whehter the 
> accounting is 
> >>performed by the NAS or by the AN.  In the latter case, also the IP 
> >>address of the accounting servers are specified.
> >>
> >>regards,
> >>Stefaan
> >>
> >>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 16 Jan 2008 16:20:43 +0100

Hi Stefaan,

I have trouble parsing the message below (eg when you say "if we  
believe that the comment below was on the wrong bullet, then it is  
all Ok.").

So, let's break it into separate bits:

1) 2nd bullet: Accounting done by AN and reported to NAS (excluding  
the question of volume accounting done on AN)
======================================================================== 
================
Leaving aside the question of whether the AN is to perform volume  
accounting itself or not, could you identify if you see any specific  
>>>  http://www1.ietf.org/mail-archive/web/ancp/current/msg00408.html.

and if needed propose changes?

2) 2nd bullet: Accounting done by AN and reported to NAS (the  
question of volume accounting done on AN)
======================================================================== 
================
Focusing on the question of whether the AN is to perform volume  
accounting itself or not.
I think you're saying that we know of some ANs that are not capable  
of performing such volume accounting so we can not just assume this  
capability always exist. That's a valid point. So ANCP needs to  
support the model where volume accounting is done on NAS.
Now, is it likely that some ANs would support such capability today  
or in the future?  If yes, perhaps ANCP should also support that  
model, no?
I think you mentioned something about DSL Forum position on that in  
Vancouver. Could you summarize DSL Forum position on this?

3) 1st bullet: Accounting done by AN and reported directly to Server
=================================================
I think you suggest we could remove this as it does not affect ANCP.
I don't have a strong view. I lean towards keeping it in because it  
because it does clarify where ANCP plays and doesn't play.

Francois

On 14 Jan 2008, at 14:56, Stefaan DE CNODDER wrote:

>
> Woj,
>
> From a functional point of view it is Ok but the comment was to  
> change the second bullet of section 3.4.3 into what is already in  
> the first bullet of section 3.4.3 (although there it is generalised  
> that the AN can send this info to any acct server and not just the  
> NAS).
>
> My question is whether we can remove the first bullet.  If the AN  
> has to do the multicast accounting, then it can also do the unicast  
> accounting and I thought ANCP was about moving all of this to the  
> NAS.  And if the AN can do the unicast accounting, then it can do  
> the appropriate QoS queueing as well....  Anyhow, I am fine with  
> the current text in the framework and if we believe that the  
> comment below was on the wrong bullet, then it is all Ok.
>
>>> From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel- 
>>> lucent.be] Sent: 14 January 2008 14:00
>>> To: Wojciech Dec (wdec)
>>> Cc: [email-masked]
>>> The framework draft currently does not exclude anything.  Both  
>>> options are possible.  The case where the AN is counting the  
>>> information can be sent directly from the AN to the accounting  
>>> server (which might be the NAS itself of course) with another  
>>> protocol than ANCP like Radius for instance.  Actually, section  
>>> 3.4.3 has to be read as whole and not just the part I copy/pasted  
>>> in the email.  The question is basically if this section is Ok  
>>> for everyone.
>>>
>>> accounting is performed by the NAS or by the AN.  In the latter  
>>> case, also the IP address of the accounting servers are specified.
>>>
>>> regards,
>>> Stefaan
>>>
>>>
>>>> alternative proposal is presented in http://www1.ietf.org/mail- 
>>>> archive/web/ancp/current/msg00408.html.
>>>>
>>>> ---snip---
>>>> o The AN keeps track of when replication for a given multicast  
>>>> flow starts or stops and then the AN can convey time and/or  
>>>> volume information to the NAS for further processing. This
>>>
>>> approach relies on
>>>> the time and/or volume information for further processing.  
>>>> Granted that if access nodes are not capable of providing such  
>>>> information, they will only signal simple start/stop events. I  
>>>> however don't see why the framework and protocol should be  
>>>> limited only to
>>>
>>> this latter
>>>>> not.  Is something similar needed to support the first bullet  
>>>>> in a white list entry (e.g., need for time and/or volume based
>>>
>>> accounting

---

From: "Derek Harkness" <[email-masked]>
Date: Thu, 17 Jan 2008 12:53:29 -0000

I lost some of the the thread of the text alternatives, but can only
absolutely agree on the black box principle - AN & NAS is one multicast
node.

There are multiple uses for this info:
(1) Who is using what channels. This can help you with network planning
/ overbooking, but also to enable targetted advertising, for which you
only may only need to know which mcast channels they watch - i.e.
start/stop.

(2) Charging for delivery of the mcast traffic - for which you may want
detailed info, as you are charging on volume basis and time basis ( i.e.
peak time volume will be more expensive ). This would apply for a e.g.
wholesale network provider charging a retailer for delivery.

Less so, I think, unless you want the detailed mode from all but the AN2
doesn't support it yet - so this is back to the capabilities discussion
i think. From an application scenario this seems to make less sense.
Accounting models tend to be application or network global rather than
network element or regionally specific, in my experience.

Cheers,

	Derek.

+=============================+
Derek Harkness
Juniper Networks 
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: [email-masked]
+=============================+ 

-----Original Message-----
From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: 14 January 2008 16:39
To: Stefaan DE CNODDER
Cc: [email-masked]
Subject: RE: [ANCP] Multicast Accounting

Stefaan,

Regards,
Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 18 Jan 2008 11:22:39 +0100

It thus seems that allowing for ANCP mcast accounting detail capability
negotiation seems as the way forward, with two main capabilities: simple
(start/stops only), detailed (start/stops with byte count). Arguably
time info can also be added, but appears to be implicit in the
start/stop info already.

-Woj.

> From: Derek Harkness [mailto:[email-masked]] 
> Sent: 17 January 2008 13:53
> To: Wojciech Dec (wdec); Stefaan DE CNODDER
> Cc: [email-masked]
> I lost some of the the thread of the text alternatives, but 
> can only absolutely agree on the black box principle - AN & 
> NAS is one multicast node.
> 
> - Does anyone forsee a use for only simple start/stop mcast 
> ANCP accounting messages vs start/stop accounting with detailed info? 
> 
> (1) Who is using what channels. This can help you with 
> network planning / overbooking, but also to enable targetted 
> advertising, for which you only may only need to know which 
> mcast channels they watch - i.e.
> start/stop.
> 
> (2) Charging for delivery of the mcast traffic - for which 
> you may want detailed info, as you are charging on volume 
> basis and time basis ( i.e.
> - And does anyone forsee a deployment model where a mix of 
> the modes is used, eg AN1 supporting detailed-mode and AN2 
> supporting not-detailed-mode? 
> 
> Less so, I think, unless you want the detailed mode from all 
> but the AN2 doesn't support it yet - so this is back to the 
> capabilities discussion i think. From an application scenario 
> this seems to make less sense.
> Accounting models tend to be application or network global 
> rather than network element or regionally specific, in my experience.
> 
> Cheers,
> 
> 	Derek.
> 
> multicast 
> > >>>>      Access Loop and per multicast flow, before 
> sending it to a 
> > >>>>central