On 2/21/13 1:46 AM, "Mattia Rossi" <[email protected]> wrote:
>Hi Chris, > >reading the draft, it seems clear that it is bound to your specific >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. >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. 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. > >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. 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. > >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. Thanks. We'll consider it for a future version. > >Cheers, > >Mat Chris -- Chris Donley CCIE, CISSP, SCiPM Director - Network Technologies CableLabs® 858 Coal Creek Circle Louisville, CO 80027 303-661-3480 (v) > >Am 20.02.2013 20:38, schrieb Chris Grundemann: >> 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 protected]" >><[email protected]> >> 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.t >>>xt >>> 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 >>> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > >_______________________________________________ >homenet mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
