On Thu, 04 Jan 2007 19:35:10 +0800
Kacheong Poon <kacheong.poon at sun.com> wrote:
> Renee Danson wrote:
>
> > Yes, I think both of these are possibilities. Actually, the latter (an
> > Env selection condition on a non-exisiting link/interface) is not specific
> > to the ENA scenario; links and interfaces may come and go,
>
>
> There is one question which does not directly related to
> ENA or other virtual link/interface manipulation program.
> For example, a user plugged in a wireless card. Using
> the current NCP and ENA proposal, this is noted and be
> displayed in the GUI. But nothing extra will be done as
> it is not in the NCP. So a user needs to explicitly add
> it to the NCP before any "magic" will happen.
As an aside because of the fact that links can come and go and because
of the need to build config for other systems the user needs to be able
to specify what to do with links that don't exist at configuration time
on the system. We've discussed this before when talking about the GUI
but I don't know if its written down anywhere.
[...]
> > I think trying to do nothing about them could lead to indeterminate state.
> > Doing nothing (not tearing down things we didn't set up) works fine if all
> > the ENA does is create a new link or interface. But what if it modifies an
> > existing link?
>
>
> The action of restoring a setup will remove this modification.
> I think this action is easy to understand to a user.
>
Really?! Wholesale removal of body parts seems move obvious to me then
exchanging the diamonds for cubic zirconia (of course the later might
cause the former...).
[...]
> > Well, sort of. As I said above, it's because we need to be able to put
> > the system in a predictable state. We can't be sure that we'll be able
> > to restart/refresh ourselves without interfering with whatever the ENA
> > has done.
>
>
> I suggest we have two different actions. One is to restore
> the system setup to be exactly like the one specified by a
> NCP. The other is to just restore the NCP without removing
> link/interface the NCP does not know about. And I guess if
> NWAM is restarted, the action is to just restore the NCP
> without removing link/interface it does not know about. And
> we figure out how to handle this gracefully.
[...]
I think this is all well and good when the links and interfaces
specified by the NCP don't overlap those manipulated by the ENA
(although I think it might be common for the user to want to make sure
those interfaces are in the NCP so they build an environment dependent
on them).
In the case where we get ripped out of the ground and restart say we lay
out the NCP ignoring "other" links and interfaces. After that we match
an environment. If we've managed to make the tunnel unusable but the
link is still there we are likely to match an environment which
contains name servers, etc. which are unreachable. OTOH if the tunnel
is still usable but we don't match on it we are likely to create an
equally unusable configuration (bump in the stack which we don't remove?).
mph
