Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Larry Sheldon]

I guess at long last it is time for Larry to stop thinking there was a 
common interest here.


NANOG has gone completely into the weeds (my email client treats it as 
political spam).


Sad--once upon a time it was a home for science in an insane academic world.

--
"Everybody is a genius.  But if you judge a fish by
its ability to climb a tree, it will live its whole
life believing that it is stupid."

--Albert Einstein

From Larry's Cox account.

Re: Prepending with another ASN you don't own

[Randy Bush]

>> this is called path poisoning.  an italian friend used it in his phd
>> thesis.  a few friends and i used it to detect use of default across
>> the internet.
> 
> I've done this in the past as a work-around for insufficient BGP
> community support.  Just prepending the AS I wanted to ignore the
> paths.
> 
> But, if the problem is an anycast CDN choosing a sub-optimal path to
> reach you, you might try reaching out to them.  They're probably just
> as, if not more interested, in getting their traffic to you as
> efficiently as possible.

apologies.  i should have been more explicit.  both of the examples
were using path poisoning for routing research.  it is not a technique
i would reccommend in normal operations.

randy

Re: Multicast IPTV on DOCSIS

[Luke Guillory]

Yes it works over docsis, you assigned downstreams to part of a multicast group 
and the CMTS will use those when a device asks to join.

X1 is both traditional HFC and also full on IPTV which is where everyone is 
going including HFC plants.


Mediaroom is the least popular middleware when looking at the major ones, 
Minerva has much more market share.

Cox licensed the X1 platform for their Contor product after ditching Cisco for 
some reason.



Sent from my iPhone

On Dec 16, 2016, at 4:27 PM, Jean-Francois Mezei 
> wrote:


Today, Rogers (in Canada) announced it was ditching it long running
project to move to an IPTV platform it had been developping and will
adopt Comcast X1.  (some $500 million writeoff).

Telco IPTV systems use multicasting all the way to the customer's LAN
and generally use the Microsoft/Ericcson MediaRoom product suite and
compatible STBs.

Could a cableco have deployed Mediaroom on a DOCSIS system? Does docsis
support multicasting ? I assume it would run on a separate DOCSIS group
of NTSC channels on the coax and likely require 2 modems in the home.

I am curious on why Rogers would have spent so much time trying to
develop its own system.

With regards to Comcast X1, is this a very conventional TV on coax
system, with a bunch of switched video channels to cater to on-demand
services to invividual homes ?

Or does X1 use some form of IP connection to deliver "data" for the
on-demand content ? (while linear TV still provided in traditional
digital channels bundled into an NTSC channel ?

BTW, one of the original arguments for Rogers is that cable STBs had
proprietary software that was slow to evolve and get new features
approved/tested, so they lagged behind the IPTV STB software which
didn't require certificatioN/approval by the STB hardware vendors (cisco
etc).

Has any Cable system converted to IPTV ?










Luke Guillory
Network Operations Manager


[cid:image56af80.JPG@29a6b056.4196f16d] 

Tel:985.536.1212
Fax:985.536.0300
Email:  lguill...@reservetele.com
Web:www.rtconline.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084





Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission.

Multicast IPTV on DOCSIS

[Jean-Francois Mezei]

Today, Rogers (in Canada) announced it was ditching it long running
project to move to an IPTV platform it had been developping and will
adopt Comcast X1.  (some $500 million writeoff).

Telco IPTV systems use multicasting all the way to the customer's LAN
and generally use the Microsoft/Ericcson MediaRoom product suite and
compatible STBs.

Could a cableco have deployed Mediaroom on a DOCSIS system? Does docsis
support multicasting ? I assume it would run on a separate DOCSIS group
of NTSC channels on the coax and likely require 2 modems in the home.

I am curious on why Rogers would have spent so much time trying to
develop its own system.

With regards to Comcast X1, is this a very conventional TV on coax
system, with a bunch of switched video channels to cater to on-demand
services to invividual homes ?

Or does X1 use some form of IP connection to deliver "data" for the
on-demand content ? (while linear TV still provided in traditional
digital channels bundled into an NTSC channel ?

BTW, one of the original arguments for Rogers is that cable STBs had
proprietary software that was slow to evolve and get new features
approved/tested, so they lagged behind the IPTV STB software which
didn't require certificatioN/approval by the STB hardware vendors (cisco
etc).

Has any Cable system converted to IPTV ?

Re: Prepending with another ASN you don't own

[Jon Lewis]

On Fri, 16 Dec 2016, Randy Bush wrote:


this is called path poisoning.  an italian friend used it in his phd
thesis.  a few friends and i used it to detect use of default across
the internet.


I've done this in the past as a work-around for insufficient BGP community 
support.  Just prepending the AS I wanted to ignore the paths.


But, if the problem is an anycast CDN choosing a sub-optimal path to reach 
you, you might try reaching out to them.  They're probably just as, if not 
more interested, in getting their traffic to you as efficiently as 
possible.


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Jean-Francois Mezei]

On 2016-12-16 10:58, Rich Kulawiec wrote:
> This is a short-term (about one month) project being thrown together
> in a hurry...and it could use some help.  


How much data are we talking about here?  A few floppy disks ? a couple
of megabytes ? gigabytes ? terabytes ? petabytes ?

Have you considered giving "courtesy copies" to other environmental
organistaions such as Environment Canada, Australian Bureau of
Meteorology etc ?

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Mark Blackman]

> On 16 Dec 2016, at 21:35, Rob McEwen  wrote:
> But global warming and CO2 being a cause of it.

http://climate.nasa.gov/evidence/ 

What sort of effects do you reckon a 35% increase in atmospheric CO2 over 
historical levels over the space of 65 years might lead to? 

- Mark

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Aaron C. de Bruyn via NANOG]

