Thanks Dan, for your comments.
So here's what I saw upon a quick browse through the document:
- Where does this fit in with the Clearview IP Tunneling work?
We will be able to create IP interfaces on the IP tunnel links created
via "Clearview IP Tunneling work"
- There are other consumers of this API. IKEv2 (or IKEv1 IKE-CFG
support) would use these as well to create tunnel interfaces. The
good news is that I don't see anything so far that would be a
hinderance, and in fact, stability here would help a LOT.
(We can test these APIs with punchind, BTW.)
Great. The plan is to get few consumers start using the library
libipadm.so.1 (as identified in the design doc). Once we have sufficient
features (in subsequent phases of ipadm) we will have more consumers
using this library.
- I see that there is absolutely no *_algs support ala. ifconfig(1M).
I do not mind EOL-ing these, but I do need to see an agenda for
how. This may be more dladm-level than ipadm, but it is something
we need to take into account.
The eventual goal is to achieve the new mantra => 'ipadm' will be the
new 'ifconfig'.
For now (first phase) 'ifconfig' will not be made obsolete. The *_alg
support will be present in ifconfig(1M) as it is today. We will not
carry forward the *_algs support in 'ipadm' as 'ipsecconf' is the right
place for people to configure it.
- I assume the "-t" equivalent will be in the library as well, right?
Yes
- I have mixed feelings about EOL-ing XRESOLV. Nobody uses it, but
for IP-over-<new-technology> XRESOLV can provide a better way for
<new-technology> to implement ARP or ARP-like functionality.
(XRESOLV + PF_ROUTE was the inspiration for PF_KEY.)
OK.
thanks
~Girish
_______________________________________________
networking-discuss mailing list
[email protected]
