Re: [Int-area] Comments on current MPvD draft.

["Eric Vyncke (evyncke)" <[e-mail]>]

This could be an alternative but I can only imagine the pile of changes to be done... RA-guard, RFC 4890, ...

In either alternative (different link-local group, different ND code), we HAVE to ensure whether it is doable with the existing HW/SW in the routers/switches/AP... I am afraid that this is more complex to change the network/routers than the end-points (thinking about OS/HW refresh cycle) but I can, obviously, be wrong on this statement.

-éric

From: Ted Lemon <[e-mail]>
Date: Wednesday 15 November 2017 at 17:05
To: Eric Vyncke <[e-mail]>
Cc: int-area <[e-mail]>
Subject: Re: [Int-area] Comments on current MPvD draft.

Size constraints seem like a good thing. Might keep people from sending search lists. Is there a reason not to just define a new packet type, instead of requiring the use of an additional multicast listener?

On Nov 15, 2017 16:32, "Eric Vyncke (evyncke)" <[e-mail]<mailto:[e-mail]>> wrote:
Ted,

For the benefit of the WG members that were not at the WG meeting, let me thank you again for your interest and your comments on the -00.

The authors have already discussed about your points and other similar ones. We have two potential approaches to fix this short-term issue:

-          PvD containers where PIO, RDNSS, ... options are inside the container so those options will be ignored by non PvD aware hosts

-          Sending PvD RA not to ff02::1 but to a different link-local multicast group, PvD aware hosts must process RA received via ff02::1 and this new group

I personally prefer the later as the former creates a 'complex' encoding that will stay forever to solve a short-term issue (non PvD aware hosts). It also puts a size-constraint on the PvD as RA cannot be fragmented.

Expect more discussions/proposals on the list on this topic

-éric

From: Int-area <[e-mail]<mailto:[e-mail]>> on behalf of Ted Lemon <[e-mail]<mailto:[e-mail]>>
Date: Wednesday 15 November 2017 at 14:52
To: int-area <[e-mail]<mailto:[e-mail]>>
Subject: [Int-area] Comments on current MPvD draft.

I'd like to have a bit of discussion today on the architectural choices in the current draft, if possible.

There are two issues I want to discuss:

  1.  The assumption that each PvD will have its own router
  2.  The expected behavior of hosts that do not support MPvD in the presence of multiple routers

The first assumption is problematic in the sense that in most cases (I think), it will actually be the case that the multiple provisioning domains will both be on the other side of a leaf router from the host that is accessing them.   In this case, requiring multiple RAs with different link-local addresses is fairly heavyweight.

The second issue isn't, strictly speaking, an MPvD problem, but I think it implicates MPvD because I think the behavior in this case is undefined.   E.g., if both routers advertise a set of name servers, what does the host do?

We've been looking at this in Homenet, and this came up as a serious concern: if the host chooses one set of name servers, it may not be able to access services in the other PvD.  And yet if the host does support MPvD, we kind of want it to use different name servers per PvD.   So what we concluded is that we want to be able to give hosts that do not support MPvD a clear answer that is different than the answer we give out for each PvD.

This would not be possible with the current proposal.   It's not a hard problem to solve, but we need to consider whether or not, and how, to solve it.