Subject: [homenet] FW: New Version Notification for draft-grundemann-homenet-hipnet-00.txt

From: Chris Grundemann <[email-masked]>
Date: Wed, 20 Feb 2013 19:38:55 +0000

Dear Homenet,

CableLabs, in cooperation with our members and vendor companies, is
enhancing our eRouter specification to support multirouter home networks.
As we have in the past, we are presenting our eRouter updates to the IETF
in the spirit of sharing.  We believe that these enhancements meet the
principles of the homenet-arch document, while not relying on new protocol
development.

In addition, we are prototyping these enhancements, and are planning to
demonstrate them in Orlando.

Cheers,
~Chris

On 2/16/13 8:27 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-grundemann-homenet-hipnet-00.txt
>has been successfully submitted by Chris Donley and posted to the
>IETF repository.
>
>Filename:	 draft-grundemann-homenet-hipnet
>Revision:	 00
>Title:		 A Near Term Solution for Home IP Networking (HIPnet)
>Creation date:	 2013-02-15
>Group:		 Individual Submission
>Number of pages: 22
>URL:             
>http://www.ietf.org/internet-drafts/draft-grundemann-homenet-hipnet-00.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-grundemann-homenet-hipnet
>Htmlized:        
>http://tools.ietf.org/html/draft-grundemann-homenet-hipnet-00
>
>
>Abstract:
>   Home networks are becoming more complex.  With the launch of new
>   services such as home security, IP video, Smart Grid, etc., many
>   Service Providers are placing additional IPv4/IPv6 routers on the
>   subscriber network.  This document describes a self-configuring home
>   router that is capable of operating in such an environment, and that
>   requires no user interaction to configure it.  Compliant with
>   draft-ietf-homenet-arch, it uses existing protocols in new ways
>   without the need for a routing protocol.
>
>
>                  
>        
>
>
>The IETF Secretariat
>

---

From: Mattia Rossi <[email-masked]>
Date: Thu, 21 Feb 2013 09:46:37 +0100

Hi Chris,

reading the draft, it seems clear that it is bound to your specific 
CableLabs eRouter use case.
I haven't understood if this is just an informational draft, or whether 
you want to pursue it further and adapt the draft to create a standard. 
In the latter case, some thoughts:

It's not clear, that it would work with all the scenarios outliend in 
section 3.2.2 of the homenet architecture 
(http://tools.ietf.org/html/draft-ietf-homenet-arch-07).
E.g. how does it cover Multihoming? If an internal router gets two 
addresses, one from each prefix, and assuming no CER_ID, how do you 
ensure that the /48 check works, and it doesn't pick the first address, 
comparing it to the second prefix, and thus declaring the router a CER 
which it is not?
I believe that's a non-issue, as the /48 check is done on a 
per-interface basis, but that's not documented in the draft.
A multihoming section where you explain this, would be beneficial I think.

I also don't like the "/48 check" notation, as it implies that ISP's 
hand out a /48 (even if stated otherwise in the text).
If you call it "ISP prefix check" or "Delegated prefix check" would be 
better, as the principle is, that the ISP hands out an address to the 
CER which is different from the delegated prefix, while the CER hands 
out addresses from that prefix.

Cheers,

Mat

Am 20.02.2013 20:38, schrieb Chris Grundemann:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Chris Donley <[email-masked]>
Date: Thu, 21 Feb 2013 16:23:38 +0000

>CableLabs eRouter use case.
Just as our eRouter specification was relevant to the wider community as a
contribution to RFC 6204/bis, we believe that our updates to support
multirouter topologies are also relevant beyond the cable ecosystem.

>you want to pursue it further and adapt the draft to create a standard.
This is informational.  We are bringing our updates to the IETF, in case
others can benefit from our work.  We expect to be able to demonstrate
this functionality in Orlando on OpenWRT routers - stop by and check it
out.

>A multihoming section where you explain this, would be beneficial I think.
Multihoming is covered in Section 6 (Multiple ISPs). We believe that our
approach will cover the scenarios in the homenet arch document, as well as
some additional ones (e.g. 2 ISPs, 2 CERs, non-shared subnet e.g. For
VPNs). To your point, we could clarify that the /48 check is per prefix
per interface.
>out addresses from that prefix.
Thanks.  We'll consider it for a future version.
>Mat

Chris
-- 
Chris Donley
CCIE, CISSP, SCiPM
Director - Network Technologies
CableLabs®
858 Coal Creek Circle
Louisville, CO 80027
303-661-3480 (v)

---

From: Erik Kline <[email-masked]>
Date: Tue, 26 Feb 2013 12:08:08 +0900

WRT to Section 4.1, I think the "/48 check" may not be a good idea.
It may work for /your/ deployment models, but it doesn't necessarily
work for all.  Furthermore, if this were widely adopted it would
effectively enforce that deployment model all providers, needlessly I
think.

Consider a deployment model that I believe I first heard from Lorenzo:
a customer is allocated a prefix AND the "zero-numbered" /64 from that
prefix is advertised in the RA toward the customers home gateway.
(Really any <64 customer prefix and any single /64 would work, like
the "all ones" /64--it doesn't particularly matter.)  I'm not aware of
anything that technically precludes this nor do I think we should move
to preclude it now.

(Note: there may be some home gateways that are not be smart enough to
recognize that one of the prefixes delegated to it is in use already
on one of its interfaces (e.g. WAN), but homenet can require such
intelligence.)

So, your text could try to recognize that IF there is only one
allocated prefix in the home && IF an interface is not number from
that prefix THEN it must be an edge.  That's fine.  But being numbered
from within the allocated prefix does not necessarily mean that it's
an interior router.