Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly"

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Mar 2014 11:04:44 -0700

Let's keep some momentum going by touching base for half an hour or less 
every other week starting next week.

Please pick a time in the poll.

http://doodle.com/usa83cbr5z5mfuny

In terms of working through the issues it would be good have some structure.

What do we need to do as a team to get more data from deployment problems?
What about analysis of existing implementations e.g., to understand the 
unsolicited NAs to all-nodes we saw in London?

I suggest we work through the suggestions somewhat separate for the 
three areas:
  - RS/RA
  - NS/NA for address resolution
  - DAD

I'll start writing up the ideas and issues following that structure, but 
if someone wants to take one of them and drive it let me know.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Mar 2014 23:29:18 +0000

Hello Erik;

Your split of the problem space makes sense to me; we could make a table to map it with solution space. 
The solution space we discussed so far to divide the broadcast domain would be (to my recollection):

1) no ND, a /64 per device. I think John will detail this approach and use cases where that makes sense (including 3G).
2) Mixed registered node vs. classical nodes (efficient ND). In that model the usage of NS/NA multicast is reduced roughly by the ratio of registered nodes.
3) Multiple private (secondary) vlans with a primary (federating) vlan where all the common services would reside. In that model devices in a pvlan cannot reach devices in other pvlans and DAD proxy is used to avoid address collisions globally. All multicasts including NS/NA from the primary vlan are effectively flooded but not multicasts originated from the pvlans which are limited to the pvlan and the primary. This is also deployable today and we probably can document how it works and when it makes sense to use it. 
4) backbone router model: If registered nodes are all on the "southern" side of the backbone routers and classical ND runs over a federating backbone on the "northern" side then NS / NA mcasts can be completely avoided in the southern domain. With the backbone routers acting as proxies, any to any reachability is available for global and ULA unicast addresses. 

In model 1 the subnet can be much smaller than the link. In model 2 the subnet is congruent with the link. In the last 2 models, the subnet is larger than the links, IOW we are in multilink subnet space.

Cheers,

Pascal

> -----Original Message-----
> From: Efficientnd-dt [mailto:[email-masked]] On Behalf Of Erik
> Nordmark
> Sent: vendredi 14 mars 2014 11:05
> To: [email-masked]
> Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly"
> 
> 
> I suggest we work through the suggestions somewhat separate for the three
> areas:
>   - RS/RA
> I'll start writing up the ideas and issues following that structure, but if someone
> wants to take one of them and drive it let me know.
> 
>     Erik
> 
> _______________________________________________
> Efficientnd-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/efficientnd-dt

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 15 Mar 2014 10:43:29 +0000

Hi Pascal/Erik:

Will 6man be interested in dealing with multi-link subnets?

But I agree that we should at least separate out the problem space  for the multi-link subnet models.

-Samita

-----Original Message-----
From: Efficientnd-dt [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, March 14, 2014 4:29 PM
To: Erik Nordmark; [email-masked]
Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly"

Hello Erik;

Cheers,

Pascal

> From: Efficientnd-dt [mailto:[email-masked]] On 
> Behalf Of Erik Nordmark
> Let's keep some momentum going by touching base for half an hour or 
> less every other week starting next week.
> 
> What about analysis of existing implementations e.g., to understand 
> the unsolicited NAs to all-nodes we saw in London?
> 
> three
> I'll start writing up the ideas and issues following that structure, 
> but if someone wants to take one of them and drive it let me know.
> 
>     Erik
>

---

From: Erik Kline <[email-masked]>
Date: Mon, 17 Mar 2014 14:46:09 +0900

Pascal,

> 2) Mixed registered node vs. classical nodes (efficient ND). In that model the usage of NS/NA multicast is reduced roughly by the ratio of registered nodes.
...
> In model 1 the subnet can be much smaller than the link. In model 2 the subnet is congruent with the link. In the last 2 models, the subnet is larger than the links, IOW we are in multilink subnet…

It's not clear to me that this #2 mixed mode is not also the
multi-link model.  In the "factory with lots of sensors and some
normal hosts" example, that to me was a multi-link example, was it
not?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Mar 2014 06:35:24 +0000

Hello Erik

> Le 17 mars 2014 à 06:46, "Erik Kline" <[email-masked]> a écrit :
> 
> Pascal,
> 
That is model 4 actually.

In both cases the router will proxy ND.

In model 2, the TLLA in the proxied NA will be that of the device. The packets can be switched to the mac of the destination and Layer 2 has to support the mobility of the device. 

In model 4 the TLLA in the proxied NA will be that of the router. This allows for sleeping devices and not switchable addresses, eg mac64 in 802.15.4 or firewire.

WiFi could play in both case with pro/cons but the factory is 6TiSCH, definitely an MLSN, because of:
- mesh routing
- incompatible mac 

Cheers,
Pascal

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 17:03:13 +0900

All,

just to make things very clear from the start: I think we need a detailed
problem statement (more likely, more than one, since there's more than one
problem to solve) before we move into solution space.

The efficient-nd draft does not have what I consider to be a useful problem
statement for this purpose, because it starts with the assumption that it
is a goal to remove as much ND multicast traffic as possible. I don't think
we know yet whether this is a goal or not.

Cheers,
Lorenzo

On Sat, Mar 15, 2014 at 8:29 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> 1) no ND, a /64 per device. I think John will detail this approach and use
> cases where that makes sense (including 3G).
> 2) Mixed registered node vs. classical nodes (efficient ND). In that model
> the usage of NS/NA multicast is reduced roughly by the ratio of registered
> nodes.
> 3) Multiple private (secondary) vlans with a primary (federating) vlan
> where all the common services would reside. In that model devices in a
> pvlan cannot reach devices in other pvlans and DAD proxy is used to avoid
> address collisions globally. All multicasts including NS/NA from the
> primary vlan are effectively flooded but not multicasts originated from the
> pvlans which are limited to the pvlan and the primary. This is also
> deployable today and we probably can document how it works and when it
> makes sense to use it.
> 4) backbone router model: If registered nodes are all on the "southern"
> side of the backbone routers and classical ND runs over a federating
> backbone on the "northern" side then NS / NA mcasts can be completely
> avoided in the southern domain. With the backbone routers acting as
> proxies, any to any reachability is available for global and ULA unicast
> addresses.
>
> In model 1 the subnet can be much smaller than the link. In model 2 the
> subnet is congruent with the link. In the last 2 models, the subnet is
> larger than the links, IOW we are in multilink subnet space.
>
> Cheers,
>
> Pascal
>
> if someone

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2014 11:01:56 -0700

On 3/17/14 1:03 AM, Lorenzo Colitti wrote:
> All,
>
> just to make things very clear from the start: I think we need a 
> detailed problem statement (more likely, more than one, since there's 
> more than one problem to solve) before we move into solution space.
>
> The efficient-nd draft does not have what I consider to be a useful 
> problem statement for this purpose, because it starts with the 
> assumption that it is a goal to remove as much ND multicast traffic as 
> possible. I don't think we know yet whether this is a goal or not.
Lorenzo,
What type of problem statement you have in mind?
Please send text ;-) At least an example indicating the direction would 
be very helpful.

I think David offered some wording at the 6man microphone but I don't 
remember the exact words.
Perhaps it was something along the lines of ND not getting in the way of 
scaling a subnet to have lots more hosts??

    Erik

>
> Cheers,
> Lorenzo
>
>
> On Sat, Mar 15, 2014 at 8:29 AM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Erik;
>
>     1) no ND, a /64 per device. I think John will detail this approach
>     and use cases where that makes sense (including 3G).
>     2) Mixed registered node vs. classical nodes (efficient ND). In
>     that model the usage of NS/NA multicast is reduced roughly by the
>     ratio of registered nodes.
>     3) Multiple private (secondary) vlans with a primary (federating)
>     vlan where all the common services would reside. In that model
>     devices in a pvlan cannot reach devices in other pvlans and DAD
>     proxy is used to avoid address collisions globally. All multicasts
>     including NS/NA from the primary vlan are effectively flooded but
>     not multicasts originated from the pvlans which are limited to the
>     pvlan and the primary. This is also deployable today and we
>     probably can document how it works and when it makes sense to use it.
>     4) backbone router model: If registered nodes are all on the
>     "southern" side of the backbone routers and classical ND runs over
>     a federating backbone on the "northern" side then NS / NA mcasts
>     can be completely avoided in the southern domain. With the
>     backbone routers acting as proxies, any to any reachability is
>     available for global and ULA unicast addresses.
>
>     In model 1 the subnet can be much smaller than the link. In model
>     2 the subnet is congruent with the link. In the last 2 models, the
>     subnet is larger than the links, IOW we are in multilink subnet space.
>
>     Cheers,
>
>     Pascal
>
>     > From: Efficientnd-dt [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Erik
>     > Nordmark
>     > To: [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2014 11:03:22 -0700

> normal hosts" example, that to me was a multi-link example, was it
Erik,
I think they are quite separate or at least separable.

efficient-nd is an existence proof of a single subnet on a single link 
providing for mixed mode.

A general case of a multi-link subnet requires additional pieces. For 
instance, to handle those in 6lowpan there was a need to provide for 
multi-hop mechanisms in RFC 6775.

I'd like to keep the scope of the DT limited to the case of single-link 
subnets.

While we shouldn't make in any more difficult than in 4861 to have 
proxies and backbone routers, but I don't think we've been asked to make 
that any easier.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2014 11:09:53 -0700

> 1) no ND, a /64 per device. I think John will detail this approach and use cases where that makes sense (including 3G).

Yes.
> 2) Mixed registered node vs. classical nodes (efficient ND). In that model the usage of NS/NA multicast is reduced roughly by the ratio of registered nodes.

#2 assumes that we'd have some explicit registrations. I wouldn't take 
that for granted up front.
> 3) Multiple private (secondary) vlans with a primary (federating) vlan where all the common services would reside. In that model devices in a pvlan cannot reach devices in other pvlans and DAD prox…

We haven't talked about that option. It would be good to understand 
whether it is different than the other techniques that have been 
discussed. From a quick look it appears the same as the split-horizon 
approach with proxy-dad; the router(s) can multicast RA, multicast RS 
will only make it to the router(s), etc.

> 4) backbone router model: If registered nodes are all on the "southern" side of the backbone routers and classical ND runs over a federating backbone on the "northern" side then NS / NA mcasts can…
That seems to be part of a solution to a multi-link subnet, which I 
don't think we need to work on in the DT.

> In model 1 the subnet can be much smaller than the link. In model 2 the subnet is congruent with the link. In the last 2 models, the subnet is larger than the links, IOW we are in multilink subnet…
My take is that in #1 they are congruent - the subnets are picked to 
match the links with one /64 per link.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Mar 2014 18:58:16 +0000

Hello Erik

> > 3) Multiple private (secondary) vlans with a primary (federating) vlan where all
> the common services would reside. In that model devices in a pvlan cannot
> reach devices in other pvlans and DAD proxy is used to avoid address collisions
> globally. All multicasts including NS/NA from the primary vlan are effectively
> flooded but not multicasts originated from the pvlans which are limited to the
> pvlan and the primary. This is also deployable today and we probably can
> document how it works and when it makes sense to use it.
> 
[PT] It is the same, for all I know, and it is what I tried to describe from inside the box.
The private vlan is the way our switches impose the split horizon.
Unsure if it is a generalized terminology. And yes, we do DAD proxy to isolate the customers.

 Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Mar 2014 18:58:17 +0000

> > In model 1 the subnet can be much smaller than the link. In model 2 the subnet
> is congruent with the link. In the last 2 models, the subnet is larger than the links,
> IOW we are in multilink subnet space.

[PT] Depends on the use case and what we call the link, I suspect. Say you have a large shared Ethernet / WiFi fabric, and even multiple ones. The fabric is a single broadcast domain and a transit link. 
It is possible to use the /64 to enable mobility designs across L2 and L3. In that case, broadcast RAs do not carry prefixes, but unicast RAs are tailored to the various devices pretty much like PMIP does.
Unsure if John's model needs to include mobility, but as a side effect it can certainly be achieved. In any fashion, if a link is the SSID and the connected vlan, the prefix is smaller than the link and may even move from link to link.
V6 has certainly multiple interesting facets : )

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Mar 2014 14:49:54 -0700

> It is possible to use the /64 to enable mobility designs across L2 and L3. In that case, broadcast RAs do not carry prefixes, but unicast RAs are tailored to the various devices pretty much like PM…
FWIW the 16ng working group explored that model and decided on the 
simpler approach. See RFC 5121 
<http://datatracker.ietf.org/doc/rfc5121/>  and RFC 4968 
<http://datatracker.ietf.org/doc/rfc4968/>
IEEE 802.16 is capable of treating the physical network as a single 
link, but that is inefficient due to broadcast and multicast, thus 5121 
treats it as independent links each with a /64.

Regards,
    Erik