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

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

Hi,

Sue suggested that I forward this email to idr for more discussions.

Thanks.

Richard

On 8/3/12 11:24 AM, Susan Hares wrote:
> Richard:
>
> Could you cross-post this note to the [e-mail] list. The BGP-LS draft is being considered for WG adoption. I think this perspective would help the idr WG.
>
> Thank you,
>
> Sue
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Y. Richard Yang
> Sent: Friday, August 03, 2012 11:04 AM
> To: stefano previdi
> Cc: Thomas Nadeau; James Kempf; IETF ALTO; [e-mail]; [e-mail]
> Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS
>
> 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
> deliver. 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