Subject: Re: [core] 🔔 WGLC for Resource Directory

From: Peter van der Stok <[email-masked]>
Date: Wed, 22 May 2019 11:03:56 +0200

Hi Ted,

thanks for your comments, and apologies for the late reaction.
Some discussions were needed.

please see below;

Greetings, 

peter
Ted Lemon schreef op 2019-03-25 14:06:

> On Mar 21, 2019, at 5:32 PM, Jaime Jiménez <[email-masked]> wrote:
> 
>> Please take some time to carefully review the latest version and provide feedback by 2019-04-17 , specially those of you that contribute to other organisations that make use of some version of the document.
> 
> Carsten asked me to look at the CORE server discovery text.   It mostly looks good, although I don't understand why there are so many options.   If the intention is to have different profiles for different types of constrained networks, it would be good to say that explicitly.   It doesn't make much sense to pre-configure _devices_ to discover the resource directory using different mechanisms.   If that is really what is intended, then how this is going to be managed should be discussed.
> 
> <pvds>
> The intention is not to specify a set of normative profiles but to guide implementers and users of the resource directory, dependent on their installation. The text can be used to check the presence of at least one of the mentioned facilities before installing and using a resource directory in a given installation. We think this text is helpful because installations can be very different and many bundary conditions need to be satified in, for example, a building control installation.
> The text of section 4.1 is proposed to be:
> 
> A (re-)starting device may want to find one or more resource
> directories for discovery purposes.  Dependent on the operational
> conditions, one or more of the techniques below apply.  The use of
> DNS-SD [RFC6763] is described in [I-D.ietf-core-rd-dns-sd].
> 
> The device may be pre-configured to exercise specific mechanisms for
> finding the resource directory 
> </pvds>
> 
> The text about DNSSD is somewhat problematic: 
> 
> 3.  It may be configured to use a service discovery mechanism such as
> DNS-SD [RFC6763 [1]].  The present specification suggests configuring
> 
> the service with name rd._sub._coap._udp, preferably within the
> 
> domain of the querying nodes.
> 
> DNSSD works by first enumerating services, then choosing a service from among those services, then connecting to that service.  It looks like the idea here is that the default server name will be "rd", but that isn't stated explicitly.   Some discussion about how devices are suppose to choose between advertised RD servers is necessary here.   If the intention is that only one RD server ever be present or discoverable, then you could say that enumeration is not done at all, but then this isn't much different than just using DNS to resolve the hostname.
> 
> <pvds>
> We intend to broach this subject in the rd-dns-sd draft. Point 3 in section 4.1 of RD draft is therefore suppressed.
> Indeed the procedure for discovering a dns-sd service is the one you describe. 
> Extra text is needed in rd-dns-sd draft to cover the case that not only the services described in the RD are discoverable via DNS but also the RD itself.
> 
> Thanks for pointing this out
> </pvds> 
> 
> Based on the discussions that I've had in certain other standards bodies on how to use Core RD, I think that leaving this very loosely specified is probably not the right thing to do.   If in fact the intention is that other per-network-type specifications will decide how Core RD servers will be discovered on networks of the type discussed by those specifications, then this document should be written to explicitly support that use.   If this is the case, what is said here isn't general enough. 
> 
> I'm writing this with the goal of starting the discussion, rather than saying what needs to be said, because I haven't been privy to the discussion that led to the text as it is written in the current document.   It would help to understand what the authors/wg had in mind when this text was written. 
> 
> Thanks! 
> Thanks,
> 
> Peter
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

Links:
------
[1] https://tools.ietf.org/html/rfc6763

---

From: Badis Djamaa <[email-masked]>
Date: Wed, 22 May 2019 15:22:08 +0200

Dear Chairs, RD authors, members,

Thank you for raising this point concerning section 4 of CoRE-RD draft.
Indeed, besides the diversity of options, there are also performance
issues, especially with the CoAP resource discovery approach. To deal with
this, we have proposed a new announce-based mechanism to discover RD
server(s) [1]. Section 1.3 of [1] points out some potential shortcomings of
section 4 of CoRE-RD and motivates the need of an announce-based mechanism
that can be generalized to announce other links (please see the discussion in
[2]).

