[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ANCP] Multicast Accounting
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.
> -----Original Message-----
> From: Stefaan DE CNODDER
> [mailto:stefaan.de_cnodder at alcatel-lucent.be]
> Sent: 14 January 2008 14:56
> To: Wojciech Dec (wdec)
> Cc: ancp at ietf.org
> Subject: Re: [ANCP] Multicast Accounting
>
>
> 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