[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About NAROS
On Tue, 2003-06-24 at 16:25, Cedric de Launois wrote:
> 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".
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.
>
> > 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.
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
> 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.
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)
> 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
>
>
>