[1]: https://tools.ietf.org/html/draft-djamaa-core-proactive-rd-discovery-00
[2]: https://mailarchive.ietf.org/arch/msg/core/s8bjwXJeipCm2PNkE_mS16GGBFw

All the best,
Badis

On Wed, 22 May 2019 at 11:04, Peter van der Stok <[email-masked]>
wrote:

> Please take some time to carefully review the latest version and provide
> feedback by *2019-04-17* , specially those of you that contribute to
> other organisations that make use of some version of the document.
>
> Carsten asked me to look at the CORE server discovery text.   It mostly
> looks good, although I don't understand why there are so many options.   If
> the intention is to have different profiles for different types of
> constrained networks, it would be good to say that explicitly.   It doesn't
> make much sense to pre-configure *devices* to discover the resource
> directory using different mechanisms.   If that is really what is intended,
> then how this is going to be managed should be discussed.
>
> <pvds>
> The intention is not to specify a set of normative profiles but to guide
> implementers and users of the resource directory, dependent on their
> installation. The text can be used to check the presence of at least one of
> the mentioned facilities before installing and using a resource directory
> in a given installation. We think this text is helpful because
> installations can be very different and many bundary conditions need to be
> satified in, for example, a building control installation.
>        DNS-SD [RFC6763 <https://tools.ietf.org/html/rfc6763>].  The present specification suggests configuring
>
> DNSSD works by first enumerating services, then choosing a service from
> among those services, then connecting to that service.  It looks like the
> idea here is that the default server name will be "rd", but that isn't
> stated explicitly.   Some discussion about how devices are suppose to
> choose between advertised RD servers is necessary here.   If the intention
> is that only one RD server ever be present or discoverable, then you could
> say that enumeration is not done at all, but then this isn't much different
> than just using DNS to resolve the hostname.
>
> <pvds>
> We intend to broach this subject in the rd-dns-sd draft. Point 3 in
> section 4.1 of RD draft is therefore suppressed.
> Extra text is needed in rd-dns-sd draft to cover the case that not only
> the services described in the RD are discoverable via DNS but also the RD
> itself.
>
> Based on the discussions that I've had in certain other standards bodies
> on how to use Core RD, I think that leaving this very loosely specified is
> probably not the right thing to do.   If in fact the intention is that
> other per-network-type specifications will decide how Core RD servers will
> be discovered on networks of the type discussed by those specifications,
> then this document should be written to explicitly support that use.   If
> this is the case, what is said here isn't general enough.
>
> I'm writing this with the goal of starting the discussion, rather than
> saying what needs to be said, because I haven't been privy to the
> discussion that led to the text as it is written in the current document.
> It would help to understand what the authors/wg had in mind when this text
> was written.
>
> Thanks!
>
> Thanks,
>
> Peter

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 May 2019 09:51:55 -0400

On May 22, 2019, at 5:03 AM, Peter van der Stok <[email-masked]> wrote:

Thanks for getting back to me—I know that there are a lot of demands on our time, so there’s no need to apologize for being asynchronous! :)

>> The intention is not to specify a set of normative profiles but to guide implementers and users of the resource directory, dependent on their installation. The text can be used to check the presen…

The problem with this approach is that as an implementor, I have no idea what to do.   If you aren’t solving my problem, then you should explicitly say that you aren’t solving my problem, so that I’m not left wondering. :)

However, to be clear, I am not really suggesting that you say nothing.   I am suggesting that we figure out what the correct thing is to say, so that implementors are not left guessing.   There is a huge problem in the IoT space with solutions that use existing standards in incompatible ways, so that even though everybody can say “we’re standards compliant,” there is no interoperability. 

