headers
Tim Chown | 19 Jun 2013 12:37
Picon
Favicon

Re: 2nd Working Group Last Call for draft-homenet-arch

On 19 Jun 2013, at 11:08, Ray Bellis <Ray.Bellis <at> nominet.org.uk> wrote:

> On 18 Jun 2013, at 22:46, Juliusz Chroboczek <jch <at> pps.univ-paris-diderot.fr> wrote:
> 
>> I think we can take it asa given that OSPF will be chosen for Homenet, whether some of us like it or not.
> 
> Actually I don't think that's a given at all.
> 
> It happens that the initial efforts by some participants have focused on OSPF, but I hear there's quite a
few people now thinking that IS-IS would be a better choice.
> 
> Lack of open source implementations is a potential impediment, of course, although it's expected that
BIRD (from cz.nic) will have IS-IS support some time pretty soon.

So we've seen some examples of the zeroconf prefix assignment/configuration in action through
implementations of draft-arkko-homenet-prefix-assignment-04 and
draft-ietf-ospf-ospfv3-autoconfig-02. These have used Bird and Quagga. While obviously just proof of
concept, these were deployed on commodity devices. The Bird implementation went further, supporting
src&dst based routing, which was demonstrated at the previous two IETFs.

It would be interesting to see the equivalent solution based on IS-IS. I'm not sure who the "quite a few
people" are, but it would be a good time for them to put something more tangible forward.

Prior discussions have also proposed other routing protocols for homenet.

As someone else mentioned, the prefix and routing information could be passed in ND/RAs, or that function
could potentially be part of any extended naming/SD protocols that emerge from the "mdnsext" BoF and
subsequent work. What the homenet-arch text needs to capture is the general principles/requirements.  I
think with the changes suggested by Ole, which are fairly minor, it will do so.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikael Abrahamsson | 19 Jun 2013 10:49
Picon
Favicon

Re: 2nd Working Group Last Call for draft-homenet-arch

On Wed, 19 Jun 2013, Steven Barth wrote:

> But let me ask the other way: What relevant usecase would such a 
> solution not cover? or What would be covered better by something like 
> OSPF in a home network?

Let's say you have a cable Internet operator, handed off in a coax outlet 
next to your TV in your living room. The coax goes to their CER, which 
hands off an ethernet port. At the other end of the apartment/house, your 
FTTH connection is handed off in a media converter, also a CER. You 
connect a wireless AP to each of these and also connect up them together, 
so you have identical behaving SSID across the different domains, you 
prefer the APs to be routers, because you also have non-ethernet sensors 
you want to hook up. Now a PD hierarchy from each CER will cross each 
others, and how do you know what packet to send where to avoid uRPF 
filtering for each set of addresses? Perhaps you also want to build a ring 
of the APs around your house so in case you need to change out one of 
them, you don't break connectivity to everything else.

I don't see how this can be solved without distributing more information 
to routers than they would have using purely DHCPv6-PD.

I'm sure some will say above is bordering on overengineering and it's more 
"enterprise", but I believe people will want the above to work because 
their homenet will be more crucial to them in 10-20 years than it is 
today. I know a lot more people using RAID5 or RAID6 today compared to 10 
years ago, same thing with backups etc.

> I'd just like to avoid a solution which adds much complexity and 
> provides more features than actually needed today just because it could
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Chown | 19 Jun 2013 01:12
Picon
Favicon

Re: draft-ietf-homenet-arch comments

On 18 Jun 2013, at 23:19, Ole Troan <otroan <at> employees.org> wrote:

> I've battled through the whole document again. I'm quite happy to see this document proceed as is.
> some nits and comments below. note I'm also a co-author although I haven't held the pen for a while.

You are always welcome to pick it up again; you have the xml :)  We should agree the full list of changes first though.

> this document could benefit from some weight loss throughout. the text is riddled with excess, just in the
abstract alone
> you can cut: increasingly, general, associated, briefly, suggests, can be employed (are used), 

Probably, yes.  Mark and Ray are concerned that any -08 to -09 changes should be no more than needed, so that
the tools diff view isn't bigger than it needs to be. Let's see what they say about that.

> s/pro-active management/active management
> 
> s/CER/CE router/?
> how many names do we need for a CPE, Home Gateway, Residential Gateway, CE, CE Router, pick one of the
existing ones

So now you want the text longer :)  I really don't mind, again, let's see what the chairs want.

