Re: [homenet] 6renum redux [Routing protocol comparison document]

On Tue, 3 Mar 2015, Juliusz Chroboczek wrote: I still think there needs to be quite a lot of work done on APIs and best common practices in order for applications to do the right thing so this kind of renumbering event works. Most likely it's going to require a FOSS library that will act as a mi

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Wed, 4 Mar 2015, Mark Andrews wrote: We could also extend the temporary / permanent address model to PD. You get two prefixes from the ISP. One is designed to servers and other things that need long term stability. One is designed for ephemeral use. The application chooses which to use l

Re: [homenet] L2 link status [was: More about marginal links]

> Op 3 mrt. 2015, om 21:50 heeft Curtis Villamizar het > volgende geschreven: > > In message > > Henning Rogge writes: > >> On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar >> wrote: >>> The basis for the metric in RFC 7181 is out of scope. So what did you >>> use? >> >> This: >> https:

Re: [homenet] 6renum redux [Routing protocol comparison document]

In message <54f6aace.3030...@globis.net>, Ray Hunter writes: > > Ted Lemon > > 4 March 2015 03:21 > > On Mar 3, 2015, at 4:55 PM, Ray Hunter wrote: > >> One hour TTL could mean 24 times the DNS traffic compared to that historic > norm. It also could mean (re)signing DNS

Re: [homenet] 6renum redux [Routing protocol comparison document]

Ted Lemon 4 March 2015 03:21 On Mar 3, 2015, at 4:55 PM, Ray Hunter wrote: One hour TTL could mean 24 times the DNS traffic compared to that historic norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as hosts move around the homenet...

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Mar 3, 2015, at 4:55 PM, Ray Hunter wrote: > One hour TTL could mean 24 times the DNS traffic compared to that historic > norm. It also could mean (re)signing DNSSEC zones more than 24 times per day > as hosts move around the homenet... Caching is really only interesting for query cluste

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Tuesday, March 3, 2015, Juliusz Chroboczek wrote: > > I still think there needs to be quite a lot of work done on APIs and best > > common practices in order for applications to do the right thing so this > > kind of renumbering event works. Most likely it's going to require a FOSS > > library

Re: [homenet] 6renum redux [Routing protocol comparison document]

In message <54f62dda.9020...@globis.net>, Ray Hunter writes: > > Ted Lemon > > 3 March 2015 20:36 > > > > Why do you say that? Is a ~60 minute TTL too short for a home device? > > I don't think so. As soon as the old address is deprecated, you remove > > the record poin

Re: [homenet] 6renum redux [Routing protocol comparison document]

Ted Lemon 3 March 2015 20:36 Why do you say that? Is a ~60 minute TTL too short for a home device? I don't think so. As soon as the old address is deprecated, you remove the record pointing to it--you don't keep it around. You install records only for non-depreca

Re: [homenet] 6renum redux [Routing protocol comparison document]

> I still think there needs to be quite a lot of work done on APIs and best > common practices in order for applications to do the right thing so this > kind of renumbering event works. Most likely it's going to require a FOSS > library that will act as a middle layer between the application and th

Re: [homenet] 6renum redux [Routing protocol comparison document]

In message , Mikael Abrah amsson writes: > On Tue, 3 Mar 2015, Mark Andrews wrote: > > > What we really should be telling ISPs is that renumber events should be > > make before break. There is zero reason other plain poor customer > > service to not do this. > > There are some markets in the

Re: [homenet] L2 link status [was: More about marginal links]

In message Henning Rogge writes: > On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar > wrote: > > The basis for the metric in RFC 7181 is out of scope. So what did you > > use? > > This: > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 It seems like with this draft, pack

Re: [homenet] 6renum redux [Routing protocol comparison document]

In message <54f611a6.2000...@gmail.com>, Brian E Carpenter writes: > > > Regards >Brian Carpenter >http://orcid.org/-0001-7924-6182 > > > > On 04/03/2015 05:54, Mikael Abrahamsson wrote: > > On Tue, 3 Mar 2015, Ray Hunter wrote: > > > >> I think there are two completely separate

Re: [homenet] 6renum redux [Routing protocol comparison document]

