[homenet] WGLC comments on ietf-homenet-arch-07

[Michael Richardson <[e-mail]>]

I have read the document from top to bottom.   It isn't ready.

I find that it needs more detailed editing.  It makes quite a number of
non-normative references to documents which might never be published.
I realize that this won't keep the document from moving forward,
but I wonder how useful those references will be in the future.

I do not find that there is really any substantive content in
the architecture document which I disagree with, or which is, at this
point, at all controversal.  I think that actually it should be more
definitive, and in a number of places, significantly less repetitive.

I think that we need two further revisions of this document.

One to tighten things up, and a second to include text on a more
clearly prescriptive notion of what the architecture is.


===
I found this part weird:

   [RFC6204] defines basic requirements for customer edge routers
   (CERs).  The scope of this text is the internal homenet, and thus
   specific features on the CER are out of scope for this text.

I'm confused by this.  If the architecture and requirements set out by
homenet can not apply to the CER, then how does any of this work?
Maybe it needs to say:

   [RFC6204] defines basic requirements for customer edge routers
   (CERs).  The scope of this text is the internal homenet, and thus
   specific features on the **WAN side of** the CER are out of scope for
   this text.
(again in paragraph 2 of section 3)

section 2.4: s/hoemnet/homenet/

Please change:
   In the case where LLNs are
   being set up in a new home/deployment, individual LLNs may, at least
   initially, each use their own /48 ULA prefix.

to;
   In the case where LLNs are
   being set up in a new home/deployment (as early as during
   construction of the home), LLNs will need to use their own /48
   ULA prefix.  Depending upon circumstances beyond the scope of
   homenet, it may be impossible to renumber the ULA used by the LLN
   so routing between ULA /48s may be required.


I'd sure like to UPPERCASE all of:
   As such, neither IPv6 NAT or NPTv6 is recommended for
   use in the homenet architecture.

add to:
   As noted later in this text, if appropriate filtering is in place on
   the CER(s) **(as mandated by RFC6024 requirement S-2)***, a ULA
   source address may be taken as an indication of
   locally sourced traffic.

(while it is clear that BCP38 says that packets with a ULA in the source
field should not be sent upstream, it is unclear to me if BCP38 is
sufficiently clear that ULA packets arriving on the WAN interface
with ULA source addresses should also not be passed into the LAN.)

I wonder if section 2.6 point 1 really belongs.
  "Ensuring there is a way to access concent in the IPv4 Internet."
There is no particular reason this belongs in homenet or has to be
implemented in the home network itself.  There are advantages to doing
it "onsite" if at least one of the CERs has IPv4 connectivity, otherwise
two ISPs implementing DNS64 could confuse the homenet.

3.2.2, "Number of CERs" probably needs a [PCP] reference.

I wonder if the diagrams should have the "Service Provider Network"
label extended to "invade" into the CER:

<text/plain violators beware>

           +-------+-------+     +-------+-------+         \
           |   Service     |     |   Service     |          \
           |  Provider A   |     |  Provider B   |           | Service
           |    Router     |     |    Router     |           | Provider
           +------+--------+     +-------+-------+           | network
                  |                      |                   |
                  |      Customer        |                   |
                  | Internet connections |                  /
                  |                      |		   /
           +------+--------+     +-------+-------+        /
           |     IPv6      |     |    IPv6       |        _ _
           | Customer Edge |     | Customer Edge |           \
           |   Router 1    |     |   Router 2    |           /
           +------+--------+     +-------+-------+          /
</fixed>

3.2.3:

add to:
   In some cases IPv4 home networks may feature cascaded NATs, which
   could include cases where NAT routers are included within VMs, or
   where Internet connection sharing services are used. 

to say:
   In some cases IPv4 home networks may feature cascaded NATs.
   End users are frequently unaware that they have created such
   networks as "home routers" and "home switches" are frequently
   confused. In addition, there are cases where
   NAT routers are included within Virtual Machine Hypervisors 
   (VMware, HyperV, Xen, KVM, VirtualBox, etc...), or
   where Internet connection sharing services have been enabled.
   This document applies to the such hidden NAT "routers" equally.

3.2.4 para 4 s/archiecture/architecture/

3.2.4 (page 18):
   An example of such a 'simpler' approach has been documented in
   [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat].  Alternatively a
   flooding/routing protocol could potentially be used to pass
   information through the homenet, such that internal routers and
   ultimately end hosts could learn per-prefix configuration
   information, allowing better address selection decisions to be made.
   However, this would imply probably host and certainly router changes.
   Or another avenue is to introduce support for source routing
   throughout the homenet; while greatly improving the 'intelligence' of
   routing decisions within the homenet, such an approach would require
   relatively significant router changes.

it seems that we are sitting on the fence here.  I think that we need to
be a bit more prescriptive here?

I think we need a definition of walled garden.  I'm not really happy
with the IAB one that I was pointed to when some said that the IAB said
that walled gardens were bad.

3.4.1: 
       However, if only a /64 is offered by the ISP, the homenet
       may be severely constrained or even unable to function.

I think that we need to say something different in the text that follows.

"if only a single /64 is received by a CER, then the homenet prefix
 distribution protocol MUST contain a way for that CER to signal
 that failure case"

I think that this replaces the text:
  For those reasons it is recommended that
  DHCP-PD or OSPFv3 capable routers have the ability to issue a warning
  upon receipt of a /64 if required to assign further prefixes within
  the home network.  Though some consideration needs to be given to how
  that should be presented to a typical home user.

3.4.1:
   There may be cases where local law means some ISPs are required to
   change IPv6 prefixes (current IPv4 addresses) for privacy reasons for
   their customers.  In such cases it may be possible to avoid an
   instant 'flash' renumbering and plan a non-flag day renumbering as
   per RFC 4192.

Maybe if we are going to talk about this at all, we should reference 
the specific law, and understand if the privacy law wouldn't also be 
violated if my host talked to facebook using prefix1::001 and
prefix2::001 at the same time, so in fact flash renumbering, is in fact
required in order to satisfy the supposed law...

3.4.2 says:
   The use of ULAs should be restricted to the homenet scope through
   filtering at the border(s) of the homenet, as described in RFC 6092.

I'm confused.  6092 doesn't mention ULAs at all?

3.4.2 last paragraph talks about multiple ULAs again and electing a
      master a second time. Might be best to just say this once.
      3.4.3 para 3 says it again.

3.5 I think we have consensus that homenet is deploying a routing protocol.

I think that 3.5 "Any routed solution" should be a seperate section.
Either the requirements in 3.x should have more headings, or we should
have explicit "REQ-XX" things itemized so that later documents can
better refer to this.

I think that perhaps much of section 3.7 could be removed, and replaced
with a some statements from the mdnsext BOF slides.  Simply stating that
"homenet requires site wide service discovery as described in X" should
be an abundant clue to the IESG that mdnsext in some form needs to be
chartered, and identifying gaps is part of our charter.

3.8.1 - I don't think that DiffServ has any utility for a homenet.
      The issue is for QoS is getting an upstream ISP to
      prioritize the relevant traffic onto the downstream
      link(s).  If it's really about traffic entirely internal
      to the homenet, then maybe some well known DSCP will
      do, sure...

      The right architecture, if there is going to be one is
      the IntServ/DiffEdge model.
      http://datatracker.ietf.org/doc/draft-bernet-diffedge/
      I know that diffserv talked a lot about such things, 
      and I'm told win2k can even do this, but to my knowedge
      nothing went forward as a specification.








-- 
Michael Richardson <[e-mail]>, Sandelman Software Works