Re: [netext] Logical Interface draft

[Daniel Corujo <[e-mail]>]

Dear all,

Please kindly accept my review on this draft.

Overall, I think that it provides a very useful initial description for the topic, but, IMHO, it is really demanding for some added details. Please consider:

1 - The document focuses on PMIPv6. Although it is currently the de-facto mobility management protocol, there are currently other efforts underway, particularly DMM. I am sure that there are a lot of people who would be interested in analysing the impact that the logical interface would have in such architectures (or be impacted by them). As such, not only a specific section addressing other mobility management schemes, but actually shifting PMIPv6 to a specific scenario within this draft, rather than than its focus, would allow the draft to be more informatively broad and future-proof.

2 - In section 3.2.1 it is indicated that “the handover across access points need not to be hidden to the IP layer since the IP layer configuration remains the same after a handover”. However, IP configuration steps are still triggered, such as sending out Router Solicitations and collecting Router Advertisements, in the case of IPv6 Stateless Autoconfiguration. This will impact the terminal, even in intra-technology handovers.

3 - Point 2) in this email also raises an issue which should be interesting to cover in this draft. One can consider that the identified interface to realize PMIPv6 proceedings would be the Logical Interface. However, in a handover situation, how would the mechanism chose through which physical sub-interface the Router Solicitation would be sent? Each sub-interface has a different MAC address and, in the case of IPv6 Stateless Autoconfiguration, the requested suffix would be different. I might be missing something, so please correct me if I am wrong. Nonetheless, this also hints that the scenarios shown in sections 6.1 and 6.2 could use a little bit of more information and detail.

4 - Also in section 3.2.1, in the 2nd paragraph, regarding “the logical interface would not be used to provide simultaneous access for purposes of multihoming or flow mobility”: would it be interesting to consider load balancing or reliability aspects, considering a Single IP Address / Multiple physical interfaces case?

5 - I think that section 4, which is called “Technology Use Cases” should be enhanced with more examples. Basically all the examples indicated in this section have been hinted in text here and there in the previous sections, so it does not explicitly add nothing new.

6 - In section 5, regarding the 1st property of the logical interface, it would be interesting to add a bit more information on how its relationship with the set of physical interfaces is done. Is it just the LIF and FLOW tables?

7 - In section 5.1, regarding the “logical router that in turns decides which physical interface is to be used to transmit packets”, seems to me to be very interesting and could be further extended to encompass rule-based configuration. For example, besides the usual “default” rule, a sequential list, just to name an example.

8 - In section 5.2, the PIF table is mentioned, but Figure 2 addresses the LIF table and FLOW table.

9 - In section 5.2, is it possible to add indication on how the tables can handle several LIF’s? Or each LIF has its own set of tables? If so, whenever packets are received, does the “Connection Manager” need to check each table from each LIF, as per “In case traffic of an existing flow is suddenly received from the network on a different sub-interface than the one locally stored, the logical interface should interprete the event as an explicit flow mobility trigger from the network (…)”. Seems to me that this would cause some performance issues…

10 - In Sections 6.1 and 6.2, as indicated before, more details should be given about each procedure. For example, beyond the LMA’s Binding Table, it would be interesting to see the dynamics of the LIF and FLOW tables before and after the handover. This is important to evaluate the behaviour aspects of the LIF in particular situations as well, such as handovering a flow to an interface that has been connected for sometime. 

11 - The remainder of my comments are just editorial:
 - Abstract, line8, should be “ (…) details of THE logical interface (…) “.
 - Page 3, 3rd paragraph, line 1, there is no need for “network” before “network-based”.
 - Page 3, 3rd paragraph, line 4, suggestion of replacing “afford” with “allow”
 - Page 5, 1st paragraph, line 2, should be “ (…) or movement from THE host IP layer.”
 - Page 5, Section 3.1, 2nd bullet, line 1, should be “ (…) that logically groupS/bondS (…) “
 - Page 8, Section 4, 1st paragraph, line 4, it it really “available devices” or should it be “available accesses” or “available interfaces”?
 - Page 8, Section 4, 3rd paragraph, line 1, should be “ (…) setup is based on THE creation (…) “
 - Page 10, Section 5.1, 2nd paragraph, line 3, should be “ (…) that in turn decides (…) “
 - Page 10, Section 5.2, 1st paragraph, missing “.” after “Figure 2”.

