Re: About NAROS

[Cedric de Launois <delaunois@info.ucl.ac.be>]

Le lun 23/06/2003 à 20:38, marcelo bagnulo a écrit : 
> 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.
This is precisely what we were thinking of when we wrote in the draft 
"[NAROS] complements [...] the default IPv6 source address selection
algorithm". 

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

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.

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

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

Indeed. We are fully aware of that.

> This implies that an additional mechanism for failure
> detection is needed, probably and e2e mechanism.

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