Subject: [homenet] WG Last Call for draft-ietf-homenet-dncp-03

From: Mark Townsley <[email-masked]>
Date: Wed, 6 May 2015 17:21:03 +0200

Dear WG,

Thank you for the recent reviews and update of draft-ietf-homenet-dncp.
Please take the next 3 weeks to make your final reviews. WG Last Call will
officially end on May 28.

Thank you,

- Mark and Ray

On Thu, Mar 5, 2015 at 3:25 PM, Ray Bellis <[email-masked]>
wrote:

>
> Please provide further reviews for the recently updated
> draft-ietf-homenet-dncp and draft-ietf-homenet-hncp-04.  We believe these
> are very close to ready for WGLC.
>
>

---

From: Ray Bellis <[email-masked]>
Date: Tue, 19 May 2015 10:24:57 +0100

On 06/05/2015 16:21, Mark Townsley wrote:

> Please take the next 3 weeks to make your final reviews. WG Last Call
> will officially end on May 28.

This is just a quick reminder to the WG that this WGLC ends in 9 days.

Please send review / comments / whatever to the list ASAP.

thanks,

Ray and Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2015 13:19:38 +1200

Hi,

This is really just an FYI for the WG, not a direct comment on the draft.

The latest posted draft of the proposed Anima signalling protocol
is draft-carpenter-anima-gdn-protocol-03. It's by no means a WG draft
and big changes may be coming. However, the present draft attempts
to use a TLV format that is strictly compatible with DNCP, but needs
its own range of type codes.

Needless to say, I have read the DNCP draft, but don't have much new to
say about it.

Regards
   Brian Carpenter
On 07/05/2015 03:21, Mark Townsley wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 28 May 2015 15:11:07 +0200

> Please take the next 3 weeks to make your final reviews.

I strongly support this work.  We have recently set up an HNCP experiment
here in Paris (together with Thomas Denecker), and in the superficial
testing we did, it works beautifully.

As I've already mentioned on a number of occasions, however, I think that
in its current state DNCP represents a missed opportunity: it is
impossible to participate in DNCP without contributing a Node-State TLV
and a full set of Neighbor sub-TLVs.  This implies that:

 (1) it is impossible to reliably snoop the protocol without contributing
     a Node-State TLV and a full set of Neighbor sub-TLVs;

 (2) it is impossible to publish data within DNCP without contributing
     a full set of Neighbor sub-TLVs;

 (3) it is impossible to act as a dumb DNCP forwarder without publishing
     a Node-State TLV and a full set of Neighbor sub-TLVs.

Point (1) is relevant to network monitors that are not co-located with
a router, or more generally to hosts that wish to learn the network
topology without increasing the amount of replicated state.  Point (2) is
relevant to hosts that wish to leverage DNCP in order to publish some data
without increasing the amount of replicated state.  Point (3) is important
for routers that don't have any attached hosts, as when connecting two
wired networks over a number of wireless hop-to-hop links.

Fixing this is not complicated -- it just requires making it clear that
publishing Neighbor sub-TLVs is optional, and that, if a node is
publishing no sub-TLVs, then publishing a Node-State TLV is itself
optional.  This will require changing the algorithm in Section 5.4 (since
the neighbor graph is no longer necessarily connected).  I have no idea
whether it requires changes to the link assignment algorithm.

I think that not lifting the requirement for O(n+e) state in DNCP now
would be a serious missed opportunity, since it seriously reduces the
applicability of the protocol.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 28 May 2015 17:07:07 +0300

>     a Node-State TLV and a full set of Neighbor sub-TLVs;

This is not true, at least assuming the profile specifies even partially multicast-using profile. In pure unicast setup, you have to poll, I guess. (HNCP isn’t doing this, as it uses multicast also.)

>     a full set of Neighbor sub-TLVs;

Full set is not required. _One_ bidirectional one per link is enough.

>     a Node-State TLV and a full set of Neighbor sub-TLVs.

This is not true. Given basic bridging of ‘remember one guy on end of each link’, you can do essentially bridging.

> whether it requires changes to the link assignment algorithm.

