Subject: [mif-arch-dt] Determination & Naming

From: Margaret Wasserman <[email-masked]>
Date: Tue, 14 May 2013 03:27:02 -0400

How does a node determine/detect that it is attached to multiple PVDs?

How are PVDs enumerated and/or named?

Are PVDs globally defined/named, or do they exist only from the perspective of each MPVD node?

---

From: Dave Thaler <[email-masked]>
Date: Tue, 14 May 2013 19:50:45 +0000

Not to answer the question, but to provide some related information...

PVDs are related to, but not the same as, a "site" in the RFC 4007 sense.
That is, if you have two sites, I'd expect them to be different PVDs.
Different PVDs don't imply different sites though, since we've already said you could have two PVDs reachable via the same interface.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaret Wasserman
Sent: Tuesday, May 14, 2013 12:27 AM
To: [email-masked]
Subject: [mif-arch-dt] Determination & Naming

_______________________________________________
mif-arch-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif-arch-dt

---

From: Hui Deng <[email-masked]>
Date: Fri, 24 May 2013 15:19:32 +0800

I thought context in the host will be merged,  do we still need enumerate the PvDs? for the purpose of user to pick?
PvD or PvD ID may only be used by user who decide which one to pick?
 
> From: [email-masked]
> Date: Tue, 14 May 2013 03:27:02 -0400
> To: [email-masked]

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 28 May 2013 04:27:36 +0000

Apologies if you get a copy of the below email twice - due to some reason it didn't make it to the list first time, trying to re-send.

>>> How does a node determine/detect that it is attached to multiple PVDs?
If the host has not received explicit information about the connected PVDs on a particular interface, it should assume the set of configuration on that interface is in a separate PVD.

If the host received explicit information (such as e.g. DHCP server responded with a new DHCP option, defining a PVD), then the host associates some / all of the interface config (depending on the received explicit information from e.g. DHCP and/or other sources) with the explicitly learned PVD(s).

>>How are PVDs enumerated and/or named?

PVDs are named: if no explicit information received, the host assigns a locally unique ID to the PVD on each interface. Where explicit information is received, PVD ID is received as part of that information (either human-readable, or globally unique ID, or both). Depending on the host implementation, enumeration is something the host can do after learning the PVDs - the host stack could do implicitly during e.g. Connect calls, and/or could expose APIs for "Einstein" apps to be aware of the multiple available PVDs and their configuration elements and other properties.

>>> Are PVDs globally defined/named, or do they exist only from the perspective of each MPVD node?

Explicitly configured PVDs are globally defined/named. Implicitly configured PVDs exist only from the perspective of the MPVD node.

>>I thought context in the host will be merged,  do we still need enumerate the PvDs?

I think the particular choice of host behavior (enumeration vs merging) is out of scope, though as a more general case, behavior of enumeration should be allowed and implementable, and can be used as a reference conceptual model in the arch document.

>>for the purpose of user to pick?

IDs could be used for different purposes. To name a few: a) to pick by user, b) to use per policy configured on the host for particular purpose (e.g. download video from MO servers, download MMS, perform Wi-Fi traffic offload) c) merge elements from the same PVD available on different interfaces.

-Dmitry

________________________________
From: [email-masked] on behalf of Hui Deng
Sent: Friday, May 24, 2013 12:19 AM
To: [email-masked]; [email-masked]
Subject: Re: [mif-arch-dt] Determination & Naming

---

From: Hui Deng <[email-masked]>
Date: Tue, 28 May 2013 15:00:26 +0800

I am fine with this proposal, to have PVD, PVD ID or local PVD ID.
 
-Hui
 
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mif-arch-dt] Determination & Naming
Date: Mon, 27 May 2013 22:25:00 +0000

If the host received explicit information (such as e.g. DHCP server responded with a new DHCP option, defining a PVD), then the host associates some / all of the interface config (depending on the received explicit information from e.g. DHCP
 and/or other sources) with the explicitly learned PVD(s).
 
>>How are PVDs enumerated and/or named?
 
PVDs are named: if no explicit information received, the host assigns a locally unique ID to the PVD on each interface. Where explicit information is received, PVD ID is received as part of that information (either human-readable, or globally
 unique ID, or both). Depending on the host implementation, enumeration is something the host can do after learning the PVDs - the host stack could do implicitly during e.g. Connect calls, and/or could expose APIs for "Einstein" apps to be aware of the multiple
 available PVDs and their configuration elements and other properties. 

 
>>I thought context in the host will be merged,  do we still need enumerate the PvDs?
 
I think the particular choice of host behavior (enumeration vs merging) is out of scope, though as a more general case, behavior of enumeration should be allowed and implementable, and can be used as a reference conceptual model in the arch
 document.

 
IDs could be used for different purposes. To name a few: a) to pick by user, b) to use per policy configured on the host for particular purpose (e.g. download video from MO servers, download MMS, perform Wi-Fi traffic offload) c) merge elements
 from the same PVD available on different interfaces.
 
-Dmitry

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 27 May 2013 22:25:00 +0000

-Dmitry

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 May 2013 17:28:33 +0000

On May 27, 2013, at 6:25 PM, Dmitry Anipko <[email-masked]<mailto:[email-masked]>> wrote:
IDs could be used for different purposes. To name a few: a) to pick by user, b) to use per policy configured on the host for particular purpose (e.g. download video from MO servers, download MMS, perform Wi-Fi traffic offload) c) merge elements from the same PVD available on different interfaces.

It may be worth noting that in some cases it would be useful for a user to be able to say "this prefix belongs to this PvD and this other prefix belongs to this other PvD" in cases where there are multiple prefixes and no explicit PvD.   This would be sort of equivalent to configuring something manually that would normally be configured via DHCP.