Subject: [Efficientnd-dt] RS/RA list of items

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2014 17:55:46 -0700

Do we have issues with multicast RS? The data from the IETF didn't show 
it but that might be due to filters in the APs for all-routers??
The DNA RFC currently states that the unicast NS and multicast RS be 
sent in parallel. It might make sense to suggest that hosts implement 
DNA in a way where the multicast RS is deferred so that should it get an 
immediate solicited NA it does not multicast the RS.

Higher timers for periodic RA
  - tuning
  - increasing allowed max in RFC 4861

Encourage router implementations to unicast solicited RAs
  - but listening to Ran's concern about satellite networks, perhaps 
there needs to be a config option so that on links where multicast is 
efficient they can continue to do multicast?

Allow for hosts that optionally want to use RS to refresh the RA 
information.
  - would need a way to limit their traffic
  - again, Ran's satellite network case might mean that the network 
should be in control of this behavior.
  - One could envision a new field/option in the RA with the "RS refresh 
interval".

When a new router appears on the link, per 4861 it will multicast 3 
initial RAs.

What about the case when a router wants to quickly disseminate a change 
(like adding a prefix and deprecating another prefix).
In that case it would make sense to also allow a multicast of 3 initial 
RAs i.e., relax the current spec.

    Erik

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Mar 2014 09:54:13 +0800

Erik,

On Mar 18, 2014, at 8:55 AM, Erik Nordmark <[email-masked]> wrote:

> 
> Do we have issues with multicast RS? The data from the IETF didn't show it but that might be due to filters in the APs for all-routers??
> The DNA RFC currently states that the unicast NS and multicast RS be sent in parallel. It might make sense to suggest that hosts implement DNA in a way where the multicast RS is deferred so that should it get an immediate solicited NA it does not multicast the RS.
> 

See below.. I think there is room for profiling here.

> - but listening to Ran's concern about satellite networks, perhaps there needs to be a config option so that on links where multicast is efficient they can continue to do multicast?
> 
> Allow for hosts that optionally want to use RS to refresh the RA information.
> - again, Ran's satellite network case might mean that the network should be in control of this behavior.
> - One could envision a new field/option in the RA with the "RS refresh interval".

Couldn't we use RA's router lifetime for this purpose? Just add some
clarifications to the rules for sending RSes before the router lifetime
expires (controllable with a config knob or a RA header flag bit) and 
how to set (min|max)rtradvinterval.

I'd be conservative adding a new option for this purpose.

- Jouni

> 
> When a new router appears on the link, per 4861 it will multicast 3 initial RAs.
> 
> What about the case when a router wants to quickly disseminate a change (like adding a prefix and deprecating another prefix).
> In that case it would make sense to also allow a multicast of 3 initial RAs i.e., relax the current spec.
> 
>  Erik
> 
> _______________________________________________
> Efficientnd-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/efficientnd-dt

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Mar 2014 09:34:45 -0700

> See below.. I think there is room for profiling here.

Jouni,
Didn't understand what profiling you had below that relates to the 
advertisement interval.
> how to set (min|max)rtradvinterval.
A RA flag ("please refresh using unicast RS") is sufficient to leave the 
network manager in control (Ran's concern to not make it worse on links 
where multicast is the most efficient way).

The router lifetime can be used but we need to hard-code a ratio.
What I mean is that the default settings is that the router lifetime is 
3x the RA advertisement interval. Thus if that ratio holds, then a RS 
refresh would make sense at e.g. one forth of the router lifetime. 
However, if the network admin configures the ratio between router 
lifetime and RA interval as 10x, then the unicast RS would never trigger.
If the unsolicited RAs are a less frequent (say every 2 hours as opposed 
to the default every 10 minutes) then it wouldn't be unreasonable to use 
a higher ratio. E.g., adv interval 2 hours and router lifetime 18 hours.

As long as we are comfortable picking a fixed ratio R and have the host 
unicast a RS when "router lifetime/R" has expired, then we don't need an 
explicit way for the router to include the RS refresh time in the RA.

So it depends how much control we want to leave to the network admin as 
opposed to hard-coding in the spec.

    Erik

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 19 Mar 2014 09:47:16 +0800

Erik,

On Mar 19, 2014, at 12:34 AM, Erik Nordmark <[email-masked]> wrote:

> Didn't understand what profiling you had below that relates to the advertisement interval.

What I had in mind was possibly giving guidance for (min|max)rtradvinterval
use so that unsolicited RAs are sent closer to expiration of the router
life time. For example saying minrtradvinterval = 0.8 * maxrtradvinterval
and AdvDefaultLifetime = 2 * maxrtradvinterval etc.. in certain types of
environments. As an example..

> A RA flag ("please refresh using unicast RS") is sufficient to leave the network manager in control (Ran's concern to not make it worse on links where multicast is the most efficient way).
> 
> What I mean is that the default settings is that the router lifetime is 3x the RA advertisement interval. Thus if that ratio holds, then a RS refresh would make sense at e.g. one forth of the router lifetime. However, if the network admin configures the ratio between router lifetime and RA interval as 10x, then the unicast RS would never trigger.
> If the unsolicited RAs are a less frequent (say every 2 hours as opposed to the default every 10 minutes) then it wouldn't be unreasonable to use a higher ratio. E.g., adv interval 2 hours and router lifetime 18 hours.

Like in cellular where the lifetime is encouraged to be set to 18 hours.

> As long as we are comfortable picking a fixed ratio R and have the host unicast a RS when "router lifetime/R" has expired, then we don't need an explicit way for the router to include the RS refresh time in the RA.

That would work as what I suggested above as "clarifications" for sending RS.

> So it depends how much control we want to leave to the network admin as opposed to hard-coding in the spec.

Right.. 

- Jouni

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Mar 2014 10:30:07 -0700

> environments. As an example..
If folks have operational recommendations, then we should write them 
down and get feedback.

On lossy links (assuming to unicast RS refresh) the AdvDefaultLifetime 
to maxrtradvinterval ratio must be sufficiently large to get a small 
probability of loosing all of them before the lifetime expires. If it is 
known to the router that the hosts to unicast RS refresh that that isn't 
an issue any more.

> Like in cellular where the lifetime is encouraged to be set to 18 hours.
What is the maxrtradvinterval recommendation?
And does the link ensure reasonable reliability for the multicast RAs?

    Erik

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 20 Mar 2014 09:59:12 +0800

Erik,

On Mar 20, 2014, at 1:30 AM, Erik Nordmark <[email-masked]> wrote:

> If folks have operational recommendations, then we should write them down and get feedback.
> 
> On lossy links (assuming to unicast RS refresh) the AdvDefaultLifetime to maxrtradvinterval ratio must be sufficiently large to get a small probability of loosing all of them before the lifetime expires. If it is known to the router that the hosts to unicast RS refresh that that isn't an issue any more.
> 
>>> 

MaxRtrAdvInterval 6h
MinRtrAdvInterval  0,75 × MaxRtrAdvInterval i.e. 4,5h

> And does the link ensure reasonable reliability for the multicast RAs?

More or less.. the link is considered reliable. Also, the multicast messages are in reality unicast since the link model is p2p for this type of traffic. However, I have seen that RAs still get lost in reality but that has been more of an issue for the initial RAs when the link comes up.

- JOuni