Re: [mif] next step for MIF PVD configuration

[Stjepan Groš <[e-mail]>]

Hi Margaret,

Thank you for the clarification/answer. I read the documents you were
referring to and here are my comments.

On 02.03.2016 13:48, Margaret Cullen wrote:
> Hi Stepjan,
>
> On Feb 29, 2016, at 8:26 AM, Stjepan Groš <[e-mail]> wrote:
>
>> Hi all!
>>
>> On 29.02.2016 11:21, Hui Deng wrote:
>>> Hello all
>>>
>>> We had the concensus already about droping DHCP MPVD ID document, 
>>> based on this, here chairs would like to understand whether MIF WG
>>> has achieved the concensus on below two steps to deliver MPVD conf.
>>> 1) step 1: using RA to get MPVD ID information
>>> 2) step 2: using DNS to get other MPVD configuration.
> There has been previous mention on the list regarding this two-step approach, although it did not use that terminology -- in the minutes from Yokohama, it has been previous referred to as an "offline mechanism".  It was discussed in the minutes from Yokohama which were posted to the list.  During the meeting, we reached consensus of those int he room that we should use RAs to identify an explicit PVD, and that we should use an offline mechanism to get further PVD information.
>
> The MIF WG minutes from the last meeting can be round here:
> https://www.ietf.org/proceedings/94/minutes/minutes-94-mif) 
>
> There is currently one proposal for an offline mechanism, the MPVD DNS proposal (draft-stenberg-mif-mpvd-dns).  It was also presented in Yokohama.  There seemed to be general agreement in the room that a DNS approach would be workable, but there were concerns raised about the specific proposal in this document (use of TXT records, etc.).

In the given draft two use cases are mixed into one. The first one is
for the discovery of services available. It is a valid use case for a
DNS (side question, can DNS-SD already do what this draft describes,
could SDP be (re)used?). The other one is the configuration data that
the client should use to configure itself, this is IMHO not a valid use
case for DNS service. The additional reason why not is that, for
example, RA allows asynchronous notification about changes in the
network parameters, while DNS doesn't. This mixes TTL into the equation.
TTL values in RA are relatively large, larger that in DNS. I suspect
that there could be some tricky issues too.

As a side note, when we talk about QoS characteristics of discovered
services, the draft offers one possible approach. But it is an
interesting question would this be enough. IMHO, for some it would, for
others it won't. For example, draft anticipates user visible PvD name
but this doesn't mean a lot. Maybe some service provider wants to
provide more elaborate description or something else. Also, there is a
problem of a composition of different access methods. If both say they
are fast, it might easily be that they aren't identical but due to the
shortcomings of the description "language" they can not be
differentiated. And if you include security into the mix, things start
to complicate quickly. Anyway, one possible solution would be to provide
URL that might be used to fetch description of a service/PvD which can
be in different forms (depending on one's particular needs) and thus
more likely to satisfy (almost) everyone. Also, this URL based access
might be a better in case you want to do a per-user configuration
because in the higher layers you have user's identity on your disposal
which might not be available to DNS server and/or resolver code.

And while we are at access control, DNS servers usually serve all data
from their databases to any client that asks them. If you introduce
local network specific information into DNS, how would you restrict
access to this data? Of course, it can be solved, almost everything can,
but needles to say, it complicates things.

Finally, obviously this solution assumes a single DNS server from one
ISP will provide all the data about PvDs. If you have two or more ISPs
and expect them to be collaborative is nice thing to hope for, but in
case they don't user is stuck. And even if they collaborate, that
neither scales nor is responsive.

>
> At this point we are trying to see if we can recharter the group to work on a two step proposal for PVD configuration using RAs and using DNS as the offline mechanism for further PVD configuration.  That is the "two-step approach" that is being referred to here.
>
>> Since I didn't saw any discussions on this list about those proposals I have few questions/comments:
>>
>> 1. Is this only for IPv6, or it is for IPv4 too (step 2)?
> A DNS lookup could be used for IPv4 or IPv6.  Right now, though, there has only really been discussion of how a host could get it's explicit PVD ID (which would most likely be needed for the lookup) from an IPv6 RA.  It is possible that we could define a way for an IPv4 host to get it's PVD ID, but the IPR on using DHCP for this makes that somewhat challenging.

IMHO, having only PVD ID in DHCP is _much_ closer to what IPR claim is
about than to have all the configuration data.

But, isn't this something that DHC WG should discuss and decide?

Actually, DHC WG should also solve a problem of two or more _concurrent_
DHCP servers on a local network. And by solving that use case, it might
also get around IPR claim (if its an issue at all).

>
>> 2. Why only MPVD ID in RA? Why not other information too for which RA is a natural place to be?
> There has been a great deal of concern expressed about adding all sorts of different configuration information into RAs.  In fact, currently RAs don't even contain enough information to do a secure DNS lookup, as they are missing an NTP configuration option.

Maybe I'm missing something, but IMHO not much is necessary in terms of
options when we talk about PvDs: one option, PvD CO (which can be PvD ID
in the same time) and that's it. Of course, distinction has to be kept
between node configuration (for which RA is used) and service discovery
(for which RA isn't appropriate and which might explode number of
necessary options).

Note that there is also possibility to use RS to explicitly ask for PvDs
(specific one or all available), i.e. they aren't sent in "regular" RAs.
I don't know if this was explored, but in NDP draft it isn't mentioned.

As for the missing information to make DNSSEC to work, I suppose that's
something that's not the problem this WG should solve.

> There was consensus in the room that it would be better to get the PVD ID from an RA and use a second step to look up the full PVD configuration information.  the only current proposal for that second step is to do it via DNS.

There is already a second step for RA, it is DHCP and it is already
implemented and works for years now.

Not to mention that into already complex mix of configuration mechanisms
(from operational perspective) additional one is introduced which has a
host of its own problems (security issues, and slow adoption of DNSSEC).

And while I'm talking about OP perspective, there are host of other
configuration protocols already (RADIUS, DIAMETER, PPP, VPN specific
ones). Is it really necessary to introduce yet another one into the mix?

>
>> 3. Why turn DNS into a local network configuration protocol?
> Well, there is an extent to which DNS is already used for these things via SRV records, TXT records, etc.  However, I do see your point to some extent…  What would you use propose that we use instead?

SRV as I said, is for service discovery, not node configuration. So its
not good analogy. The same goes for DNS-SD, which is also for service
discovery as the name implies.

DHCP was designed to do a local network configuration and I think that
DHC WG should be asked to solve the IPR problem. There are already some
options that might invalidate, or at least work around IPR claim, like
DHCPv4-over-DHCPv6 which encapsulates all configuration parameters
within a single option, different domain names (NIS, KRB), etc.


In the end, let mi conclude that I somehow suspect that my opinion will
change anything, but I'm nevertheless strongly opposed to the direction
WG is taking.

SG

P.S. I tried to ask on NetworkManager list for their opinion about all
this, but unfortunately received no answer.  That would be very valuable
input.

>
> Margaret
>
>