That will result in state hanging around forever unless we introduce some TTL scheme alongside it. Considering the main design goal of DNCP is _not_ to have TTLs in the protocol, I am not sure what this would accomplish.

One could argue for some ‘dumb client protocol’ that lets some ‘real’ device do the publishing for them, but then dumb client’s connectivity is no longer of interest and the ‘real’ device can pretend to have the data valid as long as the TTL in the ‘dumb client protocol’ indicates.. 

> applicability of the protocol.

Well, I am not sure I am quite convinced with this argument (yet) :)

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 28 May 2015 17:38:25 +0200

> This is not true, at least assuming the profile specifies even partially
> multicast-using profile. In pure unicast setup, you have to poll,
> I guess. (HNCP isn’t doing this, as it uses multicast also.)

Ah -- you mean that an HNCP node will reply to a Node/Network state
request even if it's not in the link state database of the requestee?
That makes sense, much more than the assumption I had made that you ignore
any nodes that you don't have in your link-state database.

Please make this explicit in Section 5.2.

> Full set is not required. _One_ bidirectional one per link is enough.

How do you ensure that the graph remains connected?  Suppose you have this
topology:

 --- A --+-- B
         |
         C

where B and C try to minimise state.  What prevents B from picking C,
C from picking B, so that the (B,C) clique becomes disconnected from the
rest of the network?

> This is not true. Given basic bridging of ‘remember one guy on end of
> each link’, you can do essentially bridging.

Same issue as above.

>> This will require changing the algorithm in Section 5.4 (since the
>> neighbor graph is no longer necessarily connected).

> That will result in state hanging around forever unless we introduce
> some TTL scheme alongside it. Considering the main design goal of DNCP
> is _not_ to have TTLs in the protocol,

Ah.  Right.  I'm an idiot.

Please make this rationale more explicit in the draft -- it's said in the
introduction, please repeat it in Section 5.4.

I'll think about it some more, but I think you've convinced me -- I don't
see a good way to avoid the state explosion without giving up on the
link-state nature of DNCP.  (Which I understand is not likely to happen.)

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Thu, 28 May 2015 09:20:55 -0700

>> each link’, you can do essentially bridging.

so my use case (wanting routers without any ipv6 ips, just the fe80::,
to be able to forward requests onward) is merely a limitation of the
implementation?

> link-state nature of DNCP.  (Which I understand is not likely to happen.)

I had hoped for DNCP to be merely AHCP on a steroid, not the explosion
of complexity that resulted.

I have kind of been evolving something rather different.

What I do right now leverages the source specific information in the
routing protocol to assume that whatever is exporting a source
specific default /60 or /56 route has a whatever::1 address in the
first prefix of that,  then self assigns itself a SLAAC/128 address
out of the topmost /64, then uses curl over https to contact each for
a potential prefix and other configuration information.

Tis nothin but a bunch of itty bitty shell scripts like:

getdefgws() {
ip -6 route | grep '^default from' | grep / | while read d f addr via splat
do
        mask=`echo $addr | cut -f2 -d/`
        a=`echo $addr | cut -f1 -d/`
        echo $a/$mask
done
}

with stuff to measure the shortest and fastest paths (traceroute or ping)...

and a bit of lua. distinct advantages are not having to upgrade any
routers in the path with a new daemon,
implicit security of the https, the state primarily lives on the
source specific gw.

disadvatages are tis hard to write it all in a shell script, and I
imagine someone will object to someone treating somewhere::1 as a
"special" indicator of an IP being available for configuration
purposes, and no doubt more...

-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 28 May 2015 21:01:17 +0300

> Please make this explicit in Section 5.2.

Section 5.2 explicitly says how to reach to each TLV (and no semantics about this, IIRC).

Section 5.3 states what Node Endpoint TLV means (=I want to be your neighbor), section 5 (start) says that that TLV is used for forming bidirectional peer relationships..

How would you make it more explicit here?

> C from picking B, so that the (B,C) clique becomes disconnected from the

Section 6.2. (You don’t pick randomly who to pick, but e.g. prefer highest ID, and everyone follows same alg and _one_ node on shared link _has_ to peer with everyone).

>> each link’, you can do essentially bridging.

