[irs-discuss] About ALTO Vs. BGP-LS

[stefano previdi <[e-mail]>]

All, 

as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few 
things:

ALTO has been designed in order to deliver to applications (through 
http/json):

1. two maps representing the network topology in an abstracted view 
   (or set of views through multiple maps). The map does not include 
   the details of a link-state database and therefore have little use 
   for any element that would need to retrieve from the network the 
   detailed/complete network layer topology, for example: link 
   addresses or link BW resources, etc. IOW: ALTO maps do not have 
   the granularity of a link-state database and ALTO protocol is not 
   designed to deliver such details.

and/or

2. Ranking services where a client sends a bunch of IP addresses in 
   a message and the ALTO server replies by ranking these addresses 
   based on their topological/network distance (or whatever criteria 
   the ALTO server has been configured for). This is called: Endpoint 
   Cost Service.

When using ALTO maps, and the ALTO protocol being http/pull based, 
there's no such concept of unsolicited routing updates. An ALTO 
client is typically a browser that will pull the maps from an ALTO 
server using http. The ALTO server will make no effort to ensure the 
client has the latest view of the topology (i.e.: It's the role of the 
client to poll for new maps time to time).

Now, in order for an ALTO server to deliver Maps or Ranking services, 
it needs to build some form of topology and in order to achieve this, 
it needs somehow to be fed by either the operator (configuration) or 
to receive dynamically topology information from the network (e.g.: 
ISIS/OSPF/BGP).

Here we had two options:
1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies 
   to ABRs or L1L2 routers in each area so to retrieve the LSDB from 
   each area. In practice I know no SP willing/accepting to open their 
   IGP to an ALTO server. Also, IGP requires direct connectivity 
   (adjacency) so from an operation point of view is complex and not 
   desired.
2. Use a database distribution protocol running on top of a reliable 
   transport layer that would allow an ALTO server to connect to a 
   _single_ and _remote_ Route Reflector (i.e.: no need to be directly 
   connected) and grab the whole network topology that will be updated 
   using standard routing protocol mechanisms (i.e.: routing updates)
   and that would allow the operator to control (through policies and 
   filters) what to distribute and to which server.

   Benefits: single (or dual at most for redundancy) connection for 
   the ALTO server (rather than having a direct adjacency with each 
   ABR) and, from the operator perspective, single point of 
   distribution of network topology (easier to apply policies and 
   control what you deliver). This is what BGP-LS is about. 

BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey 
link-state and, more generically, any type of topology information. 
The draft specifies NLRI and attributes that map whatever you can 
find in a link-state database.

We currently have draft-gredler-idr-ls-distribution in the process 
(hopefully) to be adopted as WG item in IDR WG (so far we 're getting 
good support). We also have 3 implementations of BGP-LS.

Deployment-wise: BGP-LS is not yet deployed, however, we already have 
deployments (I know at least two) where an ALTO server retrieves IP 
prefix information from remote BGP RRs (for ipv4). The same scheme 
will be used once BGP-LS will be deployed (so to say that it is not 
something that we invented after a couple of beers but corresponds to 
requirements for delivering network services to upper layers while 
still controlling efficiently what you distribute, to whom and in 
which form (note that, often, beers are anyway part of the process).

More information here:
http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
http://tools.ietf.org/html/draft-ietf-alto-protocol-12

Hope this helps.

s.



On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
> Tom,
> 
> > I agree that one of the top work items for this effort should be a
> > standardized topology function, and one that is accessible via a
> > non-routing protocol.
> 
> So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS.
> 
> However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation.
> 
> The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;)
> 
> R.
> 
>> 
>> 	I agree that one of the top work items for this effort should be a
>> standardized topology function, and one that is accessible via a
>> non-routing protocol.  While not exactly "low hanging fruit", it is
>> something that (to me) is a clear work item with clear goals that should
>> be tackled straight away.
>> 
>> 	--Tom
>> 
>> 
>> 
>> On 8/2/12 3:24 PM, "James Kempf" <[e-mail]> wrote:
>> 
>>> So after seeing part of Alia's talk this morning (I had to leave in the
>>> middle unfortunately), I'd like to make a couple suggestions. There were
>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>> think to make tangible progress, the work needs to be focussed on a small
>>> subset that would be of immediate interest and usability.
>>> 
>>> There are a couple areas that suggest themselves, but one that would be
>>> useful in work that I've been involved in is a standardized format for
>>> network topology representation and a protocol for exchanging it. The
>>> Onix OpenFlow controller has a network information base with a
>>> specialized format for network topology, and every OpenFlow controller
>>> requires this. Having a standardized way to represent it might foster a
>>> common topology database package. Another application is network
>>> management. Every network management system needs some kind of topology
>>> representation. Finally, though I am not an expert in PCE construction,
>>> it would seem to me that a PCE would need some kind of topology
>>> representation in order to perform path calculations. Having a way,for
>>> example, for the OpenFlow controller and the PCE to exchange topology
>>> information would be really useful.  I would say to start with physical
>>> topology because that is fundamental, but make the format flexible enough
>>> to support
>>> virtual topology representation.
>>> 
>>> 			jak
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
>> 
> 
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>