If this isn’t addressed in IETF specifications, it’s unlikely to be addressed anywhere, because the IETF is the only place I know of where general interoperability is an explicit goal.   The issue is that each individual IoT stack vendor is happy to simply have their own infrastructure solution that interoperates with devices that implement their stack.   But as a network owner, I may either choose to or be forced to install devices that use different IoT stacks on my network.   The network infrastructure standards, of which Core RD is clearly one, should support each stack I need to support, and not require that I implement separate infrastructure for each stack.

I think pointing to the core-rd-dns-sd document isn’t a bad thing, but I don’t think that document actually does what you think it does, so there may be some new expectation-setting exercise required.

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 23 May 2019 09:08:14 +0200

Hi Ted,

The central phrase being:
"The problem with this approach is that as an implementor, I have no
idea what to do", I like to elaborate a bit my view.

For me it is not an implementation problem but a box configuration
problem.
Let me cite two not completely fitting analogies: the plethora of YANG
modules, the plethora of communication standards.

Dependent of the type of router (home-net market or ISP market), the
router is configured with a set of YANG modules.
A smartphone, PC or tablet is equipped with a an appropriate set of
communication interfaces.
Interoprability is assured by the implementer for a given interface or
YANG module.

Going back to the RD. Interoperability is assured by the implementer for
a given discovery method.
SDOs (e.g. Faihair, Thread, OMA, and others )currently specify and
certify Internet stacks based on a selection of IETF standards. This
selection partially determines the set of appropriate discovery methods.
Actually, the SDO may select the RD being part of that stack and also
specify the required discovery method.

Does that make sense?

If so, should I mention in the text that a selection of supported
discovery methods for a given RD configuration may be specified by a
SDO?

Cheerio,

Peter
Ted Lemon schreef op 2019-05-22 15:51:

> Thanks for getting back to me--I know that there are a lot of demands on our time, so there's no need to apologize for being asynchronous! :) 
> 

The problem with this approach is that as an implementor, I have no idea
what to do.   If you aren't solving my problem, then you should
explicitly say that you aren't solving my problem, so that I'm not left
wondering. :) 

However, to be clear, I am not really suggesting that you say nothing.  
I am suggesting that we figure out what the correct thing is to say, so
that implementors are not left guessing.   There is a huge problem in
the IoT space with solutions that use existing standards in incompatible
ways, so that even though everybody can say "we're standards compliant,"
there is no interoperability.  

If this isn't addressed in IETF specifications, it's unlikely to be
addressed anywhere, because the IETF is the only place I know of where
general interoperability is an explicit goal.   The issue is that each
individual IoT stack vendor is happy to simply have their own
infrastructure solution that interoperates with devices that implement
their stack.   But as a network owner, I may either choose to or be
forced to install devices that use different IoT stacks on my network.  
The network infrastructure standards, of which Core RD is clearly one,
should support each stack I need to support, and not require that I
implement separate infrastructure for each stack. 

I think pointing to the core-rd-dns-sd document isn't a bad thing, but I
don't think that document actually does what you think it does, so there
may be some new expectation-setting exercise required.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 May 2019 09:27:14 -0400

On May 23, 2019, at 3:08 AM, Peter van der Stok <[email-masked]> wrote:
> If so, should I mention in the text that a selection of supported discovery methods for a given RD configuration may be specified by a SDO?

If that is what you intend to have happen, then yes, you should say that explicitly.   You might also explicitly discuss the problems with doing that:
Increased complexity of deployments
Lack of interoperability
Likelihood of infrastructure (as opposed to leaf) devices not actually supporting all the possible discovery methods

I suspect the reason we’re having this conversation is that we don’t yet know what to recommend, and that’s understandable.   But the reason I’m pushing the point is because at some point it would be of great benefit to the end-user to be able to say what to do.   Leaving it up to each app-layer vendor is not a good solution.   So if this document is not going to say what to do, we should at least be thinking in terms of discovering what we should recommend, and not simply decide that we are not going to solve that problem.

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 24 May 2019 11:24:36 +0200

Hi Ted,

thanks for the feedback. 

I was thinking of the following recommendations (based on my background
and experience) for the RD discovery.
Given the large range of deployment conditions, the use of conditional
recommendations seemed appropriate.

In managed networks which are (often) not connected to a border router,
the use of a preconfigured address is recommended. 
In managed networks with border routers that need stand-alone-operation,
the RDA0 option recommended.
The use of multicast discovery in mesh networks is NOT recommended. The
use of DNS facilities is described in draft-ietf-core-rd-dns-sd.

Comments on these recommendations will be appreciated.

Peter
Ted Lemon schreef op 2019-05-23 15:27:

> * Increased complexity of deployments
> * Lack of interoperability
> * Likelihood of infrastructure (as opposed to leaf) devices not actually supporting all the possible discovery methods
> 
> I suspect the reason we're having this conversation is that we don't yet know what to recommend, and that's understandable.   But the reason I'm pushing the point is because at some point it would be of great benefit to the end-user to be able to say what to do.   Leaving it up to each app-layer vendor is not a good solution.   So if this document is not going to say what to do, we should at least be thinking in terms of discovering what we should recommend, and not simply decide that we are not going to solve that problem.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 May 2019 09:11:38 -0400

On May 24, 2019, at 5:24 AM, Peter van der Stok <[email-masked]> wrote:
> In managed networks which are (often) not connected to a border router, the use of a preconfigured address is recommended. 

I can’t think of a time when this would be the right recommendation.   Just because there is no border router doesn’t mean that there isn’t a service discovery mechanism.   If you have something on the network providing core RD service, then you have a “server,” and that “server” should also be able to provice service discovery.   DNS-SD is actually a pretty easy way to do this—presumably you’re already configuring a DNS server in RA or DHCP, and if not it’s easy to do, and you don’t need to write any new specifications.   The server can be very lightweight.

If manual configuration is indicated, then what should be configured is the hostname of the RD server, not the IP address, which is simply too likely to change.   This avoids the risk that you would have to go out and manually reconfigure every device on the network when you change your network configuration. 

But really, the RDA0 works just fine in this case, and that’s what I’d recommend if I were writing the document, unless you are thinking that on a network of this type, hosts are just communicating using link-local addresses.   If they are using mesh-local addresses, then whatever mechanism configures mesh-local addressing should also be able to convey the RD IP address.

> In managed networks with border routers that need stand-alone-operation, the RDA0 option recommended.

Sure.

> The use of multicast discovery in mesh networks is NOT recommended. The use of DNS facilities is described in draft-ietf-core-rd-dns-sd.

Yup.

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 27 May 2019 09:31:34 +0200

Hi Ted,

The use cases for networks without border router are;
A mesh network configured on a gletcher in the Alps to measure the ice
movements.
A mesh network dropped from a plane over a forest.
A mesh network in a building under construction not connected to any
outside service.

For example, in those cases a border router is present once a month for
a few hours to read out data.

No RDA0 option,  avoid multicast, no host names. Therefore, the
configured RD IP address seems reasonable. 

Peter
Ted Lemon schreef op 2019-05-24 15:11:

> I can't think of a time when this would be the right recommendation.   Just because there is no border router doesn't mean that there isn't a service discovery mechanism.   If you have something on the network providing core RD service, then you have a "server," and that "server" should also be able to provice service discovery.   DNS-SD is actually a pretty easy way to do this--presumably you're already configuring a DNS server in RA or DHCP, and if not it's easy to do, and you don't need to write any new specifications.   The server can be very lightweight. 
> 
> But really, the RDA0 works just fine in this case, and that's what I'd recommend if I were writing the document, unless you are thinking that on a network of this type, hosts are just communicating using link-local addresses.   If they are using mesh-local addresses, then whatever mechanism configures mesh-local addressing should also be able to convey the RD IP address. 
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 May 2019 10:43:28 -0700

On May 27, 2019, at 12:31 AM, Peter van der Stok <[email-masked]> wrote:
> For example, in those cases a border router is present once a month for a few hours to read out data.
> No RDA0 option,  avoid multicast, no host names. Therefore, the configured RD IP address seems reasonable. 

