Subject: About NAROS

From: marcelo bagnulo <[email-masked]>
Date: 23 Jun 2003 20:38:12 +0200

Hi Cedric,

About NAROS for TE, i was wondering if  policy table defined in RFC 3484
could provide the capabilities needed for performing TE?
I mean, RFC 3484 defines a policy table that is to be used for defining
policies, such as which source address to prefer when reaching a given
destination address, which i think is what the NAROS TE application
achieves.
So i was thinking why not just complete the table with the sites
policies to achieve this goal.
The problem is that currently there is no way to dynamically configure
the policy table, so NAROS could be used for this. In this way, once the
hosts obtains the policy information, it configures its policy table and
uses it for following packets.

An alternative option would be to define a new dhcp option to configure
the policy table, so that when the hosts boots it obtains the policy
table configuration from the dhcp server. The problem with this solution
would be if the policy table is too large or too dynamic, in which case,
i guess that using NAROS would provide better performance. Another
option would be to use the NAROS server a single point for specifying
policy and that the dhcp server obtain the policy table configuration
from it. Have you considered any of these options?

About fault tolerance capabilities. As defined in the draft NAROS server
would only be aware of direct providers outages. However, i guess that
NAROS server capabilities to select the appropriate address could be
improved if the NAROS server had additional information, such as the BGP
routing table, moreover, i guess that it would be interesting that the
NAROS server had the bgp routing table view from each of the borders
routers connected to different isps. With this information, it would be
capable of knowing which addresses are reachable from each provider and
perform a better address selection. However, i would say that some
failures would remain undetected by the NAROS server, essentially due to
aggregation. This implies that an additional mechanism for failure
detection is needed, probably and e2e mechanism.

Thanks, marcelo

---

From: Cedric de Launois <[email-masked]>
Date: 24 Jun 2003 16:25:36 +0200

> uses it for following packets.
This is precisely what we were thinking of when we wrote in the draft 
"[NAROS] complements [...] the default IPv6 source address selection
algorithm". 

> from it. Have you considered any of these options?

Our starting point is quite different : we require TE capabilities.
So we need a system which can dynamically adapt to the situation
(failure, load unbalance, etc.). And the policy table seems to be both
too large and too dynamic for DHCP. If a site uses NAROS, it can
get, for the same price, TE capabilities. And I feel the use of DHCP
would only mitigate TE.

> routers connected to different isps. 

Agreed ! When we evaluated the NAROS
performances, we used a BGP table to find the BGP prefix associated
to the destination address. This is because we imagine this solution,
where a NAROS server is located on each site exit router, and so
gets access to a BGP table. Using this BGP table, it can find (or not)
a route towards the destination and it can somehow transmit this
connectivity information to a host.
However, we should not restrict ourself to BGP. NAROS could also
use other mechanisms, e.g. active or passive probing of common
destination, to know the best routes.

> With this information, it would be
> aggregation. 

Indeed. We are fully aware of that.

> This implies that an additional mechanism for failure

Agreed. We believe failure detection can only fully happen in the end
hosts. NAROS only gives hints to select the best addresses. The hosts
still make the final decision.

Regards,

Cédric

---

From: marcelo bagnulo <[email-masked]>
Date: 25 Jun 2003 17:57:07 +0200

> "[NAROS] complements [...] the default IPv6 source address selection

Ok. I guess that the response of the NAROS server could be used for
adding an entry to the Policy table of the default address selections
algorithm. So when a response from the NAROS server is obtained linking
a given destination address (DA) with a source address (SA), the host
can include an additional entry to the policy table with DA and SA and
the same label. In this way, next packets for this DA will obtain a
matching label and the default address selection algorithm can return a
source address for DA.

> too large and too dynamic for DHCP.

I am not sure of this. I guess this really depends on the case you are
considering.

First of all, failure issues will have to be addressed by other means,
because only the end hosts can perform the e2e path failure detection.

Then, about the policy table dynamics. I guess there may be site whose
policy change very fast, but i would say that there are sites that have
a somehow stable policy, that does not change everyday, so configuring
the policy when the hosts boots (using dhcp) would be acceptable.

About the size of the table, i would like to have more information about
this. I mean some large site may have a very complex policy that has to
be expressed in a way that can not be stored in hosts, but for these
very large sites, would a multi-address solution be acceptable? I would
say no, considering some comments made in this list.