On Fri, Dec 16, 2016 at 1:35 PM, Rob McEwen  wrote:
> On 12/16/2016 3:30 PM, Ken Chase wrote:
> A 39-inch rise in the ocean levels over the next century is based on
> fear-mongering and junk science designed to scare politicians into
> increasing grant $$ from the federal government. It is not based on science.

39 inches?
I'm going to start laying fiber up and down I-5.  I'll have the
cheapest trans-ocean cable between Canada and Mexico...

-A

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Rob McEwen]

On 12/16/2016 4:48 PM, Hugo Slabbert wrote:

This started as a technical appeal, but:
https://www.nanog.org/list
1. Discussion will focus on Internet operational and technical issues as
described in the charter of NANOG.
6.  Postings of political, philosophical, and legal nature are prohibited.


EXACTLY - but I had to finally respond because it was getting 
obnoxious... all the "we all think this way and we KNOW that the other 
side is wrong"--implications/statements embedded in various previous posts.


--
Rob McEwen

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Hugo Slabbert]

This started as a technical appeal, but:

https://www.nanog.org/list

1. Discussion will focus on Internet operational and technical issues as 
described in the charter of NANOG.

...
6.  Postings of political, philosophical, and legal nature are prohibited.
...

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

On Fri 2016-Dec-16 16:35:36 -0500, Rob McEwen  wrote:


On 12/16/2016 3:30 PM, Ken Chase wrote:

http://abcnews.go.com/US/north-carolina-bans-latest-science-rising-sea-level/story?id=16913782


North Carolina is not banning science. It is banning absolutely 
preposterous and manipulated junk science.


A 39-inch rise in the ocean levels over the next century is based on 
fear-mongering and junk science designed to scare politicians into 
increasing grant $$ from the federal government. It is not based on 
science.


In fact, the sea levels continue to rise at the SAME TINY 2-4mm per 
year that they've been rising at for decades, with ZERO sign of an 
increase.


If global warming was real and cumulative - this shouldn't even be 
possible, based all that we've been told over the past 20 years.


Every article that states that oceans rising at alarmingly faster 
rates - due to global warming - either lie about or manipulate the 
the data... or they grab one relatively small short term spike and 
extrapolates from that.


Meanwhile, dozens of sea-level rising predictions from so-called 
credible scientists have not only failed, but failed by order of 
magnitudes, and again, relied upon junk science. True science makes 
"risky predictions" and is willing to throw out the theory when that 
theories "risky predictions" don't come true.


But I truly due hope that this collection process is successful 
because I hope that ALL of this (mostly) manipulated data gets 
recorded for posterity so that (honest) scientists a century from now 
can do extensive studies on how/why science became so political and 
manipulated as they look back on the first few decades of the 21st 
century's slide into a strong long-term cooling trend, due to long 
term cyclical sun cycles.


This is not a victim-less crime. This manipulation of the data by 
global warmongers harms people because is miscalculates resources and 
damages the economy. Does that mean we should spew toxic waste into 
rivers or streams or spew smog into the air? Of course not. But 
global warming and CO2 being a cause of it... and "oceans rising" has 
MUCH junk science behind it.


Still, I hope this data is preserved. The truth will win out in the 
long term. (as is already starting to happen)


--
Rob McEwen




signature.asc
Description: Digital signature

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Rob McEwen]

On 12/16/2016 3:30 PM, Ken Chase wrote:

http://abcnews.go.com/US/north-carolina-bans-latest-science-rising-sea-level/story?id=16913782


North Carolina is not banning science. It is banning absolutely 
preposterous and manipulated junk science.


A 39-inch rise in the ocean levels over the next century is based on 
fear-mongering and junk science designed to scare politicians into 
increasing grant $$ from the federal government. It is not based on science.


In fact, the sea levels continue to rise at the SAME TINY 2-4mm per year 
that they've been rising at for decades, with ZERO sign of an increase.


If global warming was real and cumulative - this shouldn't even be 
possible, based all that we've been told over the past 20 years.


Every article that states that oceans rising at alarmingly faster rates 
- due to global warming - either lie about or manipulate the the data... 
or they grab one relatively small short term spike and extrapolates from 
that.


Meanwhile, dozens of sea-level rising predictions from so-called 
credible scientists have not only failed, but failed by order of 
magnitudes, and again, relied upon junk science. True science makes 
"risky predictions" and is willing to throw out the theory when that 
theories "risky predictions" don't come true.


But I truly due hope that this collection process is successful because 
I hope that ALL of this (mostly) manipulated data gets recorded for 
posterity so that (honest) scientists a century from now can do 
extensive studies on how/why science became so political and manipulated 
as they look back on the first few decades of the 21st century's slide 
into a strong long-term cooling trend, due to long term cyclical sun cycles.


This is not a victim-less crime. This manipulation of the data by global 
warmongers harms people because is miscalculates resources and damages 
the economy. Does that mean we should spew toxic waste into rivers or 
streams or spew smog into the air? Of course not. But global warming and 
CO2 being a cause of it... and "oceans rising" has MUCH junk science 
behind it.


Still, I hope this data is preserved. The truth will win out in the long 
term. (as is already starting to happen)


--
Rob McEwen

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Ken Chase]

I seriously doubt that there's going to be a witchhunt even close to as well
funded as anti-torrent DMCA-wielding piracy hunters, and it's not even nearly
the same as keeping a copy of wikileaks.aes, or sattelite photos of
Streisand's campus, or photos of Elian Gonzales, a copy of deCSS, the 
cyberSitter
killfile, etc ("we've been here before.").

The issue will be 1000s of half copies that are from differing dates sometimes
with no timestamps or other metadata, no SHA256 sums, etc etc. It's going to be
a records management nightmare. Remember, all these agencies wont be shut down
on Jan 20th making that the universal time-stamp date. Some of them may even
be encouraged to continue producing data, possibly even cherry picked or 
otherwise
tainted. Others will carry on quietly, without the administration noticing.

