Re: [netext] Logical Interface draft

["Sri Gundavelli (sgundave)" <[e-mail]>]

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" <[e-mail]> wrote:

>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-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
>>  
>>  
>> --- 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-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
>>  
>>  
>> ---------------------------------------------------------------------
>> 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
>
>_______________________________________________
>netext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/netext