Subject: [netext] Logical Interface draft

From: "Moses, Danny" <[email-masked]>
Date: Thu, 7 Aug 2014 15:43:57 +0000

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.

---

From: <[email-masked]>
Date: Fri, 8 Aug 2014 11:07:34 +0000

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:[email-masked]] De la part de Moses, Danny
Envoyé : jeudi 7 août 2014 17:44
À : [email-masked]
Objet : [netext] Logical Interface draft

Hi,

Regards,
        /Danny

_________________________________________________________________________________________________________________________

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: Daniel Corujo <[email-masked]>
Date: Thu, 21 Aug 2014 10:01:14 +0100

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 , [email-masked] 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
>  
>  
> Note: this covered in the following section section … this is the motivation of the logical interface….
>  
> -          NEW TEXT ----------
>  
> What do you mean by  “The sub-interfaces attached to a Logical interface are not visible to the IP and upper layers.”
> 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….
>  
>  
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 27 Aug 2014 05:47:38 +0000

Hi Daniel,

Apologies for the delay in responding to this thread.

Thanks for the detailed review feedback. We will review and respond to
these comments.

Regards
Sri

Thanks a lot 

On 8/21/14 2:01 AM, "Daniel Corujo" <[email-masked]> wrote:

>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.
>
>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.
>
> - 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².
>
>> I¹ve reviewed 
>>http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-suppo
>>rt/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
>>  
>>  
>>    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
>> 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
>>  
>>       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/ 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  
>>  
>>  
>>  
>> Note: actually, there is no multihoming or flow mobility since there is
>>no more than one simultaneous attachment ;-)
>>  
>> 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.
>>  
>> 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:
>>  
>> 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Š.
>>  
>>  
>> 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-supp
>>ort/). 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
>>  
>>  
>>_________________________________________________________________________
>>________________________________________________
>> 
>> 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,
>> This message and its attachments may contain confidential or privileged
>>information that may be protected by law;

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 27 Aug 2014 05:49:31 +0000

Hi Danny/Pierrick,

Thanks  for the reviews. We will address your comments.

Regards
Sri

From: <Moses>, Danny <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 7, 2014 8:43 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netext] Logical Interface draft

Hi,

Regards,
        /Danny