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

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Nov 2017 14:52:27 +0800

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:
The assumption that each PvD will have its own router
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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 15 Nov 2017 08:32:24 +0000

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 <[email-masked]> on behalf of Ted Lemon <[email-masked]>
Date: Wednesday 15 November 2017 at 14:52
To: int-area <[email-masked]>
Subject: [Int-area] Comments on current MPvD draft.

  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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Nov 2017 17:05:29 +0800

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)" <[email-masked]> 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.
>
>
>
> *From: *Int-area <[email-masked]> on behalf of Ted Lemon <
> [email-masked]>
> *Date: *Wednesday 15 November 2017 at 14:52
> *To: *int-area <[email-masked]>
> *Subject: *[Int-area] Comments on current MPvD draft.
>
>
>
> 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.
>
>
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 15 Nov 2017 12:00:46 +0100 (CET)

> The assumption that each PvD will have its own router

I don't think this is the case? It's just that each PVD is in its own RA, 
it doesn't mean one router can't send multiple RAs, one per PVD? That's at 
least my understanding.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Marcus Keane <[email-masked]>
Date: Wed, 15 Nov 2017 11:10:42 +0000

Hi Mikael,

That's correct. One router could send multiple RAs, each one from a different LLA(with each one containing a different PvD). This different LLA technique is suggested in the pa multihoming draft:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-enterprise-pa-multihoming/

Cheers,
Marcus

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Mikael
> Abrahamsson
> Sent: 15 November 2017 11:01
> To: Ted Lemon <[email-masked]>
> Cc: int-area <[email-masked]>
> Subject: Re: [Int-area] Comments on current MPvD draft.
> 
> I don't think this is the case? It's just that each PVD is in its own RA, it doesn't
> mean one router can't send multiple RAs, one per PVD? That's at least my
> understanding.
> 
> --
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fint-
> area&data=02%7C01%7Cmarcus.keane%40microsoft.com%7Cd387dc38afba4
> 60284c508d52c182564%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
> C636463404586240619&sdata=DWKSLHSV7zkvk3ixDkMFnM6BxIy89n%2B4ZP
> NhQjL7Dxc%3D&reserved=0

---

From: Tim Chown <[email-masked]>
Date: Wed, 15 Nov 2017 11:33:59 +0000

> On 15 Nov 2017, at 11:00, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I don't think this is the case? It's just that each PVD is in its own RA, it doesn't mean one router can't send multiple RAs, one per PVD? That's at least my understanding.

I’d made that (wrong?) assumption too.

Tim

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 15 Nov 2017 20:13:42 +0800

> On Nov 15, 2017, at 7:33 PM, Tim Chown <[email-masked]> wrote:
> 

The design is that one router would send multiple RAs, one for each PvD. If there are multiple routers, then each could be sending one or more RAs as well.

Best,
Tommy

> https://www.ietf.org/mailman/listinfo/int-area

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 15 Nov 2017 16:03:25 +0000

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 <[email-masked]>
Date: Wednesday 15 November 2017 at 17:05
To: Eric Vyncke <[email-masked]>
Cc: int-area <[email-masked]>
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)" <[email-masked]<mailto:[email-masked]>> wrote:
Ted,

-éric

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Nov 2017 05:07:26 +0800

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

Wouldn't these changes be required as well if you used a different multicast address?

> 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 com…

Yes.   So this is once again arguing for the encapsulation solution.

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 16 Nov 2017 05:24:17 +0800

> Le 16 nov. 2017 à 05:07, Ted Lemon <[email-masked]> a écrit :
> 

RA-guard (RFC6105) doesn't mention the destination address as a way to identify RAs.
It makes sense since both unicast and multicast RAs must be filtered.
Please tell if you know about implementations behaving differently.

- Pierre