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

["Y. Richard Yang" <[e-mail]>]

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