Re: [homenet] standard way of configuring homenets

[Tim Chown]

On 25 Jul 2018, at 04:13, Ted Lemon mailto:mel...@fugue.com>> 
wrote:

Well, the charter certainly says that we're supposed to think about homenet's 
impact on manageability.   Granted, that's a thin reed to hang on, and it would 
probably be better to make the charter more explicit.   But to be clear here, 
all home networks have user interfaces, and this is all we are talking about.   
We've somewhat skirted the issue, but if we want to be able to have an 
enrollment process, that's going to have a user interface.   If we want to be 
able to do things like change the SSIDs, that's going to require a user 
interface.

In my mind, the idea of homenet is not to be an unmanaged network, but to be a 
network that doesn't require management to operate.   If you don't do any 
managing, it should still work.   That doesn't mean that doing some managing is 
a bad thing.   And if we don't specify something in this regard, I'm afraid 
we're going to wind up with lots of homegrown management UIs that force people 
to buy all their homenet routers from a single vendor.

There’s brief discussion of this in RFC 7368, where I recall some text was 
added in response to an Ops Area AD’s input, see 
https://tools.ietf.org/html/rfc7368#section-3.8.2

Tim


On Tue, Jul 24, 2018 at 10:59 PM, STARK, BARBARA H 
mailto:bs7...@att.com>> wrote:
 Since homenet is supposed to be about an unmanaged network, 
and configuration via a management protocol requires somebody who knows what 
they’re doing, it doesn’t fall within my interpretation of the charter.
Barbara

From: homenet mailto:homenet-boun...@ietf.org>> On 
Behalf Of Ted Lemon
Sent: Tuesday, July 24, 2018 5:57 PM
To: Michael Richardson mailto:mcr%2bi...@sandelman.ca>>
Cc: homenet mailto:homenet@ietf.org>>
Subject: Re: [homenet] standard way of configuring homenets

I don't think using HNCP in that particular way is a great plan, but I'm 
willing to be convinced.   I would hope that this is in charter.

On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

I very much like the idea of having a standard way to configure homenets.
There is the YANG/NETCONF method, and I think that we should go in that
direction.

A thought I had though could a HOMENET configuration be recorded by
capturing just HNCP traffic?  Could a network configuration be restored
by essentially playing back that stuff?  I'm pretty sure that this won't
work, but the question is... should it?

Does this work fit into the charter?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  
http://www.sandelman.ca/
|   ruby on rails[



___
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 mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] standard way of configuring homenets

[Brian E Carpenter]

On 25/07/2018 14:59, STARK, BARBARA H wrote:
>  Since homenet is supposed to be about an unmanaged network, 
> and configuration via a management protocol requires somebody who knows what 
> they’re doing, 

Traditionally, yes, but we do actually want to get away from that.
(It's our explicit goal to do that in ANIMA, for which homenets are
out of scope, but we assume that the starting point is a NOC staffed
by people who know what they are doing.)

The idea of capturing a homenet config and saving it for future use
doesn't seem outlandish to me, and using tools developed for
managed networks, but operated robotically instead of manually, doesn't
seem crazy either. But it might be a big effort and a distraction.

   Brian

> it doesn’t fall within my interpretation of the charter.
> Barbara
> 
> From: homenet  On Behalf Of Ted Lemon
> Sent: Tuesday, July 24, 2018 5:57 PM
> To: Michael Richardson 
> Cc: homenet 
> Subject: Re: [homenet] standard way of configuring homenets
> 
> I don't think using HNCP in that particular way is a great plan, but I'm 
> willing to be convinced.   I would hope that this is in charter.
> 
> On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson 
> mailto:mcr+i...@sandelman.ca>> wrote:
> 
> I very much like the idea of having a standard way to configure homenets.
> There is the YANG/NETCONF method, and I think that we should go in that
> direction.
> 
> A thought I had though could a HOMENET configuration be recorded by
> capturing just HNCP traffic?  Could a network configuration be restored
> by essentially playing back that stuff?  I'm pretty sure that this won't
> work, but the question is... should it?
> 
> Does this work fit into the charter?
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  
> http://www.sandelman.ca/
> |   ruby on rails[
> 
> 
> 
> ___
> 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 mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] standard way of configuring homenets