> section 2.2 on global addressablity - include a paragraph stating that the network is exposed to ISP
renumbering the network
> to a much larger degree than before. NAT isolated the user against ISP renumbering to some extent.

True, but that is also the point of using ULAs.  We can make it more explicit though.

> section 2.4 ULA
> paragraph on security by restricting reachability. ULAs can be used by default for devices that without configuration
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Chown | 19 Jun 2013 00:57
Picon
Favicon

Re: 2nd Working Group Last Call for draft-homenet-arch

Hi,

Just a note to say that as the main editor I had a 30 min chat with the WG co-chairs Ray and Mark today in which we
discussed the WGLC feedback. The chairs will be posting an update soon. Below are some responses in the
meantime. I hope these are in line with the WG chair views; if not, I'm sure Ray or Mark will correct/clarify.

Firstly, the -08 version was produced after reading some 500-600 emails over many threads, either side of
the Orlando IETF meeting. It was impractical to respond to every point by email. No views were ignored,
rather I attempted to draw consensus from the views posted, without being swayed by the volume of comments
from some posters.  It seems that more recent comments agree that -08 is improved as a result.

The architecture text describes general principles and requirements, but not in 2119 language. As a
document, it should thus be viewed as a guide as to where homenet is heading, based on the consensus of the
WG. It is not intended to provide every specific detail in this text; further documents will do that, e.g.
for homenet naming and service discovery, where I certainly agree that more detailed work is needed, some
of which will hopefully be linked to the BoF on that topic in Berlin. Thus, for example, while forming the
largest possible subnets has been agreed as desirable, the text does not prescribe how that should be
achieved. Similarly the document does not intend to imply that mDNS is a given (it is cited as an example of a
zeroconf solution), or, given it's come up in this thread, 
 a link-state routing protocol.

Perhaps the most contentious issue is the use of ULAs; may, should or must? It seems there's consensus that
the text should be at least a "should". There is a parallel ula-usage draft that Sheng Jiang is working on
with others. This also brings up the point on whether we are designing with today's system constraints in
mind, e.g. where older systems are less likely to do appropriate address selection when deployed in a
homenet that only has external IPv4 connectivity, but has ULAs turned on internally. In general, I don't
feel we should constrain the design, but we do state that there is a preference for established/proven
protocols, and running (open source) code, and that changes to hosts and routers should be minimised. 

Regarding hipnet, it seems there needs to be a transition/coexistence path between what we have today,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ole Troan | 19 Jun 2013 00:19
Favicon

draft-ietf-homenet-arch comments

I've battled through the whole document again. I'm quite happy to see this document proceed as is.
some nits and comments below. note I'm also a co-author although I haven't held the pen for a while.

cheers,
Ole

-----

this document could benefit from some weight loss throughout. the text is riddled with excess, just in the
abstract alone
you can cut: increasingly, general, associated, briefly, suggests, can be employed (are used), 

s/pro-active management/active management

s/CER/CE router/?
how many names do we need for a CPE, Home Gateway, Residential Gateway, CE, CE Router, pick one of the
existing ones

section 2.2 on global addressablity - include a paragraph stating that the network is exposed to ISP
renumbering the network
to a much larger degree than before. NAT isolated the user against ISP renumbering to some extent.

section 2.4 ULA
paragraph on security by restricting reachability. ULAs can be used by default for devices that without configuration
only should offer services to the internal network. e.g. a printer could only accept incoming connections
on a ULA,
until configured to be globally reachable.

section 3.3.2 largest possible subnets.
this seems to say, if something can be bridged together do so. is that what we want to recommend?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Arnaud Kaiser | 18 Jun 2013 15:25
Picon
Favicon

For information: Announced new draft on MIF WG: draft-kaiser-if-sel-00

Dear participants to homenet group,

We submitted "Interface Selection Mechanism for Multiple Interfaces IPv6 
Hosts" draft-kaiser-if-sel-00 available at:
http://tools.ietf.org/html/draft-kaiser-if-sel-00

This document describes an interface selection mechanism that enables
multiple interfaces (multihomed) IPv6 hosts to select their most
appropriate egress interface to send data over the network. The
mechanism extends the Neighbor Discovery (ND) protocol [RFC4861] with
two new Router Advertisement options.

The proposed mechanism has been developed in the context of home network 
and may be relevant to HOMENET WG.

Your comments are very welcome.

Thanks in advance,

Arnaud & Alex
Permalink | Reply | 1 comment |
headers
Michael Thomas | 17 Jun 2013 22:31
Favicon

section 3.6.3


dissing nat as a security measure is fine by me, but i'm not sure that going on to diss firewalls
is really appropriate. i haven't heard of any great movement to remove them, even though they
cause trouble with new fangled protocols.

the one area that i wonder about is carrier ip connectivity on phones: i assume that they are
behind the carriers firewall? if they aren't, or that firewall is really permissive maybe there's
something to this section. if not, do we really have evidence to be so dismissive of firewalls?

Mike
Permalink | Reply | 5 comments |
headers
Acee Lindem | 17 Jun 2013 11:47
Picon
Favicon

Re: 2nd Working Group Last Call for draft-homenet-arch


On Jun 17, 2013, at 5:25 AM,  wrote:

> 
> On Jun 17, 2013, at 12:51 AM, Juliusz Chroboczek wrote:
> 
>>> This email marks the commencement of the second Working Group Last
>>> Call for draft-ietf-homenet-arch-08.  The WGLC will end on Monday
>>> June 17th.
>> 
>> I've read this draft with great interest.  There's a lot about it that
>> I like.
>> 
>> Unfortunately, I've noticed one paragraph that I believe is wrong.  In
>> Section 3.5, you say:
>> 
>>  It is desirable that the routing protocol has knowledge of the
>>  homenet topology, which implies a link-state protocol is
>>  preferable.  This would mean the routing protocol gives
>>  a consistent view of the network, and that it can pass around more
>>  than just routing information.
>> 
>> This would seem to imply that only link-state protocols can "give
>> a consistent view of the network", and that only link-state protocols
>> can "pass around more than just routing information".  I'm pretty sure
>> BGP and EIGRP experts would disagree with that.
>> 
>> Is it too late to remove this paragraph?
> 
> It is not too late to remove it but there is no reason to remove it. BGP is not used for constructing a
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ray Bellis | 3 Jun 2013 15:35
Picon
Favicon

2nd Working Group Last Call for draft-homenet-arch

This email marks the commencement of the second Working Group Last Call for draft-ietf-homenet-arch-08. 
The WGLC will end on Monday June 17th.

Please send your comments soonest, and in particular please check that any issues that you highlighted
during the previous WGLC have been addressed.

Ray and Mark.
Permalink | Reply | 64 comments |
headers
Tim Chown | 20 May 2013 15:32
Picon
Favicon

Re: Source-specific routes in Linux [was: atomic updates...]

On 8 May 2013, at 10:45, Dave Taht <dave.taht <at> gmail.com> wrote:

On Wed, May 8, 2013 at 2:29 AM, Tim Chown <tjc <at> ecs.soton.ac.uk> wrote:
On 7 May 2013, at 12:08, Markus Stenberg <markus.stenberg <at> iki.fi> wrote:
>
> Yet another implementation of interest might be:
>
> https://github.com/edderick/quagga_zOSPF/
>
> [1]/[2] versions do not interoperate with it (but they interoperate with
> Arkko one); latest [3] version interoperates with it, but not Arkko..)

Hi,

So the github zOSPF iplementation above was done this year by an undergraduate project student of mine, Ed Seabrook.  He has tested his code against both Ben's and Markus' implementations, using a netkit test environment, with pretty successful results overall.  Ed has given some feedback to the draft authors based on his experience.

It would be helpful if those comments were more public. 

Markus and Edward have discussed the issues arising from Edward's project work.  There is a small number of open questions/ambiguities resulting. I agree these should be summarised and posted here for comment to help improve the relevant draft(s).


Ed chose to build on Quagga because he knew the bird implementations existed, and wanted to show interoperability with a different platform.  

CeroWrt uses quagga-RE (for BGPpgp and babel support), and if it is possible to merge these patches into that branch, and the results useful, I'd be delighted to do so...

It would be useful to get some code review... I'll email you off-list.

Tim
_______________________________________________
homenet mailing list
homenet <at> ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Permalink | Reply | 0 comments |
headers
Tim Chown | 10 May 2013 10:24
Picon
Favicon

New revision of homenet arch doc

Hi,

A new revision of the homenet arch doc is almost done.  We hope to push it out over the weekend. So if you have any
burning issues you feel haven't been raised, now would be a good time to air them.

Thanks,
Tim
Permalink | Reply | 0 comments |

Gmane