\subsection{006: SAs entries should be capable of overlapping}

\subsubsection{006: Definition of requirement }

Currently klips1 apparently identifies a tunnel by what {\bf remote} subnet it 
serves.  That means that if a new tunnel is brought up serving the same 
subnet, it supersedes the previous one.

A more complex semantic is required, and a way to express it:

\begin{itemize}
\item sometimes you do want the new tunnel to supersede the old one.
\item sometimes you want the new tunnel to operate in parallel, using 
	equal-cost multipath, for load sharing.
\item sometimes you want the new tunnel to just sit there in standby mode, 
	to be used later
\begin{itemize}
\item for fail-over
\item for mobililty
\end{itemize}
\end{itemize}

\subsubsection{006: response}

This is a misfeature, and is hereby deprecated.

Rollover of SAs is necessary for functional long-term opportunism.

%Possibly constructive suggestion (to be filed under some OTHER 
%heading):  We could have family lineages:  Within each family lineage, 
%parents would be replaced by children as the former expire.  They would 
%keep the "family name".  The name could be derived perhaps from the name of 
%the CONN declartion in the .conf file.
%
%To implement load-sharing, mobility, and failover, we could have multiple 
%families serving the same remote subnet.




