[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ANCP] Multicast Accounting
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.
> -----Original Message-----
> From: Derek Harkness [mailto:dharkness at juniper.net]
> Sent: 17 January 2008 13:53
> To: Wojciech Dec (wdec); Stefaan DE CNODDER
> Cc: ancp at ietf.org
> Subject: RE: [ANCP] Multicast Accounting
>
> 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?
>
> 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.
>
> - 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.
>
> +=============================+
> Derek Harkness
> Juniper Networks
> Nymphenburger Strasse 13-15
> 80335 Munich
> Germany
> Tel: +49 89 5529 4916
> Mobile: +49 172 843 6621
> Email: DHarkness at juniper.net
> +=============================+
>
> -----Original Message-----
> From: Wojciech Dec (wdec) [mailto:wdec at cisco.com]
> Sent: 14 January 2008 16:39
> To: Stefaan DE CNODDER
> Cc: ancp at ietf.org
> Subject: 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
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp