Re: [irs-discuss] [Idr] [alto] About ALTO, BGP-LS, IRS

[Hannes Gredler <[e-mail]>]

hi greg,

see comments inline prefixed by HG>

On Thu, Aug 09, 2012 at 08:47:09AM -0700, Greg Bernstein wrote:
| Some questions and comments on IRS, IDR, and ALTO...
| 
| Would IRS apply to GMPLS controlled boxes such as TDM (G.709, SDH) or WDM
| (WSON) network elements?
| Setting state in a GMPLS controlled box can be rather trivial, i.e., just
| setting up a cross connect. The penalties for screwing up the state in a WDM
| box are rather terrible... Would IRS want state for all the LSP's traversing a
| box?
| 
| I'm a infrastructure plumber and trying to get folks to use the nifty optical
| control plane more. In GMPLS we have technology specific data models (SDH,
| G.709, WSON) that are fairly independent of specific routing protocols (OSPF,
| IS-IS) so these can help with the modeling aspect of IRS.  However, in the
| early days of GMPLS folks thought everything should be done in the same IGP
| instance, later the OSPF folks decided multiple instances were better since the
| service impacts of routing protocols is much different for circuit switched
| technologies than IP.
| 
| The model we are interested for in large-bandwidth use-cases in ALTO tries to
| abstract away as many layers as possible.  For example, suppose that the use-
| case is to set up a large IP pipe between mulitple data centers.  We could show
| an abstracted graph that helps guide paths choices via costs and bandwidth
| constraints.  The actual implementation technology could be IP-MPLS-G.709-MPLS-
| IP  or IP-OpenFlow-WSON-OpenFlow-IP  (here I just mean a simple OpenFlow
| controlled Ethernet switch that that can feed into our optical "express lane").
| 
| In other cases the data centers might want some special ethernet connectivity
| over optical pipes (a different type of service).
| 
| When I think of an IDR and sharing information between ASs then one may want to
| (or need to) keep (sub-IP) layer specific for compatibility, i.e., connecting
| the pipes between domains and adapting the higher layer protocols back out. 
| It's useful to look at publicly available service maps for examples, I like
| Level3's maps (http://maps.level3.com/default/#.UCFpjJYu9rh) --compare
| wavelength services to other services -- and CenturyLink (http://
| www.centurylink-business.com/demos/network-maps.html) -- note how wavelength
| service availability is limited compared to other services (our big pipe
| networks are generally simpler than other service networks) --.
| 
| It seems what BGP-LS would deliver to an ALTO server to digest and serve up in
| abstracted form could be very different from what might be shared between
| ASes.  

HG> BGP-LS feeding an L3 routing topology into an ALTO server is one particular
application of the protocol. as you may have noticed the encoding of the link entries
in BGP-LS is a superset of all IGP extensions most notably including the MI
(multiple instance) drafts. as such one could carry higher or lower-layer
graphs (e.g. graphs of application clusters / graphs of DWDM wavelengths).
sicne you are concerened about optical gear feel free to send text on the
GMPLS link attributes that you would like to have supported.


| 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]> 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]>
|                                    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
|                                         irs-
|                                         [e-mail]
|                                         https:
|                                         //
|                                         www.ietf.org/
|                                         mailman/
|                                         listinfo/
|                                         irs-
|                                         discuss
|                                    _______________________________________________
|                                    irs-
|                                    discuss
|                                    mailing
|                                    list
|                                    irs-
|                                    [e-mail]
|                                    https://
|                                    www.ietf.org/
|                                    mailman/
|                                    listinfo/
|                                    irs-
|                                    discuss
| 
| 
|                               _______________________________________________
|                               irs-discuss mailing
|                               list
|                               irs-
|                               [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
| 
| 
|      _______________________________________________
|      alto mailing list
|      [e-mail]
|      https://www.ietf.org/mailman/listinfo/alto
| 
| 
| --
| ===================================================
| Dr Greg Bernstein, Grotto Networking [phone]

| _______________________________________________
| Idr mailing list
| [e-mail]
| https://www.ietf.org/mailman/listinfo/idr