In the process of implementing support for tunnels, an interesting
design choice of the CLI came up..
some background:
for static addresses, based on the psarc inception review, the proposal
was to have support for something like
# ipadm create-addr -i net0 10.1.2.3
or
# ipadm create-addr -i net0 myhostaddr
where "myhostaddr" would be resolved through /etc/hosts and then
becomes the 'label' for subsequent delete-address/set-addrprop commands.
But for iptunnels (and pointopoint links, in general), the address
is specified as a *pair*. In the case of ifconfig, this is done
by providing src and dst. So if we extended that concept, the question
of specifying a conveninent "label" for the address comes up (in the
case of ifconfig, the logical interface name generated by the system
becomes the label).
Some thoughts that Seb and I just discussed:
- Support the (lousy) syntax
# ipadm create-addr -i net0 myhostaddr otherhost_addr
and then subsequent commands become "myhostaddr otherhost_addr"
e.g.,
# ipadm get-addrprop -i net0 myhostaddr otherhost_addr
this is obviously unattractive.
- allow for an optional "label"/vanity-rename of the address, so that all
of the following are legal:
# ipadm create-addr -l tunadddr -i net0 mytunaddr othertunaddr
# ipadm create-addr -i net0 myhostaddr
# ipadm delete-addr -i net0 tunaddr
# ipadm delete-addr -i net0 myhostaddr
i.e., if no '-l' is specified, the label becomes the same as the interface
address(es). Alternatively, we could have:
# ipadm create-addr -i net0 -s <myaddr> -d <otheraddr> <label>
e.g.,
# ipadm create-addr --i net0 -s mytunaddr -d othertunaddr tunaddr
# ipadm create-addr -i net0 -s myhostaddr
but in both cases, if a "label" is not specified for the
tunnel we'd have to generate a vanity name for the address, which,
if we wanted to be consistent with the non-pointotpoint usage, would have
to be "mytunaddr othertunaddr".
thoughts?
--Sowmini
