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

[Volker Hilt <[e-mail]>]

Stefano, Richard,

great discussion.

I believe that the capability to provide a simplified view on the 
network topology to an application is a key feature rather than a bug. 
Applications that want to have a view on network topology don't need 
need a fine grained view on the topology in most casts and benefit from 
having an abstracted view. This will simplify processing for the 
application and enables providers to control the exposure of details. 
We've seen some numbers for topology data sizes in the incremental 
updates presentation in the ALTO meeting, which provide some insights 
into the amounts of data needed for different topology sizes.

I like the idea of enabling an ALTO server to offer different levels of 
details. This will enable a server to tailor responses to the specific 
client. It will add complexity as the ALTO server itself will have to 
maintain the most complex topology it is offering and will have to keep 
this topology up to date. But this is an interesting question for 
discussion in the WG.

Cheers,

Volker







On 03.08.2012 11:03, Y. Richard Yang wrote:
> Hi Stefano,
>
> Good post! I added the ALTO mailing list, given the relevance. I hope
> that this is OK cross posting.
>
> First, a few comments on ALTO:
>
> View granularity:
>
> - ALTO currently defines two abstract network topology data structures:
> Network Map and Cost Map(s). More link-state oriented maps (graphs),
> with aggregations and transformations, can be added efficiently to ALTO.
> Some initial efforts are already on the way (e.g., see the graph
> representation proposal at page 9:
> http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence,
> I see a natural next-step is for ALTO to provide a link-state view to
> external entities.
>
> - It is a good comment on the level of details that ALTO should
> delivery. This is a good question for the ALTO working group and the
> community to discuss. I feel that ALTO should provide multi-levels of
> granularity of views, and we should discuss in the working group.
>
> Pull vs push delivery mechanism:
>
> - There are more discussions on adding the incremental update in ALTO.
> Multiple mechanisms have been discussed. I feel that it is the right
> direction for ALTO.
>
> Now let me understand the deployment model of BGP-LS. Your explanation
> on the issues of acquiring routing state is excellent. Let me start by
> understanding more details on the deployment model of BGP-LS inside a
> network:
>
> - A set N_igp of BGP-LS instances are deployed to collect IGP info. You
> need multiple instances because IGP needs direct connectivity
> (adjacency). Each instance here receives (potentially multiple) IGP
> updates and streams (relays) to an another (remote) entity, which I
> assume is a master BGP-LS instance. So each of these N_igp instances is
> IGP-in and BGP-LS out. This appears to be shown in Figure 1 of
> draft-gredler-idr-ls-distribution.
>
> - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You
> also may need multiple instances because the network does not want to
> see aggregated states but raw states. These instances will feed to the
> master BGP-LS as well.
>
> - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some
> direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to
> use: for example, an ALTO Server transforms/aggregates the feed to
> generate ALTO views (maps and graphs), and an PCE uses the feed to
> maintain its TED. One could even imagine that ALTO builds a detailed TED
> and feeds to PCE, but this beyond the scope of this discussion. The
> master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the
> master BGP-LS does not push to any other entities and simply maintains
> an internal DB for others to query.
>
> Do I understand it correctly?
>
> Now, we can take a look at more specifics of BGP-LS.
>
> A first perspective is the semantics of the content. If the objective is
> to solve the aforementioned deployment issue, then an alternative
> solution is to introduce a simple LS update tunneling protocol, where a
> link-state proxy forwards LS messages to a collector. The current design
> of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
> Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
> OSPF, etc). However, the protocol appears to (try to) go beyond simple
> tunneling and introduces a common LS schema, by converting/filtering
> individual IGP LS messages to some common format. I feel that it can be
> helpful to first specify the schema (LS data model) instead of the
> specific encoding. For example, OSPF specifies LS Age, and this is
> filtered. (Please correct me if I missed it). On the other hand, one can
> think that some Age info can be helpful for one to understand the
> "freshness" of the LS. A problem studied in database is heterogeneous
> databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
> schema, and there can be many problems. If there is such a study, please
> do share a pointer.
>
> A second perspective is using BGP as the transport. What key features
> from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
> flexibility)? What features of BGP do we not need (e.g., BGP is a
> routing protocol and hence builds in features to handle convergence such
> as dampening)? What may be missing (e.g., a capability of pull or
> filtering of push). I feel that these issues should be discussed. If
> they have already been discussed, please do share a pointer, as I am
> definitely a new comer.
>
> Thanks!
>
> Richard
>
> On 8/2/12 11:54 PM, stefano previdi wrote:
>> 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
>>>
>> _______________________________________________
>> 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