See above.

> introduction, please repeat it in Section 5.4.

I dislike repeating myself in a document. Any suggestions on wording on how to stay this nicely? ;)

> link-state nature of DNCP.  (Which I understand is not likely to happen.)

The main reason I am against TTL stuff is actually that it invalidates the use of Trickle; given even large static network, the TTL updates would cause Trickle never to be anything else than I_min => if you want to scale to (say) medium-sized static networks with low waste, this is the design I came up with. I _do_ welcome better designs though.

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 28 May 2015 21:08:13 +0300

> to be able to forward requests onward) is merely a limitation of the

Well, IPv6 IPs _are not forced_ by DNCP _or_ HNCP. Current implementation wants to do the assignments now by default, but I think if you set ip6assign=0 (or whatever the desired prefix length parameter was), you would get what you want now too.

The light-weight bridging of DNCP described here (or some other scheme) is something else. And for the record, I do not recommend it even if I _think_ I made it possible when thinking of the current DNCP design originally.

> purposes, and no doubt more…

Well, sounds like you’re inventing god server for a subset of what HNCP does :)

I find it amusing that you consider https in and of itself a source of security though. Do you actually validate your certs etc? Sounds relatively far from zeroconf.

(And I wonder how one does e.g. OCSP without actually having network configuration up.)

Couldn’t you just run DHCPv6 PD to the prefix::1 too? No need for magic, ready encoding for lots of things, and support for PSK if you want it ’secure’ (arguably less painful to set up than your own cert hierarchy).

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 28 May 2015 22:45:50 +0200

> Section 5.3 states what Node Endpoint TLV means (=I want to be your
> neighbor), section 5 (start) says that that TLV is used for forming
> bidirectional peer relationships..

> How would you make it more explicit here?

   A DNCP node MUST reply to a request from any valid address, as
   specified by a given DNCP profile, whether this address is known to be
   the address of a neighbour or not.  (This provision satisfies the needs
   of monitoring or other host software that needs to discover the DNCP
   topology without necessarily participating in the full DNCP protocol.)

Or perhaps

   ... without contributing to the replicated DNCP state.)

> Section 6.2. (You don’t pick randomly who to pick, but e.g. prefer
> highest ID, and everyone follows same alg and _one_ node on shared link
> _has_ to peer with everyone).

Ah, I see.

Should there be a forward reference in the first paragraph of 5.1?

> how to stay this nicely? ;)

Just repeat it and be done with it.  There's nothing wrong with stating
the rationale in both the introduction and the protocol description.

> The main reason I am against TTL stuff is actually that it invalidates
> the use of Trickle;

I think it's too late to be discussing this here.  Let's have beer in
Prague and yell at each other.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 29 May 2015 08:45:31 +0300

> On 28.5.2015, at 23.45, Juliusz Chroboczek <[email-masked]> wrote:
> 
> 
>   … without contributing to the replicated DNCP state.)

Slightly different wording choice for me (‘adding to the state in the network’), but hopefully same semantics.

> Should there be a forward reference in the first paragraph of 5.1?

Added there:

   If the
   DNCP profile supports dense broadcast link optimization
   (Section 6.2), and if a node does not have the highest node
   identifier on a link, the endpoint may be in a unicast mode which
   only listens to multicasts.  In that mode multicast updates MUST be
   omitted.

Added related comment also to 5.3:

   If the DNCP profile supports dense broadcast link optimization
   (Section 6.2), and if a node does not have the highest node
   identifier on a link, the endpoint may be in a unicast mode which
   only listens to multicasts.  In that mode, all peers except the one
   with the highest node identifier MUST NOT have Neighbor TLV
   (Section 7.3.2) published nor any local state.

> the rationale in both the introduction and the protocol description.

.. copied intro one almost verbatim.

Thanks for the comments!

This is what I added in the end (+ one minor edit in the end to fix ordering of DNCP profile requirements that I noticed when proofreading yet again through the text).

https://github.com/fingon/ietf-drafts/compare/108e558bf9671f99254af36e9f62c71c4007df78...b9096da5b648fd5d04d17a590335b64ac3b844e3

Cheers,

-Markus