RA & DHCP problem...

[Brian E Carpenter]

On 30/12/2013 16:29, Dmitry Anipko wrote:
> Is there a chance this discussion can be captured in http://tools.ietf.org/html/draft-yourtchenko-ra-dhcpv6-comparison-00 , or in some other "problem statement" document for potential issues re configuring routing with RAs?

What I'm seeing is Nick describing a use case in bits and pieces.
If we could have a draft that describes the use case completely,
with example numerical requirements, that would be very helpful IMHO.

I think that would be better than including a detailed use case in draft-yourtchenko.

    Brian

> There has been a few discussion recently on this topic, and hence it does seem there is pain, however it doesn't seem there is a consensus on what all the pain points exactly are, as well as that DHCP is necessarily the right cure for that pain.
> 
> 
> To me it seems that capturing pain points in a document, which by going through the standard IETF process would (or would not) gather consensus on the problem statement, could be a productive way to move forward toward a solution.
> 
> ________________________________
> From: ipv6-ops-bounces+dmitry.anipko=microsoft.com at lists.cluenet.de <ipv6-ops-bounces+dmitry.anipko=microsoft.com at lists.cluenet.de> on behalf of Lorenzo Colitti <lorenzo at google.com>
> Sent: Sunday, December 29, 2013 2:25 PM
> To: Nick Hilliard
> Cc: IPv6 Ops list
> Subject: Re: RA & DHCP problem...
> 
> On Sun, Dec 29, 2013 at 10:18 PM, Nick Hilliard <nick at foobar.org<mailto:nick at foobar.org>> wrote:
> On 29/12/2013 20:48, Lorenzo Colitti wrote:
>> Is the size an issue here? Is there something about having tens of
>> thousands of IPv6 hosts that makes RAs unsuitable?
> 
> yes, size is an issue: it means that tweaking ns-interval is not feasible
> as a mechanism for dropping failover times.
> 
> Agreed, using NUD timers for failover (aka "hammer the first-hop router") doesn't scale.
> 
> and if your hosts miss a packet, you get traffic swinging to your other
> default.  You may like to debug this sort of thing, but I operate in
> companies with non-telephone number cost constraints and have a strong need for operational simplicity and consistency.
> 
> It depends on how much loss there is and how many hosts switch. But yes, you probably want some margin.
> 
>> The operator can drop a protocol, but the host implementer needs to
>> handle
> 
> yep, exactly, but please bear in mind that networks are provisioned by
> operators for end-users.  Network stacks are not written by host
> implementers for their own gratification.
> 
> True, but the party that pays the cost is always the end user.
> 
> doesn't scale.  Routers are routers, not policy management engines.  DHCP is for policy management and there is just no scalable way of handling this on routers.
> 
> There's nothing stopping the routers from getting this information via RADIUS.
> 
>> DHCP doesn't help there. If you want better than that, you need to use
>> something like VRRP anyway.
> 
> Yes, I know:  DHCPv6 + a first-hop routing protocol.  This is the scenario
> I am interested in deploying.  You know what?  It works really well in
> practice.
> 
> Well, but so does RA + VRRPv3. In addition to working in practice, it's a standard.
>