[dhcwg] draft-stenberg-pd-route-maintenance

As threatened in the WG meeting, some comments to work on section
2.1 of this document, offered in a playful spirit even if my
writing style doesn't convey that.

In general, I'd like to see this document try and imagine the "best"
deployment of the described architecture, and then point out flaws
in it, rather than to imagine all the worst ideas and point out
just how bad it could get if you really tried.

I get the idea also that while writing this section, the author
switched between the idea of, say, perl scripts writing DR
configuration syntax down an SSH channel, and a routing protocol
approach.  I think in that case you should separate this into two
different sections (as the first few bulletpoints apply to the
former but not the latter).

   Considering the backend provisioning system is the only component in
   the system that actually requires significant amount of nonvolatile
   storage, from data system point of view it would be ideal to have the
   backend provisioning system responsible for maintaining the routing
   state as well.

Consider also: the provisioning system is usually colocated or in
direct communication (providing configuration state for) the DHCP
server.  This puts it in a unique position: it is authoritative
for what prefix is assigned to what purpose.  By definintion it is
the one thing that is never 'confused' due to out-of-order delivery
or similar, there are also fewer "protocol components" involved
(system->routing vs system->dhcpv6->routing).

Beyond that I think the summary of this approach's advantages is well
stated.

I basically don't agree with, or think they are too broadly stated, with
any of the bulletpoints.  I can do a blow- by-blow if you think that's
helpful, but I suspect it would be easier to go the other route and say
how I would have written this section and you can point out what that
misses (proposed draft text in quotes):

1) A DR might be a more 'physical' layered device that does its best
   work ("core competency") at the physical layer, and really only
   manages marginally to do the minimum required at any subsequent
   layers.  To ask such a device to implement everything required
   from a full IP/TCP/UDP stack on up to BGP (or "some routing
   protocol") is really asking quite a lot.  It is amazing enough as
   it is that they manage 'static routing', and might even be 'pinged'
   without crashing.  Let's not talk about SNMP.

   Simply stated, it is a bad idea to ask CMTS manufacturers to
   implement BGP.  The resulting abomination would be a horror.

	"Routing may not be the DR manufacturer's core competency,
	 so using a full routing protocol may exceed reasonable
	 expectations in software development investment."

2) The groups of people responsible for DHCP network deployments
   are generally not the same group of people for the ISP's core
   network.

   Simply stated, Sysadmins very rarely know the lay of the BGP
   land, and probably would lose their fingers if they touched its
   state in any way.

	"The existence of multiple administrative sub-domains
	 within a network that are responsible for the design
	 and operation of core versus edge components complicates
	 integration of DR devices with the core network's routing
	 protocol.  DR operators rarely have either direct access
	 to their network's routing protocols, or experience with
	 using or troubleshooting them, as these are roles usually
	 relegated to another office."

3) A DR may be expected to implement a kind of extra sensory perception
   for the RR.  For example, let us imagine that the 'Network' and 'RR'
   are attached via VLANs, transported by DR's.  This ensures that every
   RR (which might be a customer-premise device) is in a broadcast
   domain with no other-customer RR's, and only shares the broadcast
   domain with a 'router' in the "Network" box in your ASCII art.  This
   may even be the most desirable scenario, but it necessitates that the
   DR construct the VLAN connection, and again we have all kinds of issues
   entering into detecting remote reboots and remote configuration state
   among fault-tolerant endpoints.  DHCPv6 is a good idea for such
   configuration state, and some mechanism for the DR to get its brains
   back if it shifts roles or reboots is necessary.

   So the point here is that even with such a mechanism covering the
   routing state, we still need a mechanism to recover DR configuration
   state.

	"Even if the routing state is carried via a technique such as
	 this, it may not remove the need for a means for DR devices
	 to re-acquire their RR-specific configuration state.  It also
	 presents a form of de-centralization to convey this information
	 in two different places, which may not be desirable."

4? In the 3) scenario it's probably also wasteful to apply a globally
   routable prefix to every Network<->RR connection (using only two
   addresses), so the RR is only going to have a global address if it
   chooses one from the delegated prefix.  I think this bridge is usually
   gapped in IPv6 networks using link state routing protocols (so BGP
   points a prefix to an address that is found to have a route over a
   locally-addressed link).

   Conceding to point 1 above, we have to require a much more simple
   means to allow a DR to be the bridge in this locally-addressed gap.

   I don't know a lot about this scenario, so I'm hesitant to try and
   say more.  I'm already out on the proverbial limb in terms of my own
   experiences.

I find it strangely curious that for the second time today on two
different topics, I am making a distinction between 'configuration'
state and 'routing' state being carried by DHCPv6.

At any rate, with those three points alone, and the introductory
paragraph you already have, the idea is generally well documented that
although the technique might work well in certain deployments (you
cover the main 'good' points in that introduction paragraph), it is
not a universal solution, and there's a documented need to fulfill
requirements in other use cases.

The 4th thing is probably a quagmire getting far too close to the
details.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins