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" <[email protected]> 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" | <[email protected]> | 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- | [email protected] | https: | // | www.ietf.org/ | mailman/ | listinfo/ | irs- | discuss | _______________________________________________ | irs- | discuss | mailing | list | irs- | [email protected] | https:// | www.ietf.org/ | mailman/ | listinfo/ | irs- | discuss | | | _______________________________________________ | irs-discuss mailing | list | irs- | [email protected] | https:// | www.ietf.org/ | mailman/listinfo/ | irs-discuss | | _______________________________________________ | irs-discuss mailing list | [email protected] | https://www.ietf.org/mailman/ | listinfo/irs-discuss | | _______________________________________________ | irs-discuss mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/ | irs-discuss | _______________________________________________ | irs-discuss mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/irs-discuss | | | _______________________________________________ | alto mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/alto | | | -- | =================================================== | Dr Greg Bernstein, Grotto Networking (510) 573-2237 | _______________________________________________ | Idr mailing list | [email protected] | https://www.ietf.org/mailman/listinfo/idr _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
