Subject: [p2pi] ALTO Information Export Service

From: Stanislav Shalunov <[email-masked]>
Date: Mon, 27 Oct 2008 16:16:59 -0700

We put together a first iteration of a very simple ALTO solution  
draft.  We hope this will be useful as an example point in the  
solutions space and thus allow to refine the requirements document and  
the problem statement.

http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.txt

Abstract

    The ALTO Information Export Service is a simple way to convey ISP
    routing policy preferences to applications.  Applications that could
    use this service are those that have a choice in connection
    endpoints.  Examples of such applications are peer-to-peer and
    content delivery networks.

    Applications already have access to great amount of underlying
    topology information.  For example, views of the Internet routing
    table are easily available at looking glass servers and entirely
    practical to download to every client.  What is missing is the
    routing policy information -- what does the local ISP actually
    prefer?

    This document describes a very simple mechanism that would allow to
    export such information to applications.  While such service would
    primarily be provided by the network, i.e., the local ISP, third
    parties could also operate this service.

--
Stanislav Shalunov

_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: John Leslie <[email-masked]>
Date: Tue, 28 Oct 2008 13:23:16 -0400

> http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.txt
] ...
] 7.  Mapping IPs to ASNs

   I expect ISPs will sometimes mean different things by "preferring"
ASNs. (This is a pretty generic problem with ASNs in ALTO.)

   ISPs generally peer with a limited number of ASNs, and reach IPs
"owned" by other ASNs through routes from the ASNs they directly peer
with.

   What actually causes an ISP to "prefer" a set of IPs is knowing that
they will use a route to them through a particular AS they peer with.
This is _not_ the same as which AS "owns" the IP in question. (Nor is
"owned by an AS" necessarily a meaningful statement for a CIDR block.)

   BGP looking-glass views show which ASNs "originate" routes to a
CIDR block. It is not particularly unusual to find more than one AS
"originating" such a route. Thus, looking-glass results cannot assure
that the route a packet will actually follow to reach an IP address
_ever_ passes through a particular AS.

   Looking-glass views _will_ generally show "holes" punched in CIDR
blocks "owned" by one AS for the purpose of balancing traffic to a
multihomed customer of that AS (even though it may be that _none_ of
the traffic will actually pass through the "owner" AS). But looking-
glass views tend to contain routes that are never seen by routers
not "near the backbone".

   The routing view which actually matters is the view of the ISP
router which dispatches the particular packet at a peering point.
Thus, IMHO, the ISP should usually be the provider of the mapping of
IPs to ASNs.

   (This mapping may change several times per second when routes
"flap", but that's a balancing act the ISP is best able to attempt.)

   In any case, if ALTO provides ASN "preferences" at all we should
provide a mechanism for the ISP to perform mapping of IP to ASN.
(IMHO, at least...)

--
John Leslie <[email-masked]>
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 28 Oct 2008 19:00:35 -0400

> The routing view which actually matters is the view of the ISP router
which dispatches the particular packet at a peering point. Thus, IMHO,
the ISP should usually be the provider of the mapping of IPs to ASNs.

Before this email, my opinion was that if an ISP wanted to include
ASN(s) in the policy to be returned by the ALTO service, then the ISP
should also supply the IP prefix to ASN mappings, so that the combined
ALTO service guidance came from a consistent information source (the
ISP). But I didn't have a strong opinion against using a looking glass
server instead for the IP-to-ASN mappings.

If I understood John correctly, the looking glass server's view of
IP-to-ASN mappings may depend on the server's location in the Internet
topology, and that view may not be equivalent to the view of the ISP
providing the ALTO service.

Here is one example: Within one ISP's backbone, there may be a set of
specific IPv4 prefixes coming from many origin AS's. Within another
ISP's backbone, these specific prefixes may have been replaced (and
subsumed) by a single aggregate prefix with a different origin AS (e.g.
the first backbone). Therefore, the looking glass servers for the first
and second backbones would differ on the correct origin AS with respect
to this aggregated prefix.

Here is a relevant RIPE presentation (from 2003) in which they faced
similar problems with reporting ASNs in traceroutes:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-tt-as-tra
ceroutes.pdf. In the scenario of the RIPE presentation, the route
information in the Internet Routing Registries and in the global BGP
routes were often at odds with one another; slides 8, 10, and 11
describe some interesting cases that relate to this discussion about
looking glasses.

