Hi Pete,
On 5/20/13 4:29 PM, "Peter McCann" <[email protected]> wrote: > >Agree cost is not the only argument for local break-out. But it is an >important one and I think it's appropriate to call it out in a >requirements >document. Its fine. But, there is no data point to prove that one option is cheaper than the other... :) > >>>LI should be a very small proportion of the traffic, and those flows >>>can be directed to a collection point as needed. >>You mean small set of subscribers, or small portion of a subscriber >>traffic. ? If its later, I assumed the Communication Content (CC) for >>intercept (in general) is HTTP+SMTP traffic which in most cases maps to >>100% of the subscriber traffic. > >I meant a small number of subscribers. > >Besides, as far as I know RFC 2804 is still IETF consensus. Unless you >want >to re-open the Raven discussions, we should not even be considering LI >requirements >in our work in IETF, let alone allowing them to drive us to an >architecture that is >grossly inefficient. I don't want to re-open RFC-2804 discussions, at least for now and surely not in this WG. As I commented in OPSAWG some time back, I completely disagree with that document and IETF's past views on this topic. It surely needs a review to check its applicability and relevance for the current times. To me its a regulatory requirement that operators need to comply with, else they cannot deploy that service. Now, in the DMM context, it is relevant when we justify models based on such parameters such as cost ..etc. We cannot forget the key services and draw some random conclusions. BTW, the cost argument may turn out to be trueÅ but we have insufficient data here. Better approach would be to consider both the options, but not make claims using "cost" as the driver. Any case, my entry into this discussion was more with a general comment. I'm not asking for any changes in the Reqs documentÅ Regards Sri > >-Pete _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
