Subject: [mif-arch-dt] sections 4.3 and 4.4

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 6 Sep 2013 07:10:30 -0400

Hi all,

As mentioned before, Pierrick and I would like to suggest some text for
sections 4.3 and 4.4.

Comments are welcome.

Best regards,

Juan Carlos & Pierrick

4.3.  Connectivity tests

Although some provisioning domains appear to be valid candidates for PVD
selection (e.g. good L2 quality, consistent connection parameters,
etc.), they may provide limited or no connectivity to the desired
network or the Internet. For example, some PVDs provide L3 connectivity
but require the node to authenticate through a web portal to get full
access to the Internet. If the PVD-aware node knows the PVD, it can
perform authentication operations; otherwise, the node may stay with a
limited network connectivity without full knowledge about this.  Hence,
once the node is attached to a PVD, it should check IP connectivity and
trigger PVD reselection if need be. Also, once the node is attached to a
new valid PVD, the end-to-end IP connectivity could be disrupted. A
mechanism is thus needed to check current connectivity and trigger PVD
reselection if necessary.

Usually, the node can perform these tests by trying to reach a dedicated
web server (e.g. connection managers may be able to address this problem
[RFC 6419]). A better solution would be to make the node aware of the
characteristics of the PVD in order to make the appropriate selection.
This could be realized leveraging some 3GPP and IEEE mechanisms, which
allow to expose some of PVD characteristics to the node (e.g. 3GPP
Access Network Discovery and Selection Function (ANDSF) [REF ANDSF],
IEEE 802.11u/ANQP [REF 802.11u]). 

4.4.Relationship to interface management and connection managers

Current devices such as mobile handsets make use of proprietary
mechanisms and custom applications to manage connectivity with multiple
interfaces and multiple PVDs. These mechanisms or applications are
commonly known as connection managers [RFC 6419]. 

Connection managers sometimes rely on policy servers to allow the
PVD-aware node making the PVD selection. They can also make use of
routing guidance from the network (e.g. 3GPP ANDSF [REF ANDSF]).
Although connection managers solve some connectivity problems, they
seldom address the PVD selection in a comprehensive manner. Moreover,
even with proprietary solutions, it is very challenging to present a
coherent behaviour to the end user of the device, as different platforms
present different behaviours even when connected to the same network,
with the same type of interface, and for the same purpose. 

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hui Deng
Sent: Thursday, August 29, 2013 3:36 AM
To: [email-masked]
Subject: [mif-arch-dt] Restart the teleconf

Hello all,
 
We plan to restart our regular biweek teleconf from the September 9th
(Monday) same time
will send out teleconf invitation next week (one week before the
teleconf)
 
Thanks a lot for your attendance.
Best regards,
 
-Hui

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Sep 2013 18:14:47 -0400

This looks fine, although in section 4.3, I would additionally suggest that you advice implementations to not actually enable routing on a PvD until the validation has been done.   The way you have worded it currently seems to interrupt service and then restore it, which is the wrong sequence.   Of course, the argument can also be made that we shouldn't be making recommendations in an architecture document; this stuff might be better worded by identifying the problem and talking about ways it can be addressed in the context of PVDs.

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 08:35:36 +0000

Hi Ted,

Actually, we have described current behavior where terminals do not have simultaneous connection to more than one PVD. This behavior (attach to the PVD, then perform connectivity test) is clearly not what we should advice. Section 4.3 was supposed to  give recommendation: basically, update routing once targeted PVD has been checked and confirmed. Apparently, current text is not clear enough :-), we will revise it accordingly.

Pierrick

-----Message d'origine-----
De : Ted Lemon [mailto:[email-masked]] 
Envoyé : samedi 7 septembre 2013 00:15
À : Zuniga, Juan Carlos
Cc : [email-masked]; SEITE Pierrick IMT/OLN
Objet : Re: [mif-arch-dt] sections 4.3 and 4.4

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Sep 2013 13:41:25 +0000

On Sep 9, 2013, at 4:35 AM, [email-masked] wrote:
> Apparently, current text is not clear enough :-), we will revise it accordingly.

Thanks!   :)

---

From: "Cao Zhen \(CZ\)" <[email-masked]>
Date: Mon, 9 Sep 2013 09:58:36 -0400

<https://ietf.webex.com/ietf/j.php?J=647841441&PW=NMzcwMTY4NmU4> https://ietf.webex.com/ietf/j.php?J=647841441&PW=NMzcwMTY4NmU4

Hui told me to resend the link, in case you missed the meeting request. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hui Deng
Sent: Thursday, August 29, 2013 3:36 AM
To: [email-masked]
Subject: [mif-arch-dt] Restart the teleconf

Hello all,
 
We plan to restart our regular biweek teleconf from the September 9th (Monday) same time
will send out teleconf invitation next week (one week before the teleconf)

-Hui

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 14:02:03 +0000

Hi,

Below is a revision for section 4.3 to address Ted's concern. Feel free to comment.

Br,
Pierrick and Juan-carlos

4.3.  Connectivity tests
 
Although some provisioning domains appear to be valid candidates for PVD selection (e.g. good L2 quality, consistent connection parameters, etc.), they may provide limited or no connectivity to the desired network or the Internet. For example, some PVDs provide L3 connectivity but require the node to authenticate through a web portal to get full access to the Internet. If the PVD-aware node knows the PVD, it can perform authentication operations; otherwise, the node may stay with a limited network connectivity without full knowledge about this situation.  In current implementations, some nodes perform connectivity tests to address this issue, for instance by trying to reach a dedicated web server (e.g. connection managers may be able to address this problem [RFC 6419]). If the node can simultaneously use both the current and new PVDs, it can perform connectivity test and, only after validation of the new PVD, update its forwarding state. Connectivity tests are also required once the node is attached to a new valid PVD. Indeed, during the IP session, the end-to-end IP connectivity could be disrupted for various reasons (e.g. poor L2, IP QoS issue); hence an IP monitoring function is needed to check current IP connectivity and trigger PVD reselection if necessary.
 
Nevertheless, a connectivity test for PVD selection is sometimes not appropriate and should be complemented, or even replaced, by an educated PVD selection. For example, some nodes, especially mobile handsets, cannot use more than one PVD at the same time (even if multiple-PVD attachment is possible). In this case, the connectivity test is done after performing a routing update to the new PVD, and may lead to service interruption if the selected PVD turns out to provide limited IP connectivity. Here comes into play the educated PVD selection, where the idea is to make the node aware of the characteristics of the PVD, prior to attaching to the new PVD. This would avoid selecting a PVD with inappropriate features (e.g. authentication, low quality, etc.). The educated PVD selection could be realized leveraging some 3GPP and IEEE mechanisms, which would allow to expose some PVD characteristics to the node (e.g. 3GPP Access Network Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/ANQP [REF 802.11u]). 

-----Message d'origine-----
De : Ted Lemon [mailto:[email-masked]] 
Envoyé : lundi 9 septembre 2013 15:41
À : SEITE Pierrick IMT/OLN
Cc : Zuniga, Juan Carlos; [email-masked]
Objet : Re: [mif-arch-dt] sections 4.3 and 4.4

Thanks!   :)

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 23 Sep 2013 10:16:39 -0400

Hi Dmtry,

This is text for 4.4:

JC