Isn’t it the case generally that in order for the device to know that there is a BR present, the BR has to do some kind of multicast?

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 29 May 2019 09:49:28 +0200

HI Ted,

RFC 6775 explicitly discourages multicast over the mesh network.
Neighbour discovery is done with link-local broadcast, replaced with
unicast whenever possible.
In the mesk all 6LR know the addresses of their neighbouring 6LR.
The 6LBR only needs to know the addresses of the neigbouring 6LR,
obtained with with one broadcast and n unicasts.

Sending a multicast form each node to learn the address of the RD
generates many more messages in a multihop mesh.

Does this answer the question below?

Greetings,

Peter
Ted Lemon schreef op 2019-05-28 19:43:

> Isn't it the case generally that in order for the device to know that there is a BR present, the BR has to do some kind of multicast?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 08:05:42 -0700

On May 29, 2019, at 12:49 AM, Peter van der Stok <[email-masked]> wrote:
> The 6LBR only needs to know the addresses of the neigbouring 6LR, obtained with with one broadcast and n unicasts.

A broadcast is a multicast that goes to every station.   This is what I mean.   If the sometimes-on router finds nodes this way, then it can send them the information they need to talk to the Core RD.   If instead the nodes are all configured with an address for the Core RD, this limits flexibility to no good purpose.  In this situation, if there is no space in the initial announcement for a Core RD server IP address, then defaulting to sending the Core RD messages to the router seems like it would be the right behavior.   Sending it to some other pre-configured address sounds like a maintenance nightmare.

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 29 May 2019 17:23:17 +0200

>> Nodes want to use the RD before the 6LBR is connected.
>> Another suggestion is then:
>> 
>> In managed networks before connection to the border router, the temporary use of a preconfigured address is recommended.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 May 2019 10:04:28 -0700

>>> Nodes want to use the RD before the 6LBR is connected.

Hm, okay.   That’s the piece I was missing.   So there is some infrastructure, just no external connection?   Or there is no infrastructure, just nodes that find each other?   I think these are two separate use cases.   The use case I thought you were talking about is where there are nodes that don’t see each other, but do see the border router as it flies over/drives by/whatever.   I suppose another use case is where the leaf node is mobile, and the network infrastructure that it sees changes over time: sometimes nothing, sometimes ranger station 1, sometimes ranger station 2, etc.

IOW it would be good to enumerate these use cases in more detail, and then ask the question, how can I best configure this network, for each such use case.

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 30 May 2019 09:29:37 +0200

Hi Ted,

thanks for the dissection of use cases. The ones I understand:

1a) no infrastructure with nodes that see each other.
1b) followed by nodes that see each other connected to an infrastructure
with border router (possibly intermittently)
2) nodes that see each other connected to an infrastructure with border
router (possibly intermittently)

Where 1b and 2 are actually identical; and 1b does not necessarily
follow 1a.

The intermittent connection to the border router is not important
because from the first connection to the 6LBR, the 6LR remember the
border router options.

When different border routers fly over, it wil be difficult to to
instruct them all what the RD address is. (not clear what to recommend
here, I prefer to leave that out)

When nodes do not see each other, the presence of an RD is irrelevant.

The case that a node migrates from one infrastructure to the next is
beyond my competence. That was a use case for home networks with DNS
support?

I will add some phrases to the building control section to make the
connection to (absence of) the infrastructure clearer.

Any other suggestions?

Peter

> Nodes want to use the RD before the 6LBR is connected.

Hm, okay.   That's the piece I was missing.   So there is some
infrastructure, just no external connection?   Or there is no
infrastructure, just nodes that find each other?   I _think_ these are
two separate use cases.   The use case I thought you were talking about
is where there are nodes that don't see each other, but do see the
border router as it flies over/drives by/whatever.   I suppose another
use case is where the leaf node is mobile, and the network
infrastructure that it sees changes over time: sometimes nothing,
sometimes ranger station 1, sometimes ranger station 2, etc. 

IOW it would be good to enumerate these use cases in more detail, and
then ask the question, how can I best configure this network, for each
such use case.