[119625] in North American Network Operators' Group
Re: Who has AS 1712?
daemon@ATHENA.MIT.EDU (Joe Abley)
Wed Nov 25 01:36:04 2009
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <m2hbsj8akr.wl%randy@psg.com>
Date: Tue, 24 Nov 2009 22:34:30 -0800
To: Randy Bush <randy@psg.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 2009-11-24, at 20:58, Randy Bush wrote:
>> Right. You can't advertise an ASN
>> you can only advertise a route and include an AS_PATH attribute on it
>> which makes mention of a particular AS number.
>=20
> that bit of biff-like pedantry quickly leads to you can't advertise a
> prefix.
Apologies if the pedantry seems unnecessary. I think the parallel =
between the announcement of a route (which has inherent reachability =
information contained within it) and use of an ASN in an AS_PATH =
attribute (which doesn't always) are different with respect to =
identifying use of a resource.
Overloading "advertise" for both suggests you can identify use of a =
resource elsewhere using the same measurement technique, which I think =
is broken logic.
> a bgp announcement has, in the case of ip unicast, an nlri and,
> among other things, an as-path. see rfc 1771 4.3 on Path Attributes.
I used the word "route" in the sense that it's defined in 4271.
> as to what is being announced and what is merely loitering waiting for =
a
> hot pick-up, you can work that out with your mullah, priest, rabbi,
> spouse, ...
As a divorced atheist I guess I'll just read RFCs :-)
> for unusual utility of intentionally announcing a particular asn, see
> as-path poisoning, e.g. lorenzo's thesis [0], the talk which was =
banned
> at nanog [1], or the full paper [2].
Josh and I also talked about it at NANOG 24. I remember using it to =
poison routes advertised through certain edges of AS 1221 a decade ago =
after the idea was suggested to me by Geoff Huston, and I'm sure it was =
probably old news then.
>> My point is that in the absence of any mechanism for announcing an
>> ASN, a plan to gate assignment of numbers based on an announcement
>> doesn't make any sense.
>=20
> seeing if an asn is in a currently-announced as-path is useful, as has
> been pointed out in this discussion.
I don't think it's as simple as people have suggested.
The fact that nobody has ever seen a particular number present in an =
AS_PATH attribute might mean that the ASN has never been configured on a =
router, or it might mean that nobody has ever taken a measurement from a =
router who has seen such a route.
The fact that someone has seen a particular number present in an AS_PATH =
attribute might mean that that number has been used for a particular =
autonomous system, or it might mean that someone is doing something =
(intentional or otherwise) with AS_PATHs for their own personal reasons.
The topic of this thread is really concerned with database hygiene in a =
distributed system which, as you have pointed out repeatedly, lacks =
procedural or mathematical rigour. Checking whether or not a particular =
AS_PATH regex matches anything in one or more RIBs might tell you =
something, or it might give you clues as to who to call to find out =
more, but it can never tell you anything definitively. Definitive =
knowledge sure seems like it's what you want if your job is to guarantee =
uniqueness.
It seems to me that at some point we need to stop trying to put dresses =
on the pig.
Joe=