Regards Brian Carpenter http://orcid.org/-0001-7924-6182 On 04/03/2015 05:54, Mikael Abrahamsson wrote: > On Tue, 3 Mar 2015, Ray Hunter wrote: > >> I think there are two completely separate mechanisms being discussed >> here: the need for rapid failover to a previously known altern

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Mar 3, 2015, at 11:42 AM, Ray Hunter wrote: > I think caching in the name/address space sets a much more relevant lower > limit on the speed of renumbering/ roaming via L3 on wifi/ whatever other > event that causes your host's address(es) to change. > > Otherwise you're forced into either t

Re: [homenet] L2 link status [was: More about marginal links]

On Tue, Mar 3, 2015 at 8:12 PM, Curtis Villamizar wrote: > The basis for the metric in RFC 7181 is out of scope. So what did you > use? This: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-04 I am still using the multicast loss (plus the raw link speed) to judge the links, but I

Re: [homenet] L2 link status [was: More about marginal links]

In message Henning Rogge writes: > Sorry, > > too much working on the implementation side of NHDP/OLSRv2 in the last > years... should have thought a bit more about the reply before sending > it. > > Yes, you are correct that RFC6130 does not contain the description of > the link metric...

Re: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00

Ole Troan wrote: > > I was planning on using ISC DHCP 4.3.1 together with an external script > > as described in https://github.com/mpalmer/isc-dhcp contrib, to detect the > > next hop address of my homenet router and install the relevant route for > > the delegated prefix on the last-hop ISP rou

Re: [homenet] routing protocol comparison document and hncp

> > Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to > bootstrap a certificate infrastructure, zero touch. Once every device in a > domain has a domain certificate, two devices can directly authenticate each > other, without PSK. Then you can also authenticate a key negotiati

Re: [homenet] routing protocol comparison document and hncp

