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
[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