Im glad some serious orgs are getting into it - U of T, archive.org, wikipedia, 
etc.
We'll have at least a few repo's that cross-agree on progeny, date, sha256, etc.

Only once jackboots are knocking on doors "where's the icecore sample data, 
Lebowski!"
will we really have to consider the quality levels of the other repos. Not that
they shouldnt be kept either, of course.

Remember, this is only one piece of the puzzle. The scientists can do as much 
data-
collecting as they want -- if the political side of the process wants to make 
'mentioning
climate change illegal' in state bills or other policies or department missions,
it's far more effective than rm'ing a buncha datasets.

http://abcnews.go.com/US/north-carolina-bans-latest-science-rising-sea-level/story?id=16913782

Nonetheless - mirror everything everywhere always...

/kc


On Fri, Dec 16, 2016 at 02:05:01PM -0500, Steven Miano said:
  >It would seem like the more copies the better, seemingly chunking this data
  >up and using .torrent files may be a way to both (a) ensure the integrity
  >of the data, and (b) enable an additional method to ensure that there are
  >enough copies being replicated (initial seeders would hopefully retain the
  >data for as long as possible)...
  >
  >On Fri, Dec 16, 2016 at 12:24 PM, Ken Chase  wrote:
  >
  >> University Toronto's Robarts Library is hosting an all-day party tomorrow
  >> of
  >> people to surf and help identify datasets, survey and get size and details,
  >> authenticate copies, etc.
  >>
  >> fb event: https://www.facebook.com/events/1828129627464671/
  >>
  >> /kc
  >>
  >> On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said:
  >>   >We are currently working on a scheme to successfully authenticate and
  >> verify the integrity of the data. Datasets in https://climate.daknob.net/
  >> are compressed to a .tar.bz2 and then hashed using SHA-256. The final file
  >> with all checksums is then signed using a set of PGP keys.
  >>   >
  >>   >We are still working on a viable way to verify the authenticity of
  >> files before there are tons of copies lying around and there???s a working
  >> group in the Slack team I sent previously where your input is much needed!
  >>   >
  >>   >Thanks,
  >>   >Antonios
  >>   >
  >>   >> On 16 Dec 2016, at 18:30, Ken Chase  wrote:
  >>   >>
  >>   >> Surfing through the links - any hints on how big these datasets are?
  >> Everyone's got
  >>   >> a few TB to throw at things, but fewer of us have spare PB to throw
  >> around.
  >>   >>
  >>   >> There's some random #s on the goog doc sheet for sizes (100's of TB
  >> for the
  >>   >> landsat archive seems credible), and there's one number that destroys
  >>   >> credibility of the sheet (1000 GB (100 ZB)) for the EPA
  >> archive.
  >>   >>
  >>   >> The other page has many 'TBA' entries for size.
  >>   >>
  >>   >> Not sure what level of player one needs to be to be able to serve a
  >> useful
  >>   >> segment of these archives. I realize some of the datasets are tiny
  >> (>   >> but which ones are most important vs size (ie the win-per-byte ratio)
  >> isnt indicated.
  >>   >> (I know its early times.)
  >>   >>
  >>   >> Also I hope they've SHA512'd the datasets for authenticity before all
  >> these
  >>   >> myriad copies being flungabout are 'accused' of being manipulated 'to
  >> promote
  >>   >> the climate change agenda' yadda.
  >>   >>
  >>   >> Canada: time to step up! (Cant imagine the Natl Research Council
  >> would do so
  >>   >> on their mirror site, too much of a gloves-off slap in the face to
  >> Trump.)
  >>   >>
  >>   >> /kc
  >>   >>
  >>   >>
  >>   >> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said:
  >>   >>> If you???re interested, there???s also a Slack team:
  >> climatemirror.slack.com
  >>   >>>
  >>   >>> You can find more info about that here:
  >>   >>>
  >>   >>> - https://climate.daknob.net/
  >>   >>> - http://climatemirror.org/
  >>   >>> - http://www.ppehlab.org/datarefuge
  >>   >>>
  >>   >>> Thank you for your help!
  >>   >>>
  >>   >>>
  >>    On 16 Dec 2016, at 17:58, Rich Kulawiec 

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Steven Miano]

It would seem like the more copies the better, seemingly chunking this data
up and using .torrent files may be a way to both (a) ensure the integrity
of the data, and (b) enable an additional method to ensure that there are
enough copies being replicated (initial seeders would hopefully retain the
data for as long as possible)...

On Fri, Dec 16, 2016 at 12:24 PM, Ken Chase  wrote:

> University Toronto's Robarts Library is hosting an all-day party tomorrow
> of
> people to surf and help identify datasets, survey and get size and details,
> authenticate copies, etc.
>
> fb event: https://www.facebook.com/events/1828129627464671/
>
> /kc
>
> On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said:
>   >We are currently working on a scheme to successfully authenticate and
> verify the integrity of the data. Datasets in https://climate.daknob.net/
> are compressed to a .tar.bz2 and then hashed using SHA-256. The final file
> with all checksums is then signed using a set of PGP keys.
>   >
>   >We are still working on a viable way to verify the authenticity of
> files before there are tons of copies lying around and there???s a working
> group in the Slack team I sent previously where your input is much needed!
>   >
>   >Thanks,
>   >Antonios
>   >
>   >> On 16 Dec 2016, at 18:30, Ken Chase  wrote:
>   >>
>   >> Surfing through the links - any hints on how big these datasets are?
> Everyone's got
>   >> a few TB to throw at things, but fewer of us have spare PB to throw
> around.
>   >>
>   >> There's some random #s on the goog doc sheet for sizes (100's of TB
> for the
>   >> landsat archive seems credible), and there's one number that destroys
>   >> credibility of the sheet (1000 GB (100 ZB)) for the EPA
> archive.
>   >>
>   >> The other page has many 'TBA' entries for size.
>   >>
>   >> Not sure what level of player one needs to be to be able to serve a
> useful
>   >> segment of these archives. I realize some of the datasets are tiny
> (   >> but which ones are most important vs size (ie the win-per-byte ratio)
> isnt indicated.
>   >> (I know its early times.)
>   >>
>   >> Also I hope they've SHA512'd the datasets for authenticity before all
> these
>   >> myriad copies being flungabout are 'accused' of being manipulated 'to
> promote
>   >> the climate change agenda' yadda.
>   >>
>   >> Canada: time to step up! (Cant imagine the Natl Research Council
> would do so
>   >> on their mirror site, too much of a gloves-off slap in the face to
> Trump.)
>   >>
>   >> /kc
>   >>
>   >>
>   >> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said:
>   >>> If you???re interested, there???s also a Slack team:
> climatemirror.slack.com
>   >>>
>   >>> You can find more info about that here:
>   >>>
>   >>> - https://climate.daknob.net/
>   >>> - http://climatemirror.org/
>   >>> - http://www.ppehlab.org/datarefuge
>   >>>
>   >>> Thank you for your help!
>   >>>
>   >>>
>    On 16 Dec 2016, at 17:58, Rich Kulawiec  wrote:
>   
>    This is a short-term (about one month) project being thrown together
>    in a hurry...and it could use some help.  I know that some of
>    you have lots of resources to throw at this, so if you have an
>    interest in preserving a lot of scientific research data, I've set
>    up a mailing list to coordinate IT efforts to help out.  Signup via
>    climatedata-requ...@firemountain.net or, if you prefer Mailman's
> web
>    interface, http://www.firemountain.net/mailman/listinfo/climatedata
>    should work.
>   
>    Thanks,
>    ---rsk
>   
>   >>>
>   >>
>
> --
> Ken Chase - m...@sizone.org Guelph Canada
>



-- 
Miano, Steven M.
http://stevenmiano.com

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 17 Dec, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  625735
Prefixes after maximum aggregation (per Origin AS):  221470
Deaggregation factor:  2.83
Unique aggregates announced (without unneeded subnets):  303432
Total ASes present in the Internet Routing Table: 55446
Prefixes per ASN: 11.29
Origin-only ASes present in the Internet Routing Table:   36286
Origin ASes announcing only one prefix:   15252
Transit ASes present in the Internet Routing Table:6548
Transit-only ASes present in the Internet Routing Table:166
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  38
Max AS path prepend of ASN ( 55644)  36
Prefixes from unregistered ASNs in the Routing Table:65
Unregistered ASNs in the Routing Table:  19
Number of 32-bit ASNs allocated by the RIRs:  16577
Number of 32-bit ASNs visible in the Routing Table:   12612
Prefixes from 32-bit ASNs in the Routing Table:   51551
Number of bogon 32-bit ASNs visible in the Routing Table:   610
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:388
Number of addresses announced to Internet:   2834097636
Equivalent to 168 /8s, 236 /16s and 229 /24s
Percentage of available address space announced:   76.6
Percentage of allocated address space announced:   76.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.4
Total number of prefixes smaller than registry allocations:  207209

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   156457
Total APNIC prefixes after maximum aggregation:   43125
APNIC Deaggregation factor:3.63
Prefixes being announced from the APNIC address blocks:  170884
Unique aggregates announced from the APNIC address blocks:70394
APNIC Region origin ASes present in the Internet Routing Table:5185
APNIC Prefixes per ASN:   32.96
APNIC Region origin ASes announcing only one prefix:   1141
APNIC Region transit ASes present in the Internet Routing Table:938
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 38
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2555
Number of APNIC addresses announced to Internet:  761096836
Equivalent to 45 /8s, 93 /16s and 106 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:188238
Total ARIN prefixes after maximum aggregation:89443
ARIN Deaggregation factor: 2.10
Prefixes being announced from the ARIN address blocks:   194870
Unique aggregates announced from the ARIN address blocks: 89539
ARIN Region origin ASes present in the Internet Routing Table:16105
ARIN Prefixes per ASN:12.10

Re: Routeviews

[John Kemp]

We're looking at it now.  Thanks.

John Kemp

On 12/16/16 9:21 AM, Marty Strong via NANOG wrote:
> Looks like somebody didn’t renew the domain
> 
> $ whois routeviews.org
> Domain Name: ROUTEVIEWS.ORG
> Domain ID: D48496876-LROR
> WHOIS Server:
> Referral URL: http://www.networksolutions.com
> Updated Date: 2016-12-16T10:30:46Z
> Creation Date: 2000-12-14T23:05:47Z
> Registry Expiry Date: 2017-12-14T23:05:47Z
> Sponsoring Registrar: Network Solutions, LLC
> Sponsoring Registrar IANA ID: 2
> Domain Status: clientTransferProhibited 
> https://icann.org/epp#clientTransferProhibited
> Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
> Registrant ID: C11717-NS
> Registrant Name: Perfect Privacy, LLC
> Registrant Organization: Network Solutions LLC
> Registrant Street: 12808 Gran Bay Parkway West
> Registrant Street: care of Network Solutions (DOMAIN-RESALE)
> Registrant Street: FL
> Registrant City: Jacksonville
> Registrant State/Province: FL
> Registrant Postal Code: 32217
> Registrant Country: US
> Registrant Phone: +1.5707088780
> Registrant Phone Ext:
> Registrant Fax: +1.5707088780
> Registrant Fax Ext:
> Registrant Email: pendingrenewalordelet...@networksolutions.com
> Admin ID: C11717-NS
> Admin Name: Perfect Privacy, LLC
> Admin Organization: Network Solutions LLC
> Admin Street: 12808 Gran Bay Parkway West
> Admin Street: care of Network Solutions (DOMAIN-RESALE)
> Admin Street: FL
> Admin City: Jacksonville
> Admin State/Province: FL
> Admin Postal Code: 32217
> Admin Country: US
> Admin Phone: +1.5707088780
> Admin Phone Ext:
> Admin Fax: +1.5707088780
> Admin Fax Ext:
> Admin Email: pendingrenewalordelet...@networksolutions.com
> Tech ID: C11717-NS
> Tech Name: Perfect Privacy, LLC
> Tech Organization: Network Solutions LLC
> Tech Street: 12808 Gran Bay Parkway West
> Tech Street: care of Network Solutions (DOMAIN-RESALE)
> Tech Street: FL
> Tech City: Jacksonville
> Tech State/Province: FL
> Tech Postal Code: 32217
> Tech Country: US
> Tech Phone: +1.5707088780
> Tech Phone Ext:
> Tech Fax: +1.5707088780
> Tech Fax Ext:
> Tech Email: pendingrenewalordelet...@networksolutions.com
> Name Server: NS1.PENDINGRENEWALDELETION.COM
> Name Server: NS2.PENDINGRENEWALDELETION.COM
> DNSSEC: unsigned
 Last update of WHOIS database: 2016-12-16T17:19:44Z <<<
> 
> For more information on Whois status codes, please visit https://icann.org/epp
> 
> Access to Public Interest Registry WHOIS information is provided to assist 
> persons in determining the contents of a domain name registration record in 
> the Public Interest Registry registry database. The data in this record is 
> provided by Public Interest Registry for informational purposes only, and 
> Public Interest Registry does not guarantee its accuracy. This service is 
> intended only for query-based access. You agree that you will use this data 
> only for lawful purposes and that, under no circumstances will you use this 
> data to(a) allow, enable, or otherwise support the transmission by e-mail, 
> telephone, or facsimile of mass unsolicited, commercial advertising or 
> solicitations to entities other than the data recipient's own existing 
> customers; or (b) enable high volume, automate
> 
> Regards,
> Marty Strong
> --
> Cloudflare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
> 
> https://www.peeringdb.com/asn/13335
> 

Re: Prepending with another ASN you don't own

[Roland Dobbins]

On 17 Dec 2016, at 0:13, Job Snijders wrote:

There are providers who inspect the AS_PATH's contents and make 
decisions to reject (ignore) a route announcement or

not based on the presence of certain values.


+1

---
Roland Dobbins 

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Ken Chase]

