Subject: [homenet] I-D Action: draft-ietf-homenet-arch-09.txt

From: [email-masked]
Date: Mon, 15 Jul 2013 07:17:00 -0700

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 Architecture for IPv6
	Author(s)       : Tim Chown
                          Jari Arkko
                          Anders Brandt
                          Ole Troan
                          Jason Weil
	Filename        : draft-ietf-homenet-arch-09.txt
	Pages           : 49
	Date            : 2013-07-15

Abstract:
   This text describes evolving networking technology within
   increasingly large residential home networks.  The goal of this
   document is to define a general architecture for IPv6-based home
   networking, describing the associated principles, considerations and
   requirements.  The text briefly highlights specific implications of
   the introduction of IPv6 for home networking, discusses the elements
   of the architecture, and suggests how standard IPv6 mechanisms and
   addressing can be employed in home networking.  The architecture
   describes the need for specific protocol extensions for certain
   additional functionality.  It is assumed that the IPv6 home network
   is not actively managed, and runs as an IPv6-only or dual-stack
   network.  There are no recommendations in this text for the IPv4 part
   of the network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-arch

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-arch-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-09

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 15 Jul 2013 16:33:42 +0200

Dear editors,

Thanks for the hard work.

I haven't had time to review the new document fully yet, but I'm still
concerned about the second paragraph of 3.5:

   It is desirable, but not absolutely required, that the routing
   protocol be able to give a complete view of the network, and that
   it be able to pass around more than just routing information.

This implies to me that we're recommending single-area link-state
protocols, and in particular that we're outlawing route filtering
(since link-state protocols can only filter at area boundaries, and
since at any rate route filtering prevents having a complete view).
We might still be allowing stub areas (the text doesn't say that the
complete view must be available everywhere within the network), but
we're definitely discouraging fully general multi-area operation.

Could you please confirm that this is the expected meaning?  Is there
consensus on this list that route filtering is not useful in a homenet
environment?  If this is the case, perhaps this should be stated
explicitly and justified.

For the record, I still recommend that this sentence should be removed.

Thanks,

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Mon, 15 Jul 2013 18:07:49 +0200

> For the record, I still recommend that this sentence should be removed.
I think the current text is fine, and I don't agree with the suggested
interpretation that this text implies a single link state protocol must
be used and that route filtering may not be performed. Being capable of
doing something is very different from always having to do it.

regards
RayH

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 15 Jul 2013 19:02:30 +0200

> be used and that route filtering may not be performed.

Ok, then I'm missing something.

What exactly does "a complete view" mean?  Does it mean that every
router in a homenet must be able to determine the complete topology of
the homenet?  Does it mean that there is at least one router that can
determine the complete topology of the network?  Does it mean something
else?

If you manage to explain exactly what is meant by this sentence, I'll
try to craft a wording suitable for the draft.

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Mon, 15 Jul 2013 21:19:21 +0200

Juliusz Chroboczek wrote:
> the homenet? 
There's no must in the original text.

>  Does it mean that there is at least one router that can
> determine the complete topology of the network? 

I don't think that's a necessary requirement, depending on which nodes
are intending to use which upstream ISP connections.

>  Does it mean something

The following statements are not incompatible with the current text IMHO.

The routing protocol SHOULD be able to transport more information than
just routing information.

The routing protocol SHOULD be capable of providing a Homenet device
with a complete topological view of the network.

A Homenet router MAY filter routing information where appropriate.

---

From: Tim Chown <[email-masked]>
Date: Mon, 15 Jul 2013 22:19:27 +0100

> For the record, I still recommend that this sentence should be removed.

Julius, you wrote those precise words yourself last month, agreeing with Ole that the wording was good.  And I agreed with both of you.  So I'm confused as to why you've now chosen to change your mind.  

I think you're inferring something that isn't written.  The homenet realms and borders section explains that policy can include potentially any information at each border.

Anyway, this is what you wrote:

On 18 Jun 2013, at 22:46, Juliusz Chroboczek <[email-masked]> wrote:

> Ole Troan wrote:
>> second paragraph section 3.5 routing functionality:
>> 
>>   "The homenet unicast routing protocol should preferably be an existing
>>   deployed protocol that has been shown to be reliable and robust, and
>>   it is preferable that the protocol is both 'lightweight' and that
>>   open source implementations are readily available.  It is desirable
>>   that the routing protocol has knowledge of the homenet topology.
>>   This would mean the routing protocol gives a complete view of the network,
>>    and that it can pass around more than just routing information."
> 
> Yeah, that's fine with me.  I'm not a native speaker, but here's my
> best attempt:
> 
>    The homenet unicast routing protocol should be a previously deployed
>    protocol that has been shown to be reliable, robust, to allow
>    lightweight implementations, and of which open source
>    implementations are available.  It is desirable, but not absolutely
>    required, that the routing protocol be able to give a complete view
>    of the network, and that it be able to pass around more than just
>    routing information.

Tim

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 16 Jul 2013 00:30:15 +0200

> Julius, you wrote those precise words yourself last month, agreeing
> with Ole that the wording was good.  And I agreed with both of you.

Yes, I didn't realise the implications at the time.  Sorry for that.

(I didn't "write those precise words" -- I just kept the formulation
which I believed at the time to be better than the technically incorrect
previous formulation.)

> So I'm confused as to why you've now chosen to change your mind.

Honest mistake that I'm trying to fix.  I was focusing on removing the
bit that implied that only link-state can be "consistent", and didn't
pay attention to the implications of the more precise formulation.

I am sincerely sorry for the esprit d'escalier, I really should have
realised earlier.

> I think you're inferring something that isn't written.

I'm glad to hear that.  I'm sure we agree that filtering is an
important tool that should not be outlawed by the arch document.

The current wording makes me uncomfortable.  Are you positive that the
current formulation is good, and doesn't run the risk of inducing
folks into error?  Or should we add an explanatory sentence, or remove
the bit about "complete view" altogether?

-- Juliusz