RE: draft-ietf-6man-resilient-rs update

[Dmitry Anipko <[e-mail]>]

Hi Ole,

>> I do agree with that. the specific concern with the MAY, is that we'll end up with inconsistent behaviour on the link. I'd much rather that we specified behaviour in detail.

Ok, can you elaborate to what level of details you'd expect the behavior to be specified? Is statement on rate limiting would be sufficient, or you think the description of the algo along the lines of DHCPv6 retransmissions is needed (or the latter could be referenced)?

>> I think the argument made is that the issues are somewhat tangled together.

While the issues might be somewhat tangled, it doesn't necessarily follow that the solutions have to be tangled - particularly if the solution to the massive multicast background traffic may not come fast.

>> if you made RD more resilient against packet loss, then you may end up solving the "no periodic multicast" case as a side effect.

Yes, it might happen, and I think it's fine if we solve that scenario currently described in the draft. 
That said, I don't think that for this draft we must pursue the goal of addressing the general multicast issues raised in the other recent drafts. This draft pursues incremental improvement in the context of the existing protocol.

>>1) the initial connection problem
2) not robust enough in case of packet drop / what to do when (last) router lifetime expires / last address expires
3) links without periodic RAs

Speaking for myself only, I think either (1) & (2) or (1) & (2) & (3) are fine.

>> ii) solve both problem 1 and 2. which implies taking the document back to the working group

I'd suggest re-phrasing this as "instructing the authors to update the scenario text and the suggested host behavior and re-submit for LC".

Thank you,
Dmitry



-----Original Message-----
From: Ole Troan [mailto:[e-mail]] 
Sent: Tuesday, July 29, 2014 1:49 AM
To: Dmitry Anipko
Cc: Suresh Krishnan; <[e-mail]>; [e-mail]; 6man WG
Subject: Re: draft-ietf-6man-resilient-rs update

> Let's separate discussions on the substance and on what exact language we put in the draft. 
> 
> Substance wise - IMO, the change tries to reduce existing fragility of RD in some situations. We had very real real-world support cases with one of the top mobile operators in the US, where the network was not sending new RAs before expiring the info in the initial one. Yes, this was  a misconfiguration / bug on the network side. Yes, this is where it was eventually fixed, and yes perhaps the support teams should not have taken as much time to figure it out. But the end-users don't care about that part, and they would be better off in the meantime if the protocol had more resiliency against misconfiguration or packet loss. Speaking for myself only, this is the scenario I'm concerned about. I'm sure there are others who know the "no multicast RAs, period" scenario better than I do, and they can speak for that.
> 
> So I think it would be good to first understand, leaving specific RFC language aside, whether there is consensus to improve RD reliability when the host sees that previously received information has expired / about to expire. My impression from the discussion in London was that there was such consensus - but perhaps I misunderstood. Letting the host do additional rate-limited transmissions to solve that, to me looks like a simple and reasonable approach. If you agree with that, then what's the specific concern on putting that as MAY?

I do agree with that. the specific concern with the MAY, is that we'll end up with inconsistent behaviour on the link. I'd much rather that we specified behaviour in detail.

> I do disagree with the viewpoint, that because if ND use of multicast is inefficient, let's not make any improvements to ND until multicast issue is solved. Yes, the multicast-related issues in general do need to be addressed over long term. But addressing them will take time, and there are issues today which end-users are hitting, for which incremental limited fixes within existing framework are possible and reasonable.

I think the argument made is that the issues are somewhat tangled together. 

>>> today, links without periodic RAs are not supported.
> 
> Since this is a statement about today, it equally applies (or not applies), to the option 2 you suggested and the option I suggested, so it's not a differentiator. Furthermore, it basically is equivalent to option 1, which makes it not an independent argument, but re-iterating option 1, and can't be used as a differentiator there either.

if you made RD more resilient against packet loss, then you may end up solving the "no periodic multicast" case as a side effect.

so for the question of what to do with the resilient RS draft. there seems to be at least three problems:
1) the initial connection problem
2) not robust enough in case of packet drop / what to do when (last) router lifetime expires / last address expires
3) links without periodic RAs

solving 2 may inadvertently solve 3.

before posing the questions to the working group, let's agree on the questions.
can we ask the working group to choose between the following two options:
i) only solve problem 1 in the resilient-rs draft. which implies remove text about no periodic RAs
ii) solve both problem 1 and 2. which implies taking the document back to the working group

cheers,
Ole