John, in short, I think you make a very good point.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Leslie
Sent: Tuesday, October 28, 2008 1:23 PM
To: Stanislav Shalunov
Cc: [email-masked]
Subject: Re: [p2pi] ALTO Information Export Service

> the problem statement.
http://www.ietf.org/internet-drafts/draft-shalunov-alto-infoexport-00.tx
t
] ...
] 7.  Mapping IPs to ASNs

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 28 Oct 2008 16:48:38 -0700

I agree with you Rich. Getting an accurate mapping of IP to 'owner' ASs is
not an easy task. Some people spent a lot of time on this. I did not know
this presentation.

Here is a another very good reference:

Towards an Accurate AS-Level Traceroute Tool
Zhuoqing Morley Mao Jennifer Rexford Jia Wang Randy H. Katz
UC Berkeley AT&T LabsResearch AT&T LabsResearch UC Berkeley
[email-masked] [email-masked] [email-masked]
[email-masked]

In this paper they discuss in detail all the roadblocks to have a traceroute
tool that maps IP to ASs.

Thanks,

Reinaldo

---

From: Salman Abdul Baset <[email-masked]>
Date: Wed, 29 Oct 2008 00:05:44 -0400 (EDT)

Mapping IP addresses to AS numbers by quering RIRs:
http://www.bugest.net/software/aslookup/index-e.html

-s

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 28 Oct 2008 21:22:30 -0700

Interesting.

How do I interpret its results? For example, first IP addresses I put.

 ./aslookup -r 200.200.200.1 | more

Who owns this prefix? Is it AS7132 (SBC), AS4230(Embratel) or
AS28513(Telmex)?

751:route:      200.200.200.0/24
descr:      cccoe.k12.ca.us
origin:     AS7132
mnt-by:     MAINT-AS7132
changed:    [email-masked] 20030317
source:     RADB

route:      200.200.0.0/16
descr:      EMBRATEL BRAZIL
origin:     AS4230
remarks:    -------------------------------------------------
remarks:    For SECURITY issues, please send messages only to
remarks:    [email-masked]
remarks:    -------------------------------------------------
notify:     [email-masked]
mnt-by:     MAINT-EMBRATEL
changed:    [email-masked] 20070222
source:        NTTCOM

route:         200.200.0.0/16
descr:         EMBRATEL
origin:        AS28513
mnt-by:        TELMEX-MNT
changed:       [email-masked] 20081014
source:        LEVEL3
DATA Type C
Complete

---

From: stefano previdi <[email-masked]>
Date: Wed, 29 Oct 2008 14:55:04 +0100

> From: "Woundy, Richard" <[email-masked]>
> 

that is right. BGP is a path vector protocol which means that the visibility
any router gets from its BGP peers, correspond to the selection mechanisms
those peers have done (vector-based protocols: first select best route, then
advertise best route).

This is valid for any looking glass server as well as for any ALTO server,
which implies that any preference scheme may vary according to each SP
location/pop where it is computed.

s.

---

From: Laird Popkin <[email-masked]>
Date: Wed, 29 Oct 2008 11:23:16 -0400 (EDT)

