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

[Greg Bernstein <[e-mail]>]

Hi Alia, one key use case that needs a different level of abstraction is 
the "large bandwidth" use-case. In the P4P paper Richard Yang and 
co-authors were able to affect traffic engineering by changing the path 
costs over time.  However in the "large bandwidth" case we need explicit 
information on bandwidth constraints 
(http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02).

Another dimension to the "abstraction" levels was that of the scope/span 
of users of the information.  Currently ALTO is aimed at open, 
"Internet" -like environments.  However some of the extensions being 
proposed may apply in more "controlled" or "restricted" environments.

Although we are trying to hide network details from the ALTO users there 
may be cases with particular technology information is important. For 
example in our "large bandwidth" use-case document we showed how to 
shared multiple spanning tree instance (MSTI) Ethernet graphs in reduced 
form for VLAN to MSTI assignment in a data center.  We also gave  
optical (WDM and TDM) examples.

Cheers

Greg B.

On 8/3/2012 4:57 PM, Alia Atlas wrote:
>
> I strongly agree that we need to start collecting the use-cases for 
> multiple abstraction levels as well as physical/virtual/private.
>
> Alia
>
> On Aug 3, 2012 4:51 PM, "Y. Richard Yang" <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Volker,
>
>     On 8/3/12 12:02 PM, Volker Hilt wrote:
>
>
>         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.
>
>     Agreed.
>
>         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.
>
>     Glad that you also like the idea of different levels of details of
>     the network topology. If the ALTO Server is given a detailed
>     topology (constructed from multiple sources, such as routing feed,
>     LSP feed, configuration files), we can offer multiple topology
>     operators/aggregators to explore the detailed topology, according
>     to need and policy. A simple example operator is level (i.e.,
>     hierarchy such as at the area level), but one might specify other
>     operators (e.g., fisheye focus). There are studies on
>     representation of multi-level graphs that we can try to take
>     advantage of. This can be a subject for the group to explore.
>
>     We may need to study/collect use cases for multiple level
>     topology. One interesting example immediately coming to mind is
>     the Abstract Node concept (specify IP prefix/ASN) used in RSVP-TE.
>
>     Cheers,
>
>     Richard
>
>         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]
>                         <mailto:[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]
>                             <mailto:[e-mail]>
>                             https://www.ietf.org/mailman/listinfo/irs-discuss
>
>                         _______________________________________________
>                         irs-discuss mailing list
>                         [e-mail] <mailto:[e-mail]>
>                         https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>                     _______________________________________________
>                     irs-discuss mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/irs-discuss
>
>                 _______________________________________________
>                 irs-discuss mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>             _______________________________________________
>             irs-discuss mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/irs-discuss
>
>     _______________________________________________
>     irs-discuss mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]