Chinese bgp metering story

Joel Jaeggli joelja at bogus.com
Sat Dec 19 18:06:27 UTC 2009



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 at 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
> 
> 




More information about the NANOG mailing list