Re: [p2pi] ALTO Information Export Service

[Laird Popkin <[e-mail]>]

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: [phone]

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

> From: "Woundy, Richard" <[e-mail]>
> 
>> 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.

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.

> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> John Leslie
> Sent: Tuesday, October 28, 2008 1:23 PM
> To: Stanislav Shalunov
> Cc: [e-mail]
> Subject: Re: [p2pi] ALTO Information Export Service
> 
> Stanislav Shalunov <[e-mail]> wrote:
>> 
>> 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.tx
> t
> ] ...
> ] 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 <[e-mail]>
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi
> _______________________________________________
> p2pi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/p2pi


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