University Toronto's Robarts Library is hosting an all-day party tomorrow of
people to surf and help identify datasets, survey and get size and details,
authenticate copies, etc.

fb event: https://www.facebook.com/events/1828129627464671/

/kc

On Fri, Dec 16, 2016 at 06:42:46PM +0200, DaKnOb said:
  >We are currently working on a scheme to successfully authenticate and verify 
the integrity of the data. Datasets in https://climate.daknob.net/ are 
compressed to a .tar.bz2 and then hashed using SHA-256. The final file with all 
checksums is then signed using a set of PGP keys.
  >
  >We are still working on a viable way to verify the authenticity of files 
before there are tons of copies lying around and there???s a working group in 
the Slack team I sent previously where your input is much needed!
  >
  >Thanks,
  >Antonios 
  >
  >> On 16 Dec 2016, at 18:30, Ken Chase  wrote:
  >> 
  >> Surfing through the links - any hints on how big these datasets are? 
Everyone's got
  >> a few TB to throw at things, but fewer of us have spare PB to throw around.
  >> 
  >> There's some random #s on the goog doc sheet for sizes (100's of TB for the
  >> landsat archive seems credible), and there's one number that destroys
  >> credibility of the sheet (1000 GB (100 ZB)) for the EPA archive.
  >> 
  >> The other page has many 'TBA' entries for size.
  >> 
  >> Not sure what level of player one needs to be to be able to serve a useful 
  >> segment of these archives. I realize some of the datasets are tiny (> but which ones are most important vs size (ie the win-per-byte ratio) isnt 
indicated.
  >> (I know its early times.)
  >> 
  >> Also I hope they've SHA512'd the datasets for authenticity before all these
  >> myriad copies being flungabout are 'accused' of being manipulated 'to 
promote
  >> the climate change agenda' yadda.
  >> 
  >> Canada: time to step up! (Cant imagine the Natl Research Council would do 
so
  >> on their mirror site, too much of a gloves-off slap in the face to Trump.)
  >> 
  >> /kc
  >> 
  >> 
  >> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said:
  >>> If you???re interested, there???s also a Slack team: 
climatemirror.slack.com
  >>> 
  >>> You can find more info about that here:
  >>> 
  >>> - https://climate.daknob.net/
  >>> - http://climatemirror.org/
  >>> - http://www.ppehlab.org/datarefuge
  >>> 
  >>> Thank you for your help!
  >>> 
  >>> 
   On 16 Dec 2016, at 17:58, Rich Kulawiec  wrote:
   
   This is a short-term (about one month) project being thrown together
   in a hurry...and it could use some help.  I know that some of
   you have lots of resources to throw at this, so if you have an
   interest in preserving a lot of scientific research data, I've set
   up a mailing list to coordinate IT efforts to help out.  Signup via
   climatedata-requ...@firemountain.net or, if you prefer Mailman's web
   interface, http://www.firemountain.net/mailman/listinfo/climatedata
   should work.
   
   Thanks,
   ---rsk
   
  >>> 
  >> 

-- 
Ken Chase - m...@sizone.org Guelph Canada

Routeviews

[Marty Strong via NANOG]

Looks like somebody didn’t renew the domain

$ whois routeviews.org
Domain Name: ROUTEVIEWS.ORG
Domain ID: D48496876-LROR
WHOIS Server:
Referral URL: http://www.networksolutions.com
Updated Date: 2016-12-16T10:30:46Z
Creation Date: 2000-12-14T23:05:47Z
Registry Expiry Date: 2017-12-14T23:05:47Z
Sponsoring Registrar: Network Solutions, LLC
Sponsoring Registrar IANA ID: 2
Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
Registrant ID: C11717-NS
Registrant Name: Perfect Privacy, LLC
Registrant Organization: Network Solutions LLC
Registrant Street: 12808 Gran Bay Parkway West
Registrant Street: care of Network Solutions (DOMAIN-RESALE)
Registrant Street: FL
Registrant City: Jacksonville
Registrant State/Province: FL
Registrant Postal Code: 32217
Registrant Country: US
Registrant Phone: +1.5707088780
Registrant Phone Ext:
Registrant Fax: +1.5707088780
Registrant Fax Ext:
Registrant Email: pendingrenewalordelet...@networksolutions.com
Admin ID: C11717-NS
Admin Name: Perfect Privacy, LLC
Admin Organization: Network Solutions LLC
Admin Street: 12808 Gran Bay Parkway West
Admin Street: care of Network Solutions (DOMAIN-RESALE)
Admin Street: FL
Admin City: Jacksonville
Admin State/Province: FL
Admin Postal Code: 32217
Admin Country: US
Admin Phone: +1.5707088780
Admin Phone Ext:
Admin Fax: +1.5707088780
Admin Fax Ext:
Admin Email: pendingrenewalordelet...@networksolutions.com
Tech ID: C11717-NS
Tech Name: Perfect Privacy, LLC
Tech Organization: Network Solutions LLC
Tech Street: 12808 Gran Bay Parkway West
Tech Street: care of Network Solutions (DOMAIN-RESALE)
Tech Street: FL
Tech City: Jacksonville
Tech State/Province: FL
Tech Postal Code: 32217
Tech Country: US
Tech Phone: +1.5707088780
Tech Phone Ext:
Tech Fax: +1.5707088780
Tech Fax Ext:
Tech Email: pendingrenewalordelet...@networksolutions.com
Name Server: NS1.PENDINGRENEWALDELETION.COM
Name Server: NS2.PENDINGRENEWALDELETION.COM
DNSSEC: unsigned
>>> Last update of WHOIS database: 2016-12-16T17:19:44Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

Access to Public Interest Registry WHOIS information is provided to assist 
persons in determining the contents of a domain name registration record in the 
Public Interest Registry registry database. The data in this record is provided 
by Public Interest Registry for informational purposes only, and Public 
Interest Registry does not guarantee its accuracy. This service is intended 
only for query-based access. You agree that you will use this data only for 
lawful purposes and that, under no circumstances will you use this data to(a) 
allow, enable, or otherwise support the transmission by e-mail, telephone, or 
facsimile of mass unsolicited, commercial advertising or solicitations to 
entities other than the data recipient's own existing customers; or (b) enable 
high volume, automate

Regards,
Marty Strong
--
Cloudflare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

https://www.peeringdb.com/asn/13335

Re: Prepending with another ASN you don't own

[Job Snijders]

Hi Andrew,

On Thu, Dec 15, 2016 at 01:54:34PM -0500, Andrew Imeson wrote:
> Is it acceptable to prepend using another networks ASN as long as your
> ASN is the last one in the path? I can think of a few scenarios where
> this is helpful.

Your milage may vary. You risk introducing breakage instead of the
desired optimisation. There are providers who inspect the AS_PATH's
contents and make decisions to reject (ignore) a route announcement or
not based on the presence of certain values. 

An example: If NTT's backbone (AS 2914) receives a route announcement
from any of its adjacent ASN (customers and peering partners alike)
which contains AT's ASN (7018), _anywhere_ in the AS_PATH, the
announcement is considered invalid and rejected (except on the direct
2914 <> 7018 BGP sessions of course).

This concept is called 'Peerlocking'. NTT has enabled this for an
undisclosed number of ASNs. This is a highly effective measure against
route leaks. More information: https://www.youtube.com/watch?v=CSLpWBrHy10

So, where you initially targetted to manipulate one ASN's best path
selection, you could end up being unreachable from mulitple seemingly
unrelated ASNs because they consider the announcement part of a route
leak!

> One scenario: Anycast content provider with an ISP (who you aren't
> directly peering with) is choosing to send all traffic to a PoP on
> another continent.
>
> Solution:
> Prepend at the geographically-distant PoP so that the AS path looks
> like   , and thus that service provider
> () views it as a routing loop and chooses one of your other
> PoPs. Sure there are better solutions like communities, but why (if it
> is) would this be "bad?"

You are right that BGP Communities usually are a better method,
especially BGP Communities which are acted upon on "ibgp-in" rather then
"ebgp-out" (with per-region granularity). Communities which manipulate
the intermediate provider's best path selection can have a better effect
on keeping traffic local for anycasters then just suppressing
announcements on the far-end.

For instance, the community to "set lowest local preference, but only on
routers located outside the country I'm connected in" (2914:435 in NTT's
network) can in many cases replace the need for forging AS_PATHs. Such a
method also provides a safetynet: there always is a route, but during
normal operations its just highly unattractive. With AS_PATH forging you
don't automatically protect yourself against certain outage scenarios.