Hope these comments support the draft. Any comments on suggestions are welcome!

Best regards,


Daniel Corujo, Ph.D., Research Fellow
Universidade de Aveiro, Portugal	
http://re.vu/dcorujo
Advanced Telecommunications and Networks Group - http://atnog.av.it.pt
Follow us - @ATNoG_ITAv


On 08 Aug 2014, at 12:07 , [e-mail] wrote:

> Hi,
>  
> I’ve reviewed http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support/and I have no particular issue to raise, just few editorial suggestions (please see below). So, I agree with Danny; this doc is useful and ready for publication.
>  
> BR, Pierrick
>  
>  
> --- OLD ABSTRACT  -------------
> A Logical Interface is a software semantic internal to the host
>    operating system.  This semantic is available in all popular
>    operating systems and is used in various protocol implementations.
>    The Logical Interface support is required on the mobile node
>   operating in a Proxy Mobile IPv6 domain, for leveraging various
>    network-based mobility management features such as inter-technology
>    handoffs, multihoming and flow mobility support.  This document
>    explains the operational details of Logical Interface construct and
>    the specifics on how the link-layer implementations hide the physical
>    interfaces from the IP stack and from the network nodes on the
>    attached access networks.  Furthermore, this document identifies the
>    applicability of this approach to various link-layer technologies and
>    analyzes the issues around it when used in context with various
>    mobility management features.
>  
>  
> -------------  NEW ABSTRACT -------------
>  
> A Logical Interface is a software semantic internal to the host
>    operating system.  This semantic is available in all popular
>    operating systems and, when the terminal is equipped with more than one interface, it can be used to hide the physical interfaces from the IP stack. The logical interface thus allows various
>    network-based mobility management features such as inter-technology
>    handoffs, multihoming and flow mobility support.  This document
>    explains how the Logical Interface hides the physical
>    interfaces from the IP stack and from the network nodes on the
>    attached access networks.  Furthermore, this document identifies the
>    applicability of this approach to various link-layer technologies and
>    analyzes the issues around it when used in context with various
>    mobility management features.
>  
>  
> -          Old text -----------
>  
> Specifically, it explores the use of the Logical Interface support, a
>    semantic available on most operating systems.
>  
>  
> -          New text ----------
> Specifically, it explores the use of the Logical Interface support, available on most operating systems.
>  
>  
>  
> Section 3.1:
>  
> « an 802.11 STA » - please expand STA
>  
> s/ within the same domain/ within the same IP subnet/
>  
> s/ the IEEE 802.11 MAC layer takes care of the mobility/ the IEEE 802.11 MAC layer handles mobility between access points
>  
> s/ A logical interface denotes a mechanism that that logically group/bond several/ A logical interface denotes a mechanism that logically group several
>  
> --------- OLD text ----------
>  
> Depending on the type of
>       access technologies, it might be possible to use more than one
>       physical interface at a time -- such that the node is
>       simultaneously attached via different access technologies -- or
>       just to perform handovers across a variety of physical interfaces.
> .
>  
> Not: It does not depent on the access technology but on the OS and the terminal implementation, so I suggest:
>  
> ----------- NEW text ----------
>  
> Depending on the system, it might be possible to use more than one
>       physical interface at a time -- such that the node is
>       simultaneously attached via different access technologies -- or
>       just to perform handovers across a variety of physical interfaces.
>  
>  
>  
> ------ OLD text ---------
>  
> The configuration is typically
>       handled via a connection manager, and based on a combination of
>       user preferences on one hand, and operator preferences such as
>       those provisionned by the Access Network Discovery and Selection
>       Function (ANDSF) [TS23402] on the other hand.
>  
>  
> -------- NEW text --------
>  
> The configuration is typically
>       handled via a connection manager, and based on a combination of
>       user preferences, application characteristics, quality of communications, operator preferences (e.g. provisioned by the Access Network Discovery and Selection Function (ANDSF) [TS23402]), and so on.
>  
>  
> S/3.2.1 link layer support/link layer mobility support/
>  
> s/ in the same subnet with a common IP layer configuration (DHCP server, default router, etc.)/ in the same IP subnet with a common configuration objects (DHCP server, default gateway, etc.)
>  
> s/ In this case the handover across access points need not to be hidden/ In this case the handover across access points does not need to be hidden  
>  
>  
>  
> Last paragraph of 3.2.1 should be removed since the use-case is covered by 3.2.2. Or rewrite as:
>  
> -+-------- OLD TEXT ---------
> Since this type of link layer technology does not typically allow for
>    simultaneous attachment to different access networks of the same
>    technology, the logical interface would not be used to provide
>    simultaneous access for purposes of multihoming or flow mobility.
>  
> Note: actually, there is no multihoming or flow mobility since there is no more than one simultaneous attachment ;-)
>  
>    Instead, the logical interface can be used to provide inter-access
>    technology handover between this type of link layer technology and
>    another link layer technology, e.g., between IEEE 802.11 and IEEE
>    802.16.
>  
> Note: this covered in the following section section … this is the motivation of the logical interface….
>  
> -          NEW TEXT ----------
>  
> When the access technology does not allow a single interface to be simultaneous attach to more than one IP network (subnet and associated configuration objects), logical interface support is not required.
>  
> -------- OLD TEXT ---------
>  
> Doing so allows to hide inter-access
>    technology handovers or application flow handovers across different
>    physical interfaces.
>  
> --- NEW TEXT ------------
>  
> Doing so allows to hide inter-access
>    technology handovers, or application flow handovers across different
>    physical interfaces, from the IP stack which is by nature tight to a single interface.
>  
> -----------Question ---------------
>  
>  
> Section 4 states:
>  
> In some UE implementations the wireless connection setup is based on
>    creation of a PPP interface between the IP layer and the wireless
>    modem that is configured with the IPCP and IPv6CP protocol [RFC5072].
>    In this case the PPP interface does not have any L2 address assigned.
>    In some other implementations the wireless modem is presented to the
>    IP layer as a virtual Ethernet interface.
>  
>  
> So what? What do you want to stress here?
> -          - - -  ----
>  
>  
> Section 5:
>  
> What do you mean by  “The sub-interfaces attached to a Logical interface are not visible to the IP and upper layers.”
> The node can use either the logical or physical interfaces, I mean, an application can be bound to the LI and another application bound to one of the physical interface available.
>  
>  
>  
>  
> Section 5.1:
>  
> The IP layer should be configured with a default router reachable via the logical interface.
>  
> The IP layer should be also configured with DNS, DHCP server. Right?
>  
> Section 5.2:
>  
> In Fig.2 ::flow table :
>  
> s/ Physical_Intf_Id/PIF_ID
>  
> on section n 6.3: maybe add a reference to the draft netext-flow-mob?
>  
>  
> General comment: In the doc, we find either « Logical Interface », or « logical interface », or « Logical interface »…. Would be better to pick only one of these terms….
>  
>  
> De : netext [mailto:[e-mail]] De la part de Moses, Danny
> Envoyé : jeudi 7 août 2014 17:44
> À : [e-mail]
> Objet : [netext] Logical Interface draft
>  
> Hi,
>  
> In the last meeting there was a discussion about whether or not to publish the 'Logical Interface' draft (http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support/). At the end of the discussion it was agreed that if at least three new reviewers review the draft and state that it is useful, the WG will publish it.
>  
> Well, I reviewed it (and it was the first time for me to read it) and found the draft to be useful as a guide for OS developers (and/or network stack developers) who wish to implement a logical interface for supporting PMIPv6.
>  
> I found the draft to be clear, short and useful and recommend to publish it. I found a few minor typos that should be corrected  and sent my comments to Sri.
>  
> Regards,
>         /Danny
>  
>  
> ---------------------------------------------------------------------
> A member of the Intel Corporation group of companies
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext