Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-05.txt

From: [email-masked]
Date: Sun, 29 Apr 2012 01:40:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF.

	Title           : Logical Interface Support for multi-mode IP Hosts
	Author(s)       : Telemaco Melia
                          Sri Gundavelli
	Filename        : draft-ietf-netext-logical-interface-support-05.txt
	Pages           : 25
	Date            : 2012-04-29

   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-support-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-support-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support/

---

From: <[email-masked]>
Date: Mon, 30 Apr 2012 19:32:46 +0000

Hello,

The authors have revised the I-D and addressed concerns that have been
previously raised. 
We (chairs) would like WG members to review the I-D and provide feedback
via the mailing list.

Please make an effort and do a review of this I-D.

-Chairs

On 4/29/12 3:40 AM, "ext [email-masked]"
<[email-masked]> wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the Network-Based Mobility
>Extensions Working Group of the IETF.
>
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: Peter McCann <[email-masked]>
Date: Mon, 30 Apr 2012 20:51:45 +0000

I see the additional discussion of multiple provisioning domains in Section 5.6,
but I am still not completely happy.  The text seems to imply that all physical
interfaces belonging to a single logical interface MUST belong to the same
provisioning domain.  While this might be true for some types of handovers,
I think it is possible for a particular interface to be part of a different
provisioning domain at other times.  For example, I don't want my WiFi hardware
to be always tied up with my 3G interface.  There are times when I want to 
use my WiFi interface to connect to a network other than my 3G provider.

You say in another place that physical interfaces can be added/deleted dynamically
from the logical interface, but how do you know when you should do that?  Can
you look at router advertisements or something and tell when you are in the
same provisioning domain and when you are not?  I think some more discussion
on this topic is warranted.

-Pete

[email-masked] wrote:
> We (chairs) would like WG members to review the I-D and provide
> feedback via the mailing list.
> 
>> 	Filename        : draft-ietf-netext-logical-interface-support- 05.txt
>> 	Pages           : 25 	Date            : 2012-04-29
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-
>> interface -su pport-05.txt
>> 
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-
>> interface- sup port-05.txt
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-
>> su ppo rt/
>>

---

From: Julien Laganier <[email-masked]>
Date: Mon, 30 Apr 2012 16:29:41 -0700

> Please make an effort and do a review of this I-D.

I have reviewed this document and IMHO the document is focused too
much on one implementation strategy, i.e., that of a stub logical
interface not connected to any link, layered on top of physical
interfaces, at the expense of describing a generic abstract model of a
logical interface that can be implemented in many manners. In doing
so, the document unnecessarily restrict the applicability of the
logical interface concept and describes workarounds that seem overly
complex and unnecessary. For example, the concept of virtual
identifier seems to prevent doing inter technology handovers.

   o  In access architectures, where the link-layer identifier is
      associated with a specific access technology, it will not be
      possible for the logical interface to adopt a virtual identifier
      and it use it across different access networks.  In such networks,
      the logical interface must use the identifier of the respective
      sub-interface through which a packet is being transmitted.
      However, if more than one access technology domains that are part
      of the logical interface have such requirement, then the logical
      interface will not be able to support such configuration.

It seems to me that much of the issues revolving around link layer
identifiers, MTU, Neighbor Discovery, and Multicast, could be avoided
if the document eliminated the current dependency on the
implementation strategy being described in favor of a comprehensive
logical interface support, where the logical interface is attached to
a logical link which is terminated by a logical router. This logical
router would in turn be attached to the physical interfaces themselves
and perform adequate routing.

Doing so, the IP layer on the host runs unmodified and uses the
logical interface as any other interface. ND/ARP/DHCP etc. are
executed together with the logical router at the end of the logical
link, so is multicast. Dissimilar MTU of physical interfaces are
hidden behind the logical router as well...

Unlike the approach currently described in the document, I see only
advantages and no drawbacks to what I am proposing here.

Also note that this model is currently implemented and shipping on
many mobile devices, where two flavors of the model coexist; one where
the logical link is PPP, and another where it is Ethernet-like.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 30 Apr 2012 17:25:14 -0700

Hi Pete,

Thanks. Let me see how to best address the issue related to your concern. 

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 30 Apr 2012 17:25:18 -0700

Hi Julien.

Thanks for the comments. Inline ...

> identifier seems to prevent doing inter technology handovers.

Not sure, if that was our goal, but if any part of the text is focussed on a specific approach, we have to fix that.  Logical interface is a software construct with certain expected behavior with respect to its interfacing with the physical link, ND traffic handling, and with respect to how the messages/events are forwarded up the stack. Clearly this is a requirement spec with some minimal guidance on how to deal with specific issues. The focus was mainly on:

- The concept of a Logical Interface and the purpose
- properties of the Logical interface, its related to the physical interfaces
- How does logical interface deal with link specific ND messages, how RA's are seen, how RS is sent. L2 identifiers ...
- Presents only the details/issues that the implementations have to be aware off.

As I see it, if I'm implementing a logical interface, I need to know these details.  Now, there can be multiple ways to implement and meet these requirements. No part of the spec is using 2119 language, or suggesting how to implement it. Its some general guidance.

> and perform adequate routing.

The above text is about a specific issue related to choice of interface identifier selection. If WiMAX access is making certain assumption about the interface identifier, a given implementation needs to be sensitive to that aspect. So, we are only reflecting the issues with the interface identifier selection and the considerations. So, I'm not sure, if the above is about a specific implementation. The spec can be silent about this, but implementations will have no clue. At the end of the day, this is an informational spec, you and me/WG having worked on such things we have some understanding about the issues. But, some developer may not be aware of these considerations. 

>  This logical
> hidden behind the logical router as well…
> 

One can surely make this a logical router ( I don't know how this works ..), still taking into account the considerations listed in the document. Not sure, what part of the spec is preventing any specific implementation, still conforming to the logical interface requirements.

> the logical link is PPP, and another where it is Ethernet-like.

I agree with that.  But, you also know, in the absence of some guidance how different implementations have violated some basics and the current situation with the 3G drivers. But, I again, we are not interested in reflecting any specific implementation, the goal is to provide requirements.

Sri