Comment/Question on draft-yegin-dmm-ondemand-mobility

Hi Alper,

I have one comment/question below.

The reason 5014 defines preference rather than requirements is, it was
expected that many application only have preferences rather than a
hard requirements, thus it makes sense to provide N IPV6_PREFER_SRC_*
values for the socket option to allow application to express
preferences for the N type of addresses. Doing it in this way wouldn't
lead to a communication failure if preference couldn't be fulfilled,
e.g., at time of connect() or send().

For those applications that have a hard requirement, they can first
express their preference, and once the kernel has selected an address
based on the preference at connect() or bind2addrsel()  invocation,
verify that their preference satisfy the requirement with the
is_srcaddr call. See http://tools.ietf.org/html/rfc5014#section-13 for
the details.

Given the application with hard requirement can be supported as above,
there was no need to define another N IPV6_REQUIRE_SRC_* values...

This seems to apply to your draft too, doesn't it?

If so you would only need to define one new value in addition to the
two existing ones that are relevant to your problem statement:

- existing IPV6_PREFER_SRC_HOME [RFC5014] for home anchored

- existing IPV6_PREFER_SRC_COA [RFC5014] for unanchored

- new IPV6_PREFERE_SRC_VISITED [I-D.yegin-dmm-ondemand-mobility] for
access anchored

what do you think?

Regards,

--julien

On Thu, Jul 18, 2013 at 7:17 AM, Alper Yegin <[email protected]> wrote:
> Hey Julien,
>
> How is it going?
>
> Did you have a chance to read our new I-Ds?
>
> http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt
>
> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt
>
> I'd appreciate if you can take a look at them and share your comments --
> online or offline, either way is fine.
>
>
> Thank you and see you in Berlin.
>
> Alper