Subject: [homenet] Comments on draft-ietf-homenet-hncp-02

From: "Jonathan Hansford" <[email-masked]>
Date: Wed, 3 Dec 2014 16:07:09 -0000

Hi,

I've just come to the homenet WG and have some questions and comments for
draft-ietf-homenet-hncp-02:

1.       I notice from the homenet charter the work is based on IPv6. Is
there anything in the HNCP protocol that precludes its use for IPv4? I am
looking for a similar capability for use within multiple IPv4 broadcast
domains with no IPv6 in the mix at all.

2.       What is a node? I presume it is a router.

3.       Section 1, 3rd paragraph: s/information how/information on how

4.       Section 3, set of TLV data: s/The set of TLVs have/The set of TLVs
has

5.       Section 4.2

a.       1st paragraph: s/as purely as/purely as

b.      "TLVs MUST or MAY be present" - is that a decision that can be made
per node, per link or across the implementation?

6.       Section 4.2.4, Network State TLV: s/every known node/every node
known

7.       Section 4.3, 2nd paragraph, last sentence: s/is not IPv6/is not an
IPv6

8.       Sections 4.4 to 5: The style feels more terse here. The text is
still readable, but there is a noticeable reduction in definite and
indefinite articles (e.g. s/Whenever multicast message/Whenever a multicast
message). 

9.       Section 4.4, 2nd sentence: Feels a little clumsy. How about "If
nothing (for example - no router advertisements, no HNCP traffic) is
received from that neighbor in Imax seconds, the neighbor is not in the
neighbor discovery cache, and no layer 2 indication of presence is
available, at least 3 attempts SHOULD be made to ping it using a request
network state message (Section 4.2.2), sent with increasing timeouts (e.g.
1, 2, 4 seconds)."?

10.   Section 4.5: Is the reference to "h(neighbor node identifier)" the
equivalent of H(x) in section 5?

11.   Section 5: 

a.       s/MUST be always/MUST always be

b.      "Encoding of type=123 ." and "Notation: ." feel as though they apply
to the preceding diagram rather than the encoding being an example and the
notation applying to the diagrams that follow.

12.   Section 6, as-hoc category: Excuse my ignorance, but what is meant by
non-transitive?

13.   Page 16, assigned prefix: s/using one TLVs/using one TLV

14.   Section 7: s/Following TLVs/The following TLVs

15.   Section 9, 1st paragraph: s/have rarely security/rarely have security

16.   Section 10: s/with following/with the following

Jonathan

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 5 Dec 2014 15:43:43 +0200

> On 3.12.2014, at 18.07, Jonathan Hansford <[email-masked]> wrote:
> I’ve just come to the homenet WG and have some questions and comments for draft-ietf-homenet-hncp-02:

Heya, and thanks for the review ;)
 
> 1.       I notice from the homenet charter the work is based on IPv6. Is there anything in the HNCP protocol that precludes its use for IPv4? I am looking for a similar capability for use within multiple IPv4 broadcast domains with no IPv6 in the mix at all.

Do you need PA, SD, or just share some arbitrary TLVs? If last, you could use some existing routing link-state protocol, or possibly <unnamed thing we are generalizing out of HNCP>.

> 2.       What is a node? I presume it is a router.

Router/node is awfully mixed in hncp-02.. Router is a node, but not all nodes are routers.. 

Thanks also for corrections - I will incorporate them in the next version if they are still applicable (it seems the next iteration will be drastic, given what we have now in github (public development and all) but more on that later perhaps).

(Terms ‘link’, ‘router’, ’node’ were horribly abused in the hncp-02. Sorry.)

> 4.       Section 3, set of TLV data: s/The set of TLVs have/The set of TLVs has
> 
> 5.       Section 4.2
> 
> b.      “TLVs MUST or MAY be present” – is that a decision that can be made per node, per link or across the implementation?

Good point, have to specify that (if this thing even exists). MUST be ones obviously are always required, and MAY ones are local choice. (I think we got rid of the MAY ones in the next iteration though, but I have to double check to make sure.)

Cheers,

-Markus

---

From: "Jonathan Hansford" <[email-masked]>
Date: Fri, 5 Dec 2014 14:17:22 -0000

> -----Original Message-----
> From: Markus Stenberg [mailto:[email-masked]]
> Sent: 05 December 2014 13:44
> To: Jonathan Hansford
> Cc: Markus Stenberg; [email-masked]
> Subject: Re: [homenet] Comments on draft-ietf-homenet-hncp-02
> 
> > 1.       I notice from the homenet charter the work is based on IPv6. Is there
> anything in the HNCP protocol that precludes its use for IPv4? I am looking for
> a similar capability for use within multiple IPv4 broadcast domains with no
> IPv6 in the mix at all.
> 
> Do you need PA, SD, or just share some arbitrary TLVs? If last, you could use
> some existing routing link-state protocol, or possibly <unnamed thing we are
> generalizing out of HNCP>.

I'm currently exploring using Zeroconf capabilities to establish a single broadcast domain from scratch within an "IP island" (i.e. initially isolated from any larger internet). However, I know there will be occasions when there will be multiple broadcast domains within the island and will therefore need to be able to move from link-local to private addresses so they can be routed between the domains. Also need to perform service discovery. The one anomaly is that I need to do this prior to receiving any information from "the outside world" (e.g. allocated prefixes), hence the use of private addresses. The network needs to "discover" itself whilst it is  an island, providing full service capability within that island prior to being connected to the internet.

> Thanks also for corrections - I will incorporate them in the next version if they
> are still applicable (it seems the next iteration will be drastic, given what we
> have now in github (public development and all) but more on that later
> perhaps).
> 
> > b.      “TLVs MUST or MAY be present” – is that a decision that can be made
> Good point, have to specify that (if this thing even exists). MUST be ones
> obviously are always required, and MAY ones are local choice. (I think we got
> rid of the MAY ones in the next iteration though, but I have to double check
> to make sure.)
> 
> Cheers,
> 
> -Markus