Keep in mind that ASNs are just an option in ALTO (as we're discussing it so far), so even if the P2P network uses a public IP to ASN mapping database, the ISP can provide their own IP prefix guidance without referencing ASNs if they care to.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "stefano previdi" <[email-masked]>
To: "Richard Woundy" <[email-masked]>, "John Leslie" <[email-masked]>, "Stanislav Shalunov" <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, October 29, 2008 9:55:04 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO Information Export Service

s.

---

From: stefano previdi <[email-masked]>
Date: Wed, 29 Oct 2008 16:33:03 +0100

> From: Laird Popkin <[email-masked]>
> 
> Keep in mind that ASNs are just an option in ALTO (as we're discussing it so
> far), so even if the P2P network uses a public IP to ASN mapping database, the
> ISP can provide their own IP prefix guidance without referencing ASNs if they
> care to.

I agree.

However, I also believe on the usefulness BGP can deliver in ranking
preferences. The point to keep in mind is that BGP is location-dependent in
terms of computation (which may not be the case for other routing
protocols).

s.
 
> To: "Richard Woundy" <[email-masked]>, "John Leslie"
> <[email-masked]>, "Stanislav Shalunov" <[email-masked]>
> Cc: [email-masked]

---

From: John Leslie <[email-masked]>
Date: Wed, 29 Oct 2008 11:47:44 -0400

Laird Popkin <[email-masked]> wrote:
> 
> Keep in mind that ASNs are just an option in ALTO (as we're discussing
> it so far), so even if the P2P network uses a public IP to ASN mapping
> database, the ISP can provide their own IP prefix guidance without
> referencing ASNs if they care to.

   Indeed they can -- (by omitting any ASN guidance at all).

   But then, why include the option?

   The advantage of including an ASN option, IMHO, is that a policy can
be stated in a reasonably static manner using ASNs -- provided that the
meaning of those ASNs is clearly "where my routers will forward packets".

   This avoids having to frequently update policy as routing tables change
and having to state policy for hundreds of thousands of CIDR blocks.

   A downside is that ALTO clients may lack up-to-the-minute routing
information when mapping IPs to ASNs. That, IMHO, is something to work
on when the ALTO WG is formed. Several "good-enough" approaches suggest
themselves...

   But if clients are encouraged to use mapping quite unrelated to the
actual routing, then policy stated in ASNs is actively misleading. I
would much prefer not to _design_ misleading policy into ALTO.

---

From: Laird Popkin <[email-masked]>
Date: Wed, 29 Oct 2008 12:47:19 -0400 (EDT)

I agree with your analysis, up until the last paragraph.

I don't understand why you say that "policy stated in ASNs is actively misleading" though. Keep in mind that ALTO helps p2p networks find good endpoints, not good routes - that's done by BGP, OSPF, etc., when actually exchanging data. That is, a p2p network knows that it can exchange data between a addresses within (to make up an example) AT&T NYC and Verizon NYC, but it can't control the actual route that the data flows through. Of course, selecting endpoints that have cheap routes between them makes it likely that those cheap routes are actually used, but that's more a matter of the lower layers working properly than anything ALTO allows ISPs to directly express.

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 29 Oct 2008 10:08:42 -0700

If you say "prefer this ASN" (since you are implicitly or explicitly for
that matter) assuming that prefix 1.1.1/24 is hosted in that ASN but is
actually not, then is misleading, yes?

On 10/29/08 9:47 AM, "Laird Popkin" <[email-masked]> wrote:

> I don't understand why you say that "policy stated in ASNs is actively
> misleading" though. Keep in mind that ALTO helps p2p networks find good
> endpoints, not good routes - that's done by BGP, OSPF, etc., when actually
> exchanging data. That is, a p2p network knows that it can exchange data
> between a addresses within (to make up an example) AT&T NYC and Verizon NYC,
> but it can't control the actual route that the data flows through. Of course,
> selecting endpoints that have cheap routes between them makes it likely that
> those cheap routes are actually used, but that's more a matter of the lower
> layers working properly than anything ALTO allows ISPs to directly express.
>

---

From: John Leslie <[email-masked]>
Date: Wed, 29 Oct 2008 13:56:30 -0400

Reinaldo Penno <[email-masked]> wrote:
>> endpoints, not good routes - that's done by BGP, OSPF, etc., when
>> actually exchanging data.

   So far as I know, ALTO is completely unrelated to "finding good routes"
(which, BTW, is an issue possibly worth pursuing for multihomed users).

   While we hope that ALTO will help "find good endpoints", we're talking
about a (small) piece of ALTO only loosely related to that -- ISP policy.

>> selecting endpoints that have cheap routes between them makes it likely
>> that those cheap routes are actually used, but that's more a matter of
>> the lower layers working properly

   ... which is mostly the responsibility of the ISP...

>> than anything ALTO allows ISPs to directly express.

   It's premature, IMHO, to talk of what ALTO "allows".

> actually not, then is misleading, yes?

   Any case where the publisher of information assumes one meaning while
the user assumes a different one, I would call "misleading".

   Reinaldo raises an issue -- whether an ISP might want to express an
opinion on whether CIDR blocks served by a particular AS are better or
worse than "average". I must admit (as an ISP) that I would not.

   But perhaps some ISP might -- and if so, they should be able to list
list opinions about ASNs separately from their own routing preferences.