Finally, keep in mind that there are networks which have disabled
AS_PATH Loop Detection, or point default somewhere, so the forged
AS_PATH kludge might be in-effective.

Kine regards,

Job

ps. Eric Loos once shared this piece of wisdom with me: "Whenever in doubt, use 
BGP Communities." ;-)

Re: Network Access to and from China Mainland

[Hugo Slabbert]

On Fri 2016-Dec-16 08:57:46 +0100, patr...@pahem.de  wrote:


Hello,

I have a customer based in Europe which have a subsidiary in China (Mainland) 
and also do a lot of businesses with China (Mainland). Lately the customer have 
a lot of issues with accessing websites which are hosted outside China from the 
subsidiary in China and sees also a lot of delivery problems with emails send 
to China. The SMTP-Gateway is located in Germany and in the logs we can see 
timeouts during the connection to the STMP servers in China (Mainland). I 
suspect that the Chinese Firewall has changed it's behaviour. Have anyone else 
currently similar issues with communication to and from China?


We gave up on fighting the GFW and got dedicated links between NA and 
locations in China.  No complaints so far.



Thanks,
Patrick


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[DaKnOb]

We are currently working on a scheme to successfully authenticate and verify 
the integrity of the data. Datasets in https://climate.daknob.net/ are 
compressed to a .tar.bz2 and then hashed using SHA-256. The final file with all 
checksums is then signed using a set of PGP keys.

We are still working on a viable way to verify the authenticity of files before 
there are tons of copies lying around and there’s a working group in the Slack 
team I sent previously where your input is much needed!

Thanks,
Antonios 

> On 16 Dec 2016, at 18:30, Ken Chase  wrote:
> 
> Surfing through the links - any hints on how big these datasets are? 
> Everyone's got
> a few TB to throw at things, but fewer of us have spare PB to throw around.
> 
> There's some random #s on the goog doc sheet for sizes (100's of TB for the
> landsat archive seems credible), and there's one number that destroys
> credibility of the sheet (1000 GB (100 ZB)) for the EPA archive.
> 
> The other page has many 'TBA' entries for size.
> 
> Not sure what level of player one needs to be to be able to serve a useful 
> segment of these archives. I realize some of the datasets are tiny ( but which ones are most important vs size (ie the win-per-byte ratio) isnt 
> indicated.
> (I know its early times.)
> 
> Also I hope they've SHA512'd the datasets for authenticity before all these
> myriad copies being flungabout are 'accused' of being manipulated 'to promote
> the climate change agenda' yadda.
> 
> Canada: time to step up! (Cant imagine the Natl Research Council would do so
> on their mirror site, too much of a gloves-off slap in the face to Trump.)
> 
> /kc
> 
> 
> On Fri, Dec 16, 2016 at 06:02:46PM +0200, DaKnOb said:
>> If you???re interested, there???s also a Slack team: climatemirror.slack.com
>> 
>> You can find more info about that here:
>> 
>> - https://climate.daknob.net/
>> - http://climatemirror.org/
>> - http://www.ppehlab.org/datarefuge
>> 
>> Thank you for your help!
>> 
>> 
>>> On 16 Dec 2016, at 17:58, Rich Kulawiec  wrote:
>>> 
>>> This is a short-term (about one month) project being thrown together
>>> in a hurry...and it could use some help.  I know that some of
>>> you have lots of resources to throw at this, so if you have an
>>> interest in preserving a lot of scientific research data, I've set
>>> up a mailing list to coordinate IT efforts to help out.  Signup via
>>> climatedata-requ...@firemountain.net or, if you prefer Mailman's web
>>> interface, http://www.firemountain.net/mailman/listinfo/climatedata
>>> should work.
>>> 
>>> Thanks,
>>> ---rsk
>>> 
>> 
> 
> -- 
> Ken Chase - m...@sizone.org Guelph Canada

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Ken Chase]

Surfing through the links - any hints on how big these datasets are? Everyone's 
got
a few TB to throw at things, but fewer of us have spare PB to throw around.

There's some random #s on the goog doc sheet for sizes (100's of TB for the
landsat archive seems credible), and there's one number that destroys
credibility of the sheet (1000 GB (100 ZB)) for the EPA archive.

The other page has many 'TBA' entries for size.

Not sure what level of player one needs to be to be able to serve a useful 
segment of these archives. I realize some of the datasets are tiny (If you???re interested, there???s also a Slack team: climatemirror.slack.com
  >
  >You can find more info about that here:
  >
  >- https://climate.daknob.net/
  >- http://climatemirror.org/
  >- http://www.ppehlab.org/datarefuge
  >
  >Thank you for your help!
  >
  >
  >> On 16 Dec 2016, at 17:58, Rich Kulawiec  wrote:
  >> 
  >> This is a short-term (about one month) project being thrown together
  >> in a hurry...and it could use some help.  I know that some of
  >> you have lots of resources to throw at this, so if you have an
  >> interest in preserving a lot of scientific research data, I've set
  >> up a mailing list to coordinate IT efforts to help out.  Signup via
  >> climatedata-requ...@firemountain.net or, if you prefer Mailman's web
  >> interface, http://www.firemountain.net/mailman/listinfo/climatedata
  >> should work.
  >> 
  >> Thanks,
  >> ---rsk
  >> 
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[Royce Williams]

See also:

https://twitter.com/textfiles/status/808715999042117632

https://twitter.com/textfiles/status/808922272551550976
Jason Scott‏@textfiles
When your boss gives you the goahead to mirror 200tb of NOAA data,
you run with it

Don't let the fact that The Internet Archive is all over this deter
you, though. Coordinate here:

https://docs.google.com/spreadsheets/d/12-__RqTqQxuxHNOln3H5ciVztsDMJcZ2SVs1BrfqYCc/edit#gid=0

Royce

On Fri, Dec 16, 2016 at 7:02 AM, DaKnOb  wrote:
> If you’re interested, there’s also a Slack team: climatemirror.slack.com
>
> You can find more info about that here:
>
> - https://climate.daknob.net/
> - http://climatemirror.org/
> - http://www.ppehlab.org/datarefuge
>
> Thank you for your help!
>
>
>> On 16 Dec 2016, at 17:58, Rich Kulawiec  wrote:
>>
>> This is a short-term (about one month) project being thrown together
>> in a hurry...and it could use some help.  I know that some of
>> you have lots of resources to throw at this, so if you have an
>> interest in preserving a lot of scientific research data, I've set
>> up a mailing list to coordinate IT efforts to help out.  Signup via
>> climatedata-requ...@firemountain.net or, if you prefer Mailman's web
>> interface, http://www.firemountain.net/mailman/listinfo/climatedata
>> should work.
>>
>> Thanks,
>> ---rsk
>>
>

Re: Wanted: volunteers with bandwidth/storage to help save climate data

[DaKnOb]

If you’re interested, there’s also a Slack team: climatemirror.slack.com

You can find more info about that here:

- https://climate.daknob.net/
- http://climatemirror.org/
- http://www.ppehlab.org/datarefuge

Thank you for your help!


> On 16 Dec 2016, at 17:58, Rich Kulawiec  wrote:
> 
> This is a short-term (about one month) project being thrown together
> in a hurry...and it could use some help.  I know that some of
> you have lots of resources to throw at this, so if you have an
> interest in preserving a lot of scientific research data, I've set
> up a mailing list to coordinate IT efforts to help out.  Signup via
> climatedata-requ...@firemountain.net or, if you prefer Mailman's web
> interface, http://www.firemountain.net/mailman/listinfo/climatedata
> should work.
> 
> Thanks,
> ---rsk
> 

Wanted: volunteers with bandwidth/storage to help save climate data

[Rich Kulawiec]

This is a short-term (about one month) project being thrown together
in a hurry...and it could use some help.  I know that some of
you have lots of resources to throw at this, so if you have an
interest in preserving a lot of scientific research data, I've set
up a mailing list to coordinate IT efforts to help out.  Signup via
climatedata-requ...@firemountain.net or, if you prefer Mailman's web
interface, http://www.firemountain.net/mailman/listinfo/climatedata
should work.

Thanks,
---rsk

Re: Prepending with another ASN you don't own

[Randy Bush]

this is called path poisoning.  an italian friend used it in his phd
thesis.  a few friends and i used it to detect use of default across
the internet.

but 42 people will scream "that's my AS!"  of course, as it is your
prefix, that is ASinine :)

ramdu

Re: Prepending with another ASN you don't own

[Rubens Kuhl]

Even in that case I believe you should encapsulate between two instances of
your own ASN. Your example follows this but the text says only about the
last one in the path, while having both last and at least one previous is
better since you won't be implying that some other AS has connection to yet
another AS, it's just you doing this.

Rubens


On Thu, Dec 15, 2016 at 4:54 PM, Andrew Imeson 
wrote:

> Is it acceptable to prepend using another networks ASN as long as your
> ASN is the last one in the path? I can think of a few scenarios where
> this is helpful.
>
> One scenario: Anycast content provider with an ISP (who you aren't
> directly peering with) is choosing to send all traffic to a PoP on
> another
> continent.
>
> Solution:
> Prepend at the geographically-distant PoP so that the AS path looks
> like   , and thus that service provider
> ()
> views it as a routing loop and chooses one of your other PoPs. Sure
> there are better solutions like communities, but why (if it is) would
> this
> be "bad?"
>
> --
> Andrew Imeson
> and...@andrewimeson.com
>

Re: Recent NTP pool traffic increase

[Roland Dobbins]

On 16 Dec 2016, at 16:40, Roland Dobbins wrote:

Looking at the source IP distribution, does a significant proportion 
of the larger query base seem to originate out-of-region?


And are do they appear to be mostly broadband access networks, or . . . 
?


---
Roland Dobbins 

Re: Recent NTP pool traffic increase

[Roland Dobbins]

On 16 Dec 2016, at 6:20, Allan Liska wrote:

 FWIW The US server has seen a spike in traffic, but I have not seen a 
similar spike on the EMEA server.


Looking at the source IP distribution, does a significant proportion of 
the larger query base seem to originate out-of-region?


---
Roland Dobbins 

Network Access to and from China Mainland

[patrick]

Hello,

I have a customer based in Europe which have a subsidiary in China (Mainland) 
and also do a lot of businesses with China (Mainland). Lately the customer have 
a lot of issues with accessing websites which are hosted outside China from the 
subsidiary in China and sees also a lot of delivery problems with emails send 
to China. The SMTP-Gateway is located in Germany and in the logs we can see 
timeouts during the connection to the STMP servers in China (Mainland). I 
suspect that the Chinese Firewall has changed it's behaviour. Have anyone else 
currently similar issues with communication to and from China?

Thanks,
Patrick

Re: Recent NTP pool traffic increase

[Allan Liska]

I manage two NTP servers in the pool, one in the US and the other in
EMEA.  FWIW The US server has seen a spike in traffic, but I have not
seen a similar spike on the EMEA server.  

allan

On 12/15/2016 at 5:46 PM, "Jose Gerardo Perales Soto"  wrote:Hi,

We've recently experienced a traffic increase on the NTP queries to
NTP pool project (pool.ntp.org) servers. One theory is that some
service provider NTP infraestructure failed approximately 2 days ago
and traffic is now being redirected to servers belonging to the NTP
pool project.

Does anyone from the service provider community have any comments?

Gerardo Perales

Prepending with another ASN you don't own

[Andrew Imeson]

Is it acceptable to prepend using another networks ASN as long as your
ASN is the last one in the path? I can think of a few scenarios where
this is helpful.

One scenario: Anycast content provider with an ISP (who you aren't
directly peering with) is choosing to send all traffic to a PoP on
another
continent.

Solution:
Prepend at the geographically-distant PoP so that the AS path looks
like   , and thus that service provider
()
views it as a routing loop and chooses one of your other PoPs. Sure
there are better solutions like communities, but why (if it is) would
this
be "bad?"

-- 
Andrew Imeson
and...@andrewimeson.com