Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
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? 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? Please make this rationale more explicit in the draft -- it's said in the 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? ;) 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
On 28.5.2015, at 18.38, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: (1) it is impossible to reliably snoop the protocol without contributing 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.) 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. 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? (2) it is impossible to publish data within DNCP without contributing a full set of Neighbor sub-TLVs; 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? 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). (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. 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. See 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 dislike repeating myself in a document. Any suggestions on wording on how to stay this nicely? ;) 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.) 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
On 28.5.2015, at 19.20, Dave Taht dave.t...@gmail.com wrote:
(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.
This is not true. Given basic bridging of ‘remember one guy on end of
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?
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.
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…
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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
On 28.5.2015, at 23.45, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: 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? 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.) Slightly different wording choice for me (‘adding to the state in the network’), but hopefully same semantics. 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? 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. Please make this rationale more explicit in the draft -- it's said in the 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? ;) Just repeat it and be done with it. There's nothing wrong with stating 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
Thank you for the recent reviews and update of draft-ietf-homenet-dncp. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
On 28.5.2015, at 16.11, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Thank you for the recent reviews and update of draft-ietf-homenet-dncp. 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; 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.) (2) it is impossible to publish data within DNCP without contributing a full set of Neighbor sub-TLVs; Full set is not required. _One_ bidirectional one per link is enough. (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. This is not true. Given basic bridging of ‘remember one guy on end of each link’, you can do essentially bridging. 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. 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.. 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. Well, I am not sure I am quite convinced with this argument (yet) :) Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
(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.
This is not true. Given basic bridging of ‘remember one guy on end of
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?
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.)
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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] WG Last Call for draft-ietf-homenet-dncp-03
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: 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 ray.bel...@nominet.org.uk 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] WG Last Call for draft-ietf-homenet-dncp-03
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 ray.bel...@nominet.org.uk 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
