[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] Multicast Accounting
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
issues with proposal in :
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.
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:
Stefaan,
then you're saying that you agree with Francois' proposal for Section
3.4.3?
-Woj.
-----Original Message-----
From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder at alcatel-
lucent.be] Sent: 14 January 2008 14:00
To: Wojciech Dec (wdec)
Cc: ancp at ietf.org
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
Wojciech Dec (wdec) wrote:
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:stefaan.de_cnodder at alcatel-lucent.be]
Sent: 08 January 2008 14:13
To: ancp at ietf.org
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:
---
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
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp