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: [email protected]
> <[email protected]> on behalf of
> Lorenzo Colitti <[email protected]>
> 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
> <[email protected]<mailto:[email protected]>> 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.
>
