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

[Ted Lemon <[e-mail]>]

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]> 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]> on behalf of Ted Lemon <
> [e-mail]>
> *Date: *Wednesday 15 November 2017 at 14:52
> *To: *int-area <[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.
>
>
>
>