Paul Jakma wrote:
> Right, that has to be expressed in some terms, interface index or address.
>
> I mentioned "SID" and "nexthop" just to show it could be extended in
> future if/when NWAM extends the policies it allows users to set.
If by SID, you meant to say how the address of an IP interface
is configured, I think it is not needed. In fact, I suspect
it is wrong to ask the routing service to understand how an IP
interface is configured. If there is a need to express that in
user preference, NWAM will translate that to a preference of
IP interfaces. Having said that, it is wise to make the
communication between NWAM and routing service extensible. But
it does not mean that we need to define something, such as SID,
in the communication right now. It may never be used and is
probably a distraction.
> The above list was intended to allow policy to be expressed as "close"
> to what NWAMs representation of the policy might be as possible.
Could you explain what you meant by "NWAM representation of
the policy?"
> E.g:
>
> Preference type data
> --------------- ----
>
> link interface index
> or address
>
> Service Service ID of some kind
> (e.g. the "prefer
> DHCP domain X to Y"
> case. A hypothethical
> at this stage for NWAM)
I guess I still have not made my point clear on what "service"
means in this context of discussion. No, using DHCP to configure
an IP interface does not make DHCP a service in the context of
this discussion. And I don't expect that the routing service needs
to know how an IP interface is configured. If the user preference
specifies that, NWAM will translate it to a preference of IP
interfaces.
> Gateway IP address
> (e.g. for VPNs, if we
> learned one default
> via the 'real' network
> (e.g. DHCP) and another
> via the VPN (e.g. PPP,
> PPtP, or a static route)
> which gateway should be
> preferred? That information
> likely will be in an
> NWAM profile..)
If NWAM needs to communicate this to the routing service, I think
it just means that NWAM needs to intercept all routing info gathered
from various sources. Otherwise, how can NWAM know the gateway to
use to send policy to the routing service?
...
> So for NWAM, that "arbitrary pre-defined weighting" needs be made more
> dynamic, right?
Correct. But what I was referring by the routing service is
more than just the RIB. Just take a very simple example. Suppose
there are only static routes. By what mechanism do we communicate
this to the routing service assuming that NWAM will only communicate
policy to it? There may be a simple user preference that one link
is preferred, this is the policy NWAM will tell the routing service.
Should NWAM also use the routing socket to set all the static routes?
Maybe. But isn't this different from the DHCP case which the dhcpagent
directly tells the routing service the routing info, bypassing NWAM?
We need to complete the whole picture.
>> The above is restricting what a user can do with link preference. What
>> is the reason we need to have such restriction? A user can have two
>> preferences in priority,
>
>> 1. prefer connection to network A to connection to network B
>> 2. prefer wire link to wireless link
>
>> NWAM needs to check the network conditions dynamically to tell
>> the routing service which interface is preferred. A simple case
>> is that the machine is first connected to network A via the
>> wireless link and then a cable is plugged in to network B.
>
> The network conditions may be dynamic, but the policy still easily can
> be very static.
>
> The above policy for example seems easy to describe.
Can you outline what NWAM should tell the routing service in the
above simple case? Remember that the routing service does not know
anything about the underlying link used by an IP interface.
>> It may be that we only allow static preference in the first release.
>> But I don't see a particular reason why we need to have such
>> restriction in the architecture.
>
> Ok, I'm confused. What restriction?
Quoted from your previous mail.
---
I.e. that dependency/serialisation, of having pro-actively approve all
changes, often will not be required. The routing info can just flow
straight from the "route providing service" to the "routing service",
which can act on /previously/ acquired preference information from NWAM.
---
It can be wrong if the routing service can only act on "previously
acquired preference info" as the preference is just wrong when
the condition changes.
> Just because I claim that a user's policies will mostly be static,
> day-to-day at least, does not mean I claim the policy mechanism must be
> incapable of handling policy changes. ;)
A static user preference does not always translate to a static
link preference. I am starting to suspect that what you have in mind,
which is not what we have been talking so far, is to have the routing
service take over the user preference specification. This is why
you keep on including things like SID, addresses, ...
What we, the NWAM team, has in mind is to shield the link/IP interface
configuration from the routing service as it does not really need
the info. This makes things cleaner to deal with in the routing
service. But if you think that the routing service has to know about
all this stuff in order to make things work, we probably need to
re-consider the proposal.
--
K. Poon.
kacheong.poon at sun.com