[Ted Lemon]

Well, the charter certainly says that we're supposed to think about
homenet's impact on manageability.   Granted, that's a thin reed to hang
on, and it would probably be better to make the charter more explicit.
 But to be clear here, all home networks have user interfaces, and this is
all we are talking about.   We've somewhat skirted the issue, but if we
want to be able to have an enrollment process, that's going to have a user
interface.   If we want to be able to do things like change the SSIDs,
that's going to require a user interface.

In my mind, the idea of homenet is not to be an unmanaged network, but to
be a network that doesn't require management to operate.   If you don't do
any managing, it should still work.   That doesn't mean that doing some
managing is a bad thing.   And if we don't specify something in this
regard, I'm afraid we're going to wind up with lots of homegrown management
UIs that force people to buy all their homenet routers from a single vendor..

On Tue, Jul 24, 2018 at 10:59 PM, STARK, BARBARA H  wrote:

>  Since homenet is supposed to be about an unmanaged
> network, and configuration via a management protocol requires somebody who
> knows what they’re doing, it doesn’t fall within my interpretation of the
> charter.
>
> Barbara
>
>
>
> *From:* homenet  *On Behalf Of *Ted Lemon
> *Sent:* Tuesday, July 24, 2018 5:57 PM
> *To:* Michael Richardson 
> *Cc:* homenet 
> *Subject:* Re: [homenet] standard way of configuring homenets
>
>
>
> I don't think using HNCP in that particular way is a great plan, but I'm
> willing to be convinced.   I would hope that this is in charter.
>
>
>
> On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson 
> wrote:
>
>
> I very much like the idea of having a standard way to configure homenets.
> There is the YANG/NETCONF method, and I think that we should go in that
> direction.
>
> A thought I had though could a HOMENET configuration be recorded by
> capturing just HNCP traffic?  Could a network configuration be restored
> by essentially playing back that stuff?  I'm pretty sure that this won't
> work, but the question is... should it?
>
> Does this work fit into the charter?
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/
> 
>   |   ruby on rails[
>
>
>
> ___
> 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] standard way of configuring homenets

[STARK, BARBARA H]

 Since homenet is supposed to be about an unmanaged network, 
and configuration via a management protocol requires somebody who knows what 
they’re doing, it doesn’t fall within my interpretation of the charter.
Barbara

From: homenet  On Behalf Of Ted Lemon
Sent: Tuesday, July 24, 2018 5:57 PM
To: Michael Richardson 
Cc: homenet 
Subject: Re: [homenet] standard way of configuring homenets

I don't think using HNCP in that particular way is a great plan, but I'm 
willing to be convinced.   I would hope that this is in charter.

On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson 
mailto:mcr+i...@sandelman.ca>> wrote:

I very much like the idea of having a standard way to configure homenets.
There is the YANG/NETCONF method, and I think that we should go in that
direction.

A thought I had though could a HOMENET configuration be recorded by
capturing just HNCP traffic?  Could a network configuration be restored
by essentially playing back that stuff?  I'm pretty sure that this won't
work, but the question is... should it?

Does this work fit into the charter?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  
http://www.sandelman.ca/
|   ruby on rails[



___
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] standard way of configuring homenets

[Ted Lemon]

I don't think using HNCP in that particular way is a great plan, but I'm
willing to be convinced.   I would hope that this is in charter.

On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson 
wrote:

>
> I very much like the idea of having a standard way to configure homenets.
> There is the YANG/NETCONF method, and I think that we should go in that
> direction.
>
> A thought I had though could a HOMENET configuration be recorded by
> capturing just HNCP traffic?  Could a network configuration be restored
> by essentially playing back that stuff?  I'm pretty sure that this won't
> work, but the question is... should it?
>
> Does this work fit into the charter?
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>
> ___
> 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] standard way of configuring homenets

[Michael Richardson]

I very much like the idea of having a standard way to configure homenets.
There is the YANG/NETCONF method, and I think that we should go in that
direction.

A thought I had though could a HOMENET configuration be recorded by
capturing just HNCP traffic?  Could a network configuration be restored
by essentially playing back that stuff?  I'm pretty sure that this won't
work, but the question is... should it?

Does this work fit into the charter?

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 




signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07

[Daniel Migault]

Hi Denis,

Thanks for the feed back! The big read arrow symbolized the synchronization
between the zone hosted on your HNA and the DNS Public server on the
outsourcing infrastructure. This could be your ISP or any third party. One
of the motivation to outsource was to prevent DDoS attack on the HNA, so as
mention Ted, if your ISP is as reliable as your HNA you may use a third
party to host your zone. However, the HNA hosts the Hidden primary and is
expected to host the most up-to date content. When you switch from one ISP
to another, these ISP are hosting secondary servers and your hidden primary
are expected to be able to synchronize with these secondaries. As a result
the zone published on the Internet is expected to remain synchronized. The
problem by switching from one outsourcing infrastructure to the other, is
that information stored in cache resolver (NS) may not be up-to-date for
TTL seconds. As mentioned Ted, we expect that the hosting infrastructure is
able to host relatively safely.

I believe this concern might also be relevant to the dhcp option draft
where we explicitly had the discussion of an ISP providing the service. In
this draft the DNS Zone Template is a template that is expected to be
provisioned by the HNA. In other words, the template is not expected to
contain all elements. The template is mostly useful when the HNA is
booting. As a result, it is likely that there are very little changes over
time and remain the same over the time you switch from one ISP to the
other. If not up-to-date, the HNA may also update the template.

Yours,
Daniel



On Tue, Jul 24, 2018 at 12:35 PM, Ted Lemon  wrote:

> My personal feeling on this is that the off-site backup zone is a service
> that could be provided by an ISP, could be provided by someone else, or
> could just be something that a sufficiently geeky user sets up for
> themself.   If an ISP connection is as flaky as you describe, I would think
> that they would be a poor candidate for offering this service, although as
> long as it is reachable through ISP B, and is updated accurately, it should
> be fine.   If your point is that the homenet should notice if it can't
> maintain contact with the off-site backup server, I think that's a good
> point.
>
> On Tue, Jul 24, 2018 at 12:31 PM, Denis Ovsienko 
> wrote:
>
>> Hello group.
>>
>> What I was trying to say at the WG meeting was the following. Looking at
>> the slide with the red arrow between a DNS server in the home network and a
>> DNS server somewhere on the Internet, the following scenario immediately
>> came to my mind.
>>
>> 1. A home network is connected to the Internet through an ISP A.
>> Everything is synchronous and works.
>> 2. The link to ISP A fails.
>> 3. For the next month the home network remains half time disconnected and
>> half time connected through ISP B. Regardless of the Internet reachability,
>> devices come and go, and the network tries to update its zone.
>> 4. The link to ISP A is restored and works for the next three months.
>> 5. The user occasionally connects to ISP B in parallel, as a matter of
>> habit.
>> 6. Go to 2.
>>
>> Now, given the suggestion that the ISP maintains the zone, it would make
>> sense to think what happens when the ISP's copy is no longer updated and
>> the home network copy has changed. I have briefly looked through the I-D
>> and have not found anything that would explicitly make sure that the zone
>> cannot go split-brain. And if it goes split-brain, will it necessarily
>> synchronize afterwards with no human intervention? Maybe those provisions
>> are there, but I did not see them, in that case please disregard the
>> comment.
>>
>> Feel free to use this input to improve the document, if it gives you any
>> new ideas.
>>
>> --
>> Denis Ovsienko
>>
>>
>> ___
>> 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 mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07

[Ted Lemon]

My personal feeling on this is that the off-site backup zone is a service
that could be provided by an ISP, could be provided by someone else, or
could just be something that a sufficiently geeky user sets up for
themself.   If an ISP connection is as flaky as you describe, I would think
that they would be a poor candidate for offering this service, although as
long as it is reachable through ISP B, and is updated accurately, it should
be fine.   If your point is that the homenet should notice if it can't
maintain contact with the off-site backup server, I think that's a good
point.

