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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
