Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On 06/03/2015 08:36, Christian Hopps wrote: > >> On Mar 5, 2015, at 2:27 PM, Brian E Carpenter >> wrote: >> >> Hi, >> >>> 8. Support for Stub Networks and Stub Routers >> ... >>> IS-IS supports stub-networks as defined above >>> simply by advertising the prefix associated with a link, but not the >>> link itself. This is sometimes referred to as a "passive link". >>> >>> Further an IS-IS router has the ability to set a bit (the overload >>> bit) to indicate that it should not be used for any transit traffic, >>> and that it will only be considered a destination for the prefixes it >>> has advertised, i.e., it is a stub router as defined above. >> ... >>> As all distance vector protocols, Babel supports fairly arbitrary >>> route filtering. Designating a stub network is done with two >>> statements in the current implementation's filtering language. >> >> In a homenet, there must be no manual config. In both cases, how does >> this work automatically? How does IS-IS know not to advertise the link >> and set the overload bit, and how does Babel know to include those >> filtering rules? Or more generally, how does a stub router know that >> it's a stub router, when there is no human to tell it so? > > For IS-IS, the stub router would know so b/c it can’t be anything else. It is > running the stub version of the software. The reason it would be doing this > is b/c it’s a very small device not designed to do anything else. > > BTW, is it true that there must be no manual config, or simply that one > cannot rely on manual config? IMHO the second case applies - manual config may be possible, but the network must run correctly without it. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On 06/03/2015 09:19, Acee Lindem (acee) wrote: > > > On 3/5/15, 2:46 PM, "Juliusz Chroboczek" > wrote: > >>> Or more generally, how does a stub router know that it's a stub router, >>> when there is no human to tell it so? >> >> Yeah, it's not very clear. We were actually asked to describe the two >> protocols' support for stub networks, and nobody never told us which of >> the many definitions of stub network they meant, let alone describing the >> use case precisely. (The document uses the same definition as Cisco's >> EIGRP documentation, in case you're interested.) >> >> I'm imagining a dedicated device that has both a WiFi interface and >> a low-power interface that acts as a gateway between the Homenet network >> and the sensor network. Such a device would come from the factory with >> the low power interface configured as a stub. > > It is my understanding that this is the use case for auto-configured stub > routers as well. They are constrained devices that are only capable acting > as a stub router. Yes, the idea that this an intrinsic property of certain devices makes sense to me. If I buy a home climate control system that includes a router to connect it to the rest of the homenet, it can "know" that it's a stub router out of the box. What doesn't work for me is any suggestion that somebody needs to configure this, because in 99% of homes that isn't going to happen. The text in the draft could be a bit clearer on this point. Thanks Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
On 3/5/15, 2:46 PM, "Juliusz Chroboczek" wrote: >> Or more generally, how does a stub router know that it's a stub router, >> when there is no human to tell it so? > >Yeah, it's not very clear. We were actually asked to describe the two >protocols' support for stub networks, and nobody never told us which of >the many definitions of stub network they meant, let alone describing the >use case precisely. (The document uses the same definition as Cisco's >EIGRP documentation, in case you're interested.) > >I'm imagining a dedicated device that has both a WiFi interface and >a low-power interface that acts as a gateway between the Homenet network >and the sensor network. Such a device would come from the factory with >the low power interface configured as a stub. It is my understanding that this is the use case for auto-configured stub routers as well. They are constrained devices that are only capable acting as a stub router. Thanks, Acee > >-- Juliusz > > >___ >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
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
> Or more generally, how does a stub router know that it's a stub router, > when there is no human to tell it so? Yeah, it's not very clear. We were actually asked to describe the two protocols' support for stub networks, and nobody never told us which of the many definitions of stub network they meant, let alone describing the use case precisely. (The document uses the same definition as Cisco's EIGRP documentation, in case you're interested.) I'm imagining a dedicated device that has both a WiFi interface and a low-power interface that acts as a gateway between the Homenet network and the sensor network. Such a device would come from the factory with the low power interface configured as a stub. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
> On Mar 5, 2015, at 2:27 PM, Brian E Carpenter > wrote: > > Hi, > >> 8. Support for Stub Networks and Stub Routers > ... >> IS-IS supports stub-networks as defined above >> simply by advertising the prefix associated with a link, but not the >> link itself. This is sometimes referred to as a "passive link". >> >> Further an IS-IS router has the ability to set a bit (the overload >> bit) to indicate that it should not be used for any transit traffic, >> and that it will only be considered a destination for the prefixes it >> has advertised, i.e., it is a stub router as defined above. > ... >> As all distance vector protocols, Babel supports fairly arbitrary >> route filtering. Designating a stub network is done with two >> statements in the current implementation's filtering language. > > In a homenet, there must be no manual config. In both cases, how does > this work automatically? How does IS-IS know not to advertise the link > and set the overload bit, and how does Babel know to include those > filtering rules? Or more generally, how does a stub router know that > it's a stub router, when there is no human to tell it so? For IS-IS, the stub router would know so b/c it can’t be anything else. It is running the stub version of the software. The reason it would be doing this is b/c it’s a very small device not designed to do anything else. BTW, is it true that there must be no manual config, or simply that one cannot rely on manual config? Thanks, Chris. > > Regards > Brian > > ___ > 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] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]
Hi, > 8. Support for Stub Networks and Stub Routers ... >IS-IS supports stub-networks as defined above >simply by advertising the prefix associated with a link, but not the >link itself. This is sometimes referred to as a "passive link". > >Further an IS-IS router has the ability to set a bit (the overload >bit) to indicate that it should not be used for any transit traffic, >and that it will only be considered a destination for the prefixes it >has advertised, i.e., it is a stub router as defined above. ... >As all distance vector protocols, Babel supports fairly arbitrary >route filtering. Designating a stub network is done with two >statements in the current implementation's filtering language. In a homenet, there must be no manual config. In both cases, how does this work automatically? How does IS-IS know not to advertise the link and set the overload bit, and how does Babel know to include those filtering rules? Or more generally, how does a stub router know that it's a stub router, when there is no human to tell it so? Regards Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] WG Actions
Mark and I have just started a two-week WGLC for draft-ietf-homenet-prefix-assignment: > Subject: IETF WG state changed for draft-ietf-homenet-prefix-assignment > Date: 5 March 2015 12:33:18 GMT > > The IETF WG state of draft-ietf-homenet-prefix-assignment has been > changed to "In WG Last Call" from "WG Document" by Ray Bellis: > > http://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/ As Mark previously suggested we've now also adopted draft-ietf-homenet-hybrid-proxy-zeroconf-00 as a WG item. We had hoped to start WGLC for the two Front-end Naming Delegation drafts but it seems that the issue of how to transfer zones when the IP address of the hidden master has changed still requires further work and review. 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. Finally, as you'll have seen, Margaret just posted draft-mrw-homenet-rtg-comparison-02. We'd like to thank her and her co-authors for the extraordinary effort they've put into this. We would strongly encourage your feedback. thanks, Ray and Mark. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-hncp-04.txt
Just a small update. * reference updates to latest PA and DNCP * behavior for sending RAs was slightly optimized based on some wg comments * 2 issues added to todo-section based on earlier discussions / comments Cheers, Steven On 05.03.2015 14:57, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Control Protocol Authors : Markus Stenberg Steven Barth Pierre Pfister Filename: draft-ietf-homenet-hncp-04.txt Pages : 29 Date: 2015-03-05 Abstract: This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices on top of the Distributed Node Consensus Protocol (DNCP). It enables automated configuration of addresses, naming, network borders and the seamless use of a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-hncp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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] I-D Action: draft-ietf-homenet-hncp-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Control Protocol Authors : Markus Stenberg Steven Barth Pierre Pfister Filename: draft-ietf-homenet-hncp-04.txt Pages : 29 Date: 2015-03-05 Abstract: This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol and a set of requirements for home network devices on top of the Distributed Node Consensus Protocol (DNCP). It enables automated configuration of addresses, naming, network borders and the seamless use of a routing protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-hncp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] I-D Action: draft-ietf-homenet-hybrid-proxy-zeroconf-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Auto-Configuration of a Network of Hybrid Unicast/Multicast DNS-Based Service Discovery Proxy Nodes Author : Markus Stenberg Filename: draft-ietf-homenet-hybrid-proxy-zeroconf-00.txt Pages : 15 Date: 2015-03-05 Abstract: This document describes how a proxy functioning between Unicast DNS- Based Service Discovery and Multicast DNS can be automatically configured using an arbitrary network-level state sharing mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-hybrid-proxy-zeroconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-hybrid-proxy-zeroconf-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Routing Comparison -02
The -02 version of the routing comparison document has been submitted and can be found here: http://www.ietf.org/id/draft-mrw-homenet-rtg-comparison-02.txt This version has been substantially updated since -01, but it does not reflect all of the most recent mailing list discussion. This document is still not intended to reflect the consensus of any group. it was intended to spur an informed discussion in the Homenet WG about which routing protocol would be most suitable for use in Homenet deployments. Depending on how our discussion goes on the list and through the meeting in Dallas, we can decide whether further versions of this document are needed and/or whether it is useful to publish (a version of) this document in a longer-lived form. Margaret ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-ietf-homenet-dncp-01.txt
On 5.3.2015, at 11.19, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Home Networking Working Group of the IETF. > >Title : Distributed Node Consensus Protocol >Authors : Markus Stenberg > Steven Barth > Filename: draft-ietf-homenet-dncp-01.txt > Pages : 28 > Date: 2015-03-05 > > Abstract: > This document describes the Distributed Node Consensus Protocol > (DNCP), a generic state synchronization protocol which uses Trickle > and Merkle trees. DNCP is transport agnostic and leaves some of the > details to be specified in profiles, which define actual > implementable DNCP based protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-homenet-dncp-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-01 Appendix C. Changelog draft-ietf-homenet-dncp-01: o Fixed keep-alive semantics to consider unicast requests also updates of most recently consistent, and added proactive unicast request to ensure even inconsistent keep-alive messages eventually triggering consistency timestamp update. o Facilitated (simple) read-only clients by making Node Connection TLV optional if just using DNCP for read-only purposes. o Added text describing how to deal with "dense" networks, but left actual numbers and mechanics up to DNCP profiles and (local) configurations. Also added one relatively major outstanding issue - how to deal with ‘big data’; even given TCP, currently there is limit of 64kb that a node can publish, and updates of that data are inefficient. Several alternative schemes underoing design, watch this space :) So not quite LC-ready after all; the first change especially was critical, as under heavy load there was flapping due to the new (passive) keepalive definition of dncp-00 being somewhat more strict in what it accepts as ‘present’, compared to hncp-02 ping scheme). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] I-D Action: draft-ietf-homenet-dncp-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Distributed Node Consensus Protocol Authors : Markus Stenberg Steven Barth Filename: draft-ietf-homenet-dncp-01.txt Pages : 28 Date: 2015-03-05 Abstract: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP is transport agnostic and leaves some of the details to be specified in profiles, which define actual implementable DNCP based protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-dncp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Brian, >>> Much as I love MPTCP, it only helps TCP sessions. And it requires both >>> hosts to >>> be updated to be effective. >> >> IPv6 multi-prefix multi-homing requires both hosts to support it. which >> means transport fixes. > > Or fully operational shim6, which was conceived and designed for this > exact problem. right. I tend to think that the problems of multi-homing, multi-endpoint, mobility, and renumbering are tightly coupled. you might need to expose some of this to the transport and applications. I have more hope of solving this at L4.5 or even L5 (I suppose talking about a “session layer” would get me banned from the IETF. ;-)), than at L3.5. to take the digression back to homenet; if we agree this is a problem for transport or above, then at least we can declare victory by claiming it isn’t our problem. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