On Tue, Jul 24, 2018 at 12:31 PM, Denis Ovsienko 
wrote:

> Hello group.
>
> What I was trying to say at the WG meeting was the following. Looking at
> the slide with the red arrow between a DNS server in the home network and a
> DNS server somewhere on the Internet, the following scenario immediately
> came to my mind.
>
> 1. A home network is connected to the Internet through an ISP A.
> Everything is synchronous and works.
> 2. The link to ISP A fails.
> 3. For the next month the home network remains half time disconnected and
> half time connected through ISP B. Regardless of the Internet reachability,
> devices come and go, and the network tries to update its zone.
> 4. The link to ISP A is restored and works for the next three months.
> 5. The user occasionally connects to ISP B in parallel, as a matter of
> habit.
> 6. Go to 2.
>
> Now, given the suggestion that the ISP maintains the zone, it would make
> sense to think what happens when the ISP's copy is no longer updated and
> the home network copy has changed. I have briefly looked through the I-D
> and have not found anything that would explicitly make sure that the zone
> cannot go split-brain. And if it goes split-brain, will it necessarily
> synchronize afterwards with no human intervention? Maybe those provisions
> are there, but I did not see them, in that case please disregard the
> comment.
>
> Feel free to use this input to improve the document, if it gives you any
> new ideas.
>
> --
> Denis Ovsienko
>
>
> ___
> 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] after the meeting comments on draft-ietf-homenet-front-end-naming-delegation-07

[Denis Ovsienko]

Hello group.

What I was trying to say at the WG meeting was the following. Looking at the 
slide with the red arrow between a DNS server in the home network and a DNS 
server somewhere on the Internet, the following scenario immediately came to my 
mind.

1. A home network is connected to the Internet through an ISP A. Everything is 
synchronous and works.
2. The link to ISP A fails.
3. For the next month the home network remains half time disconnected and half 
time connected through ISP B. Regardless of the Internet reachability, devices 
come and go, and the network tries to update its zone.
4. The link to ISP A is restored and works for the next three months.
5. The user occasionally connects to ISP B in parallel, as a matter of habit.
6. Go to 2.

Now, given the suggestion that the ISP maintains the zone, it would make sense 
to think what happens when the ISP's copy is no longer updated and the home 
network copy has changed. I have briefly looked through the I-D and have not 
found anything that would explicitly make sure that the zone cannot go 
split-brain. And if it goes split-brain, will it necessarily synchronize 
afterwards with no human intervention? Maybe those provisions are there, but I 
did not see them, in that case please disregard the comment.

Feel free to use this input to improve the document, if it gives you any new 
ideas.

-- 
Denis Ovsienko


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] homenet 102 minutes

[STARK, BARBARA H]

Hi homenet,
Draft minutes have been posted. 
Thx to Phill Hallam-Baker for taking them.
https://datatracker.ietf.org/meeting/102/materials/minutes-102-homenet-01.html
Please let us know if you think they need changes.
Barbara and Stephen

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Ted Lemon]

You said that having state in the homenet makes it brittle.   That implies
that you think a stateless homenet will be less brittle, no?

On Tue, Jul 24, 2018 at 4:34 AM, Juliusz Chroboczek  wrote:

> > Juliusz is saying that he wants a nearly stateless homenet;
>
> No, I'm not.
>
> > for him, putting the public/primary functional block in the cloud makes
> > sense
>
> No, it doesn't.
>
> Ted, please don't put words into my mouth.  It's unpleasant, and it's
> disrespectful.
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] (no subject)

[Juliusz Chroboczek]

> Juliusz is saying that he wants a nearly stateless homenet;

No, I'm not.

> for him, putting the public/primary functional block in the cloud makes
> sense

No, it doesn't.

Ted, please don't put words into my mouth.  It's unpleasant, and it's
disrespectful.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet