Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

[Dmitry Anipko <[e-mail]>]

Hi Tim,

Thank you for review and comments. They were discussed during the call on Monday, and I will try to summarize below my understanding of what was agreed on during the call. Please let me know whether you agree/disagree with the proposed changes/actions or if it appears the comment was not understood correctly.

>> If we talk of common scenarios, should we list them? Should we pick a couple that can be drilled into as examples later in the document, or in an Appendix? We had some discussion on this previously in the calls, but did we agree, what if anything, should go in this text?

[d.a.] People felt we should not duplicate the scenarios between the problem statement document and architecture. A text referring to detail scenarios in the problem statement will be added.

>> This explains how the PVD architecture can be incrementally deployed, with incremental benefit, which is a nice property - perhaps the title of that section can be tweaked, or the topic of implicit vs explicit PVD discovery separated?

[d.a.] Ok, will try to do that.

>> Towards the end of section 2.1 it would be great to have heuristics to do better than putting all implicit PVD information into one bucket, e.g. where a host is multihomed, where in such a case the host would have some idea of this due to multiple global prefixes.

[d.a.] There seemed to be agreement that it's not the main goal of the architecture to magically improve without explicit PVDs how such multi-homing on single link works; and that there may be no clear way how to do that, actually. That said, Suresh said that he will suggest some text on this, and this issue may be a good topic to discuss in the MIF meeting.

>> Are PVD IDs unique per PVD, per association between the client and PVD, per location, or...? e.g. if I am with a WiFi provider, will I always see the same PVD when I use that provider, anywhere? Would a friend on that provider see the same ID? Can any assumptions be made? As yet I don't think this is stated.

[d.a.] It seemed at least two question are raised here: 1) whether the PVD ID should be the same or different across networks, operated by the same provider. 2) whether everyone on the same link should see same set of PVDs, or on the same link different nodes might see different PVDs. 

On the call, there seemed to be agreement:

For 1), that both are possible and that the architecture shall not constraint either way. 
For 2), that in the current scope of the document on a single link, all nodes should receive information about the same PVDs. That said, individual nodes may have different policy/trust settings, based on which they decide to use different subsets of the received PVDs. Future extensions, where different nodes on the same link may see different PVDs from the network, are suggested to be out of scope for the current version of the architecture.

The clarifications for both points will be added.

>> The single PVD for dual-stack networks seems very sane. It is common today for a dual-stack host to get an IPv6 address and router via IPv6 RA, and other configuration information via IPv4 DHCP.

[d.a.] OK, I can add that as additional rationale.

>> So if there is an explicit vs implicit distinction for learning PVDs, perhaps a similar model should be applied here, explicit being e.g. a user toggle (explicit choice, rather like 3G vs WiFi, as hinted at in section 2.3), the implicit being e.g. connectivity tests (Happy PVDs?).

[d.a.] It didn't feel like there was a common understanding of how this comment could be actioned on. Please feel free to elaborate or suggest specific text which you'd want to see in the document in this regard.

>> A host may pick multiple PVDs intentionally to use MPTCP; it may explicitly want to ensure it is using different channels per path.

[d.a.] Good point, folks agreed to add text that for some transports and depending on PVD information, node may decide to use connections over multiple paths / PVDs (however for each connection, the operations still need to be done consistently within the particular PVD).

>> There may be cases for split PVDs, e.g. a host with VPN running, uses the VPN to the corporate network and the default provision for all other traffic (cue security comments...).

[d.a.] Sure, this seems to be one of the PVD use cases for different connections, but it was not clear how the text should be adjusted. Do you think the current text doesn't cover that or contradicts to that? If that's the case, can you suggest the specific changes?

>> Perhaps in addition to connection requests by applications the applications will first do DNS lookups, which is where the PVD selection is first used?

[d.a.] Sure, I will add specific text about name lookup, as a possible step where selection is done (it may be not necessarily the first step, however - because e.g. PVD selection could be done based on app identity).

>> eduroam is an interesting example here. Users authenticate to their home site using their home credentials, but the visited site then makes a provisioning (and authorisation) decision based on that result.  The visited site is the PVD, but the authentication is to the home site.  The authentication to eduroam can be mutual between the device and the visited network.

[d.a.] Can you suggest more specific text which you'd like to see included?

>>And a final question for now - are we including application configuration in this work, or is it purely network services?

[d.a.] There didn't seem to be agreement on the call on this, and this was also discussed on previous calls. It may be good topic to talk about in the MIF meeting.

-Dmitry

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Tim Chown
Sent: Monday, July 22, 2013 5:57 AM
To: [e-mail]
Subject: Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt

Hi,

Some quick comments, as I won't now be able to make the call today.

Overall, the draft is taking shape nicely.

Section 1

If we talk of common scenarios, should we list them? Should we pick a couple that can be drilled into as examples later in the document, or in an Appendix? We had some discussion on this previously in the calls, but did we agree, what if anything, should go in this text?

Section 2.1 

This explains how the PVD architecture can be incrementally deployed, with incremental benefit, which is a nice property - perhaps the title of that section can be tweaked, or the topic of implicit vs explicit PVD discovery separated?

Towards the end of section 2.1 it would be great to have heuristics to do better than putting all implicit PVD information into one bucket, e.g. where a host is multihomed, where in such a case the host would have some idea of this due to multiple global prefixes.

Section 2.3

Are PVD IDs unique per PVD, per association between the client and PVD, per location, or...? e.g. if I am with a WiFi provider, will I always see the same PVD when I use that provider, anywhere? Would a friend on that provider see the same ID? Can any assumptions be made? As yet I don't think this is stated.

Section 2.4

The single PVD for dual-stack networks seems very sane. It is common today for a dual-stack host to get an IPv6 address and router via IPv6 RA, and other configuration information via IPv4 DHCP.

Section 4.2

So if there is an explicit vs implicit distinction for learning PVDs, perhaps a similar model should be applied here, explicit being e.g. a user toggle (explicit choice, rather like 3G vs WiFi, as hinted at in section 2.3), the implicit being e.g. connectivity tests (Happy PVDs?).

Section 4.2.1

A host may pick multiple PVDs intentionally to use MPTCP; it may explicitly want to ensure it is using different channels per path.

There may be cases for split PVDs, e.g. a host with VPN running, uses the VPN to the corporate network and the default provision for all other traffic (cue security comments...).

Section 5.1

Perhaps in addition to connection requests by applications the applications will first do DNS lookups, which is where the PVD selection is first used?

Section 6

eduroam is an interesting example here. Users authenticate to their home site using their home credentials, but the visited site then makes a provisioning (and authorisation) decision based on that result.  The visited site is the PVD, but the authentication is to the home site.  The authentication to eduroam can be mutual between the device and the visited network.

And a final question for now - are we including application configuration in this work, or is it purely network services?

Tim

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