So, as i see it, very large sites may have complex policies that require
a very high dynamic and a lot of space to store it, but i am not sure
whether these sites will use a multi-address solution.
OTOH, sites that could use multi-address solutions are more medium small
sites, which i am not sure if they have such complex policies.

In brief, i am just saying that i wouldn't discard dhcp yet, i think
that both NAROS and dhcp could be used to configure the default address
selection policy table. I think that a mechanism for configuring the
policy table other than manual will be needed.  

 If a site uses NAROS, it can
> gets access to a BGP table.

Yes, but my point is that the NAROS server need to know the bgp table of
each border router in order to perform a better address selection. In
this way, the NAROS server knows which addresses are reachable through
each one of the border routers and can select the appropriate source
address.

I think that consulting the NAROS server is a more general approach than
prefix deprecation. I mean, i guess that the only case where the prefix
assigned by an ISP can be fully deprecated is when the link (or the
router) to that isp fails. In this case, the NAROS server can detect it
(for instance no bgp information) and it can deprecate the prefix.
However, when other outages occur, such as an outage of the ISPs link
with its own provider, deprecating the prefix may not be the better
solution, since some of the destinations can only be reachable using
this prefix. So if the NAROS server has the bgp view of all the all the
border routers, it could provide the right source address for each case.

Regards, marcelo

 Using this BGP table, it can find (or not)

---

From: Cedric de Launois <[email-masked]>
Date: 26 Jun 2003 16:22:49 +0200

> matching label and the default address selection algorithm can return a

You got the idea. A NAROS client can process a NAROS response by simply
filling the Policy table of the default address selections algorithm.
Moreover, if an API is available to manage this policy table, 
(and according to RFC3484, it should) then the NAROS client-side part
can be easily implemented in user-level.

I am already thinking about possible extensions to NAROS. One idea is to
add an option in a NAROS request to specify the type of service desired.
For example, a host could ask the NAROS server which is the best
link for video-conferencing or VoIP. The NAROS server could then reply
so that the fastest link with the lowest delay is used.

> because only the end hosts can perform the e2e path failure detection.

Agree again. The NAROS only gives hints about which addresses to use.
NAROS is used when the host has no information to choose between 
two or more addresses otherwise equivalents.
If a host knows (e.g. by a e2e path failure detection) that only 2 of
its 3 allocated addresses can be used to reach the destination, then the
host is free to asks the server to choose between the two remaining
addresses. This is also why a client must always put in the NAROS
request the source addresses it is willing to use.

> the policy when the hosts boots (using dhcp) would be acceptable.

This is a solution if you prefer extending DHCP instead of
implementing the NAROS client. However, if a host is NAROS-aware,
it can automatically get the full content of the [small] policy
table by initiating connections using NAROS. We can simply put a large
lifetime in the NAROS response.

An advantage I see from the use of NAROS is that a host gets only the
part of the policy table it is interested in. If you use DHCP, you'll
have to transmit the full table. And maybe, only the half of this table
is useful for the host.

> say no, considering some comments made in this list.

Two parameters can be used to limit the number of NAROS requests while
keeping the number of entries in the hosts reasonable.
In the evaluation in
  http://www.info.ucl.ac.be/people/delaunoi/naros/
We show that if one policy is associated with each BGP prefix (i.e.
there are more than 100000 potential policy rules) and that
the lifetime used is 300s, then 90% of the hosts issue less than about
300 requests during the whole day. The resulting server load essentially
follows the traffic load and its average is 35 requests per second, for
a site with more than 7500 active hosts. The cache size remained below
100 entries during the whole day for 95% of the hosts.

Note that this evaluation is nearly a worst case : no filtering in
the site, lots of active p2p hosts, attacks from the web (port scans...)
factors that contribute to stress the NAROS system.

> sites, which i am not sure if they have such complex policies.

You forget that we are using "dynamic policies" to perform traffic
engineering. And even small sites could need load-balancing.
However, I also think that other solutions can be imagined to perform
basic load-balancing for tiny multihomed sites (e.g. using policy
routing and/or router advertisement messages to tell the hosts how they
should balance the traffic...)

> selection policy table. 

Ok. I'll be happy to discuss this point with you at the IETF meeting.

> I think that a mechanism for configuring the

Agree.

Regards,

Cédric