On 03/03/2015 09:37 AM, Michael Behringer (mbehring) wrote: I scanned this over (I think I've scanned Max's base doc too, but it's been a long time), and don't think that the problem at hand has much to do with needing a CA of any sort. Binding "human" names to cryptographic identities is fraugh

Re: [homenet] routing protocol comparison document and hncp

> -Original Message- > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Michael > Thomas > Sent: 03 March 2015 18:20 > To: homenet@ietf.org > Subject: Re: [homenet] routing protocol comparison document and hncp > > On 03/03/2015 08:43 AM, Gert Doering wrote: > > Hi, > > > > On

Re: [homenet] routing protocol comparison document and hncp

On 03/03/2015 08:43 AM, Gert Doering wrote: Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are re

Re: [homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00

On Mon, 2 Mar 2015, Ole Troan wrote: typically the ISP router snoops DHCPv6 messages and does route injection based on that, or the DHCPv6 server runs on the ISP router and does route injection based on binding state. So this is a plausible way of doing intra-home mobility of prefixes. Unfor

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Tue, 3 Mar 2015, Ray Hunter wrote: I think there are two completely separate mechanisms being discussed here: the need for rapid failover to a previously known alternative address for your partner device, and discovering the alternative addresses of your partner. Agree. The one thing I t

Re: [homenet] MPVD requirments in homenet

Hi Ole, By saying "multiple services" I mean the services (i.e. Basic internet, VoIP, VoD...) that can be generally provisioned independently from each other, not necessarily from a single provider. Best wishes, Liang -邮件原件- 发件人: homenet [mailto:homenet-boun...@ietf.org] 代表 Ole Troan 发送时

Re: [homenet] routing protocol comparison document and hncp

Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: > Considering that provisioning personal certificates is the almost the > polar opposite of zeroconf, the chances > of the normal schlub seeing an informative and/or trustworthy name are > really, really low. You might want to

Re: [homenet] 6renum redux [Routing protocol comparison document]

Mikael Abrahamsson wrote: On Tue, 3 Mar 2015, Michael Sweet wrote: True, but most video conferencing software and live video feeds handle disconnects gracefully (enough) already, and most streaming video is not done using a single file/URL but with a series of files/URLs, with each file/URL

Re: [homenet] 6renum redux [Routing protocol comparison document]

On 3.3.2015, at 18.04, Michael Sweet wrote: >> I just tried this. I was on the same subnet on wired ethernet and on wifi >> (etablished the call on wired with disabled wifi, enabled wifi, waited 30 >> seconds, then unplugged wired) using my OSX macbook, using Skype voice >> session with another

Re: [homenet] 6renum redux [Routing protocol comparison document]

Mikael, > On Mar 3, 2015, at 10:34 AM, Mikael Abrahamsson wrote: > ... > So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6 hour? > 12 hour? My guess is around 1 hour, but clearly that is something that should be tested to verify (and ideally be configurable). > I just trie

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Tue, 3 Mar 2015, Michael Sweet wrote: True, but most video conferencing software and live video feeds handle disconnects gracefully (enough) already, and most streaming video is not done using a single file/URL but with a series of files/URLs, with each file/URL representing a "chapter" or

Re: [homenet] routing protocol comparison document and hncp

On 03/03/2015 05:55 AM, David Oran wrote: On Mar 2, 2015, at 9:05 PM, Michael Thomas wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s)

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Mar 3, 2015, at 8:57 AM, Mikael Abrahamsson wrote: >> This is probably the use case we most care about. I think it's actually a >> strong argument for going with a longer deprecation period. E.g., if your >> deprecation period were three hours, we simply wouldn't have a problem. > > I don'

Re: [homenet] 6renum redux [Routing protocol comparison document]

Mikael, > On Mar 3, 2015, at 8:57 AM, Mikael Abrahamsson wrote: > > On Tue, 3 Mar 2015, Ted Lemon wrote: > >> This is probably the use case we most care about. I think it's actually a >> strong argument for going with a longer deprecation period. E.g., if your >> deprecation period were thr

Re: [homenet] MPVD requirments in homenet

Liang, what do you mean by "multiple services"? if you mean walled garden, the homenet architecture only has the following to say: "It should be noted that some multihoming scenarios may see one upstream being a "walled garden" and thus only appropriate for connectivity to the services

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Tue, 3 Mar 2015, Ted Lemon wrote: This is probably the use case we most care about. I think it's actually a strong argument for going with a longer deprecation period. E.g., if your deprecation period were three hours, we simply wouldn't have a problem. I don't agree with this at all.

Re: [homenet] routing protocol comparison document and hncp

> On Mar 2, 2015, at 9:05 PM, Michael Thomas wrote: > > On 03/02/2015 01:21 PM, Brian E Carpenter wrote: >> On 03/03/2015 09:12, Michael Thomas wrote: >>> >>> I'm doubtful that routing protocols need PSK's. They almost certainly >>> would like to share a symmetric key(s) but >>> is not the same

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Mar 3, 2015, at 8:20 AM, Mikael Abrahamsson wrote: > I can imagine a stream video application that uses a single TCP session, and > watching a movie over this can easily take more than an hour. I need to > check, but I would imagine for instance xbmc accessing a http(s) based file > server w

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Tue, 3 Mar 2015, Ted Lemon wrote: Why? The only case where it will matter is for long-lived connections that can't restart. So your overnight ssh, or your very long download. Any other use will survive the renumbering event because you gave an hour's notice. Deprecated addresses already

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Mar 3, 2015, at 3:24 AM, Mikael Abrahamsson wrote: > I still think there needs to be quite a lot of work done on APIs and best > common practices in order for applications to do the right thing so this kind > of renumbering event works. Most likely it's going to require a FOSS library > that

Re: [homenet] routing protocol comparison document and hncp

> On Mar 2, 2015, at 7:32 PM, Curtis Villamizar wrote: > > In message <7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org> > Christian Hopps writes: > >> Hi homenet-wg, >> >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace H

[homenet] MPVD requirments in homenet

Hi all, I'm Liang from China Mobile, a recent follower of this community. Following a previous thread concerning the discussion of MPVD in Homenet on 3rd Feb, I personally think that certain use cases are quite well in line with the mif MPVD scenario. As homenet architecture provides autonomic

Re: [homenet] routing protocol comparison document and hncp

Hi, On Mon, Mar 02, 2015 at 07:48:24PM -0500, Curtis Villamizar wrote: > The way IETF has normally done things is to allow multiple > developments to exist if they have support and then drop only those > that are not being deployed or prove to be less desirable. "Having multiple examples of runni

Re: [homenet] 6renum redux [Routing protocol comparison document]

On Tue, 3 Mar 2015, Mark Andrews wrote: What we really should be telling ISPs is that renumber events should be make before break. There is zero reason other plain poor customer service to not do this. There are some markets in the world, where customers *demand* to be frequently renumbered