Re: Chinese bgp metering story

[Joel Jaeggli <joelja () bogus com>]

Paolo Lucente wrote:
> On Fri, Dec 18, 2009 at 10:09:32PM -0600, James Hess wrote:
> > On Fri, Dec 18, 2009 at 1:24 PM, Jonny Martin <jonny () pch net> wrote:
> > ..
> > > modified if need be - to achieve this. ?Mixing billing with the reachability
> > > information signalled through BGP just doesn't seem like a good idea.
> > Indeed not..  but it might offer one advantage, if  it was mandatory
> > for any such tarrif/cost to be advertised there to be valid, and  in
> > the form of an  ancillary BGP route attribute,  rather than buried in
> > some  500,000 page  treaty that forces all ISPs to decipher it and
> > try to figure out what their liabilities are.
> >
> > Mainly because it makes any tarrif very visible, and easily understood.
> > and offers an easy ability to automatically make decisions like
> > discard reachability information that has any billing labels or
> > "strings" attached to it, or has a cost greater than $X per million
> > packets  listed for 'source'...  and easily allows an ISP to  replace
> > the  next hop with null  when a tarrif option has been listed, or use
> > only a route not subject to tarrif.
>
> I concur. Such visibility is efficient and drives simplification and
> automation from a data mining perspective, when analyzing accounting
> information.
>
> In such context, some care is required. Reachability information is
> destination based. Mixing accounting (ie. NetFlow) and reachability
> (ie. BGP) information is of good value for traffic delivered out of
> a routing domain but not for traffic received, ie. reverse reachability
> lookups can be a way although they are not truly deterministic due to
> routing asymmetries; 

deliberate tunning for purposes of TE, use of default. will all
contribute to ingress path not resembling egress...

> a mix of ingress measurements, lookup maps and
> an export protocol supporting L2 information (ie. for same interface,
> multiple peers scenarios) give way a better chance to resolve which
> neighboring party is pulling which traffic into the observed domain.
>
> Cheers,
> Paolo