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

From: [email-masked]
Date: Mon, 05 Sep 2011 09:15:10 -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-03.txt
	Pages           : 26
	Date            : 2011-09-05

   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-03.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-03.txt

---

From: Brian Haley <[email-masked]>
Date: Tue, 06 Sep 2011 09:36:20 -0400

Hi Sri,

> 	Filename        : draft-ietf-netext-logical-interface-support-03.txt

I read this draft and had a comment on Section 6.5:

6.5.  ND Considerations for Logical Interface

   The following are the Neighbor Discovery related considerations for
   the logical interface.

   o  Any Neighbor Discovery messages, such as Router Solicitation,
      Neighbor Solicitation messages that the host sends to a multicast
      destination address of link-local scope such as, all-nodes, all-
      routers, solicited-node multicast group addresses, using either an
      unspecified (::) source address, or a link-local address
      configured on the logical interface will be replicated and
      forwarded on each of the sub-interfaces under that logical
      interface.  However, if the destination address is a unicast
      address and if that target is known to exist on a specific sub-
      interface, the message will be forwarded only on that specific
      sub-interface.

I'm not sure about other OSes, but since you mentioned the Linux bonding driver
as an example of a Logical interface I can respond regarding that.  There are
configurations where you do NOT want to replicate a packet and forward it on all
the underlying physical interfaces.  Doing so can cause DAD failures if any of
the other interfaces see those packets sent to the all-nodes multicast address.
 We noticed and fixed that back in 2008.

BTW, I'm not subscribed to net-next, so haven't seen any previous discussion on
the draft.

-Brian

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 06 Sep 2011 21:09:54 -0700

Hi Brian,

Long time :)

Thanks for the review comment. Please see inline.

>  We noticed and fixed that back in 2008.

Thanks for the info. I'm not sure, if your failure scenario is specific to
logical interface construct, or if you are referring to a general case of
packet replication. For the case of logical interface construct,
essentially, we are presenting a single interface to the host stack, but
underneath there are multiple physical interfaces. Some of the operations
such as router discovery when initiated on the logical interface, should
translate to performing this operation on multiple physical interfaces.

For example, Sending a RS message on a LI abstracting WLAN and WiMAX should
result in sending that RS message on both the paths. I'm sure, this can be
achieved in multiple ways, but the external behavior what needs to be seen
is the generation of two RS packets on those two sub-interfaces. May be if
you can provide more info on your failure case, we can structure this right.
But, that was our intent.

> BTW, I'm not subscribed to net-next, so haven't seen any previous discussion

Will surely help us, if you are on the list.

Regards
Sri

---

From: Brian Haley <[email-masked]>
Date: Wed, 07 Sep 2011 16:36:26 -0400

Hi Sri,

Yes, it's been a while, I tend to only lurk on the MLs these days...

More inline.

> But, that was our intent.

I can understand the abstraction, and why you would want to send some messages
on all the underlying interfaces.

The Linux bonding driver typically isn't used in this way though, it's more of
an HA mechanism to attach a system to a switch, or set of switches, via multiple
paths.  Usually just a group of ports on the top-of-rack switch, for example in
802.3ad mode.  All physical interfaces need to be in the same network.

I've never seen it used where there are multiple types of physical interfaces in
different networks in the bond, not even sure if that's supported...

The failure in question is that in some operating modes you can see broadcasts
sent from other members of the bond (not 802.3ad of course), and that causes
problems, so we create workarounds by trapping them and only transmitting on one
of the interfaces.  That probably isn't going to happen in your scenario.

Maybe the easiest solution is to just remove the Linux reference, I probably
wouldn't have noticed otherwise :)

> Will surely help us, if you are on the list.

I'll try if the bandwidth is low...

-Brian

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 21:57:25 +0000

Following up on Brian's point, the I-D says in Sec 4.1:

"
Depending on the OS support, it might
      be possible to use more than one physical interface at a time --
      so the node is simultaneously attached to different media -- or
      just to provide a fail-over mode.  Controlling the way the
      different media is used (simultaneous, sequential attachment, etc)
      is not trivial and requires additional intelligence and/or
      configuration at the logical interface device driver.  An example
      of this type of solution is the Logical interface, which is
      defined in this document, or the bonding driver (a Linux
      implementation).

"

Do you have examples of implementations wherein a logical interface is
able to use multiple physical interfaces simultaneously?

The multiple-care-of-address solution for MIP6 enables the MN to be
simultaneously attached to an HA via different interfaces. But in such a
model, you have different CoAs associated with those physical interfaces.

-Raj

On 9/7/11 3:36 PM, "ext Brian Haley" <[email-masked]> wrote:

>>> I'm not sure about other OSes, but since you mentioned the Linux
>>>bonding
>>> driver
>>> configurations where you do NOT want to replicate a packet and forward
>>>it on
>>> all
>>> BTW, I'm not subscribed to net-next, so haven't seen any previous
>>>discussion
>>> on
>>> the draft.
>> 
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 07 Sep 2011 16:20:35 -0700

Hi Brian,

Thanks for your response.

> wouldn't have noticed otherwise :)

Thanks for the info about the issue with that usage. I understand what you
are saying. We will try to remove the bonding driver example and leave it
with the requirement, expected external behavior, independent of the
specific approach/OS.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 07 Sep 2011 16:21:13 -0700

Hi Raj:

> able to use multiple physical interfaces simultaneously?

I can think of the Linux bridge control interface, where the physical
interface are put in a bridge mode.

Since you asked :)

http://www.mendeley.com/research/applicability-virtual-interface-intertechno
logy-handoffs-proxy-mobile-ipv6/

> model, you have different CoAs associated with those physical interfaces.

Slight difference though. In the MCoA model, the HoA is bound to virtual
interface, however the tunnel is established from the IP addresses
associated with a physical interface. The relation between the two being the
tunnel providing the routing path for the home address on the virtual
interface.

Regards
Sri

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 16:01:19 +0000

Sri,

Thanks for the reference.
A few questions from the configuration of the MN in the experiment
mentioned in the paper:

1. Are multiple interfaces active at the same time (eth0 and eth1)?

2. How does the bridge interface handle the scenario when you have
multiple interfaces simultaneously active and operational? From a PMIP6
standpoint, does the MN (assuming attachment to different MAGs) obtain
different prefixes from the MAGs?

3. How does SLAAC work when the bridge IF is used? Given that you have
different EUI48s associated with Eth0 and Eth1, what does the br IF use
for address config?

-Raj

---

From: Julien Laganier <[email-masked]>
Date: Thu, 8 Sep 2011 09:04:23 -0700

I thought that we already discussed this and concluded it wasn't appropriate?

6.3.  Supported Link models for a logical interface

   The sub-interfaces of a logical interface can be bound to a point-to-
   point or a shared link (Example: LTE and WLAN).  The logical
   interface appears as a shared-link to the applications, and adapts to
   the link model of the sub-interface for packet communication.  For
   example, when transmitting a packet on a sub-interface which is
   attached to a p2p link, the transmission conforms to the p2p link
   model and when transmitting on a sub-interface attached to a shared
   link, the transmission conforms to the shared link model.

   Based on the link to which the sub-interface is attached to, the
   layer-2 resolutions may or may not be needed.  If the interface is
   bound to a P2P link with PPP running, there will not be any link-
   layer resolutions in the form of ARP/ND messages.  However, if the
   interface is bound to a shared link such as Ethernet, there will be
   ND resolutions.  The logical interface implementation has to maintain
   the required link model and the associated state for each sub-
   interface.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 08 Sep 2011 21:31:18 -0700

Hi Raj:

> 1. Are multiple interfaces active at the same time (eth0 and eth1)?

Yes. Both the scenarios, keeping or both the interfaces active, was tested
by Sawako. 

> different prefixes from the MAGs?

The brctl mode puts the interfaces in a bridge mode. For all practical
purposes the virtual interface that is configured aboves see's both the
prefixes as prefixes hosted on a link associated with that virtual
interface.

> different EUI48s associated with Eth0 and Eth1, what does the br IF use

This is a good question. I remember some discussion on this, now I don't
remember. I have to ask Sawako, what is the identifier that she noticed in
her lab, if its a generated id, or if was of one of the physical interface.
We will check on that.

But, it was tested by a Japanese student under Ryuji, and not by me. So no
short cuts, no vaporware, its real and you should be rest assured, it really
worked like spot less :)

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 08 Sep 2011 21:34:17 -0700

Hi Julien,

I know we discussed about this during the meeting, on wow the logical
interface should appear to the applications. You preferred to not to state
any thing. I was ok with that, I just wanted to check the socket API, and if
there is any API which provides the type (p2p or non-p2p), based on that we
can resolve this. Let me work on this.

Regards
Sri

On 9/8/11 9:04 AM, "Julien Laganier" <[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.
>>

---

From: Julien Laganier <[email-masked]>
Date: Fri, 9 Sep 2011 09:35:34 -0700

We have discussed this extensively during meetings and on list and
this was the proposal on the table:

http://www.ietf.org/mail-archive/web/netext/current/msg01944.html

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 11 Sep 2011 11:16:59 -0700

Yes. There is the proposed text from you. Thanks !

There was also a comment on ND layer considerations when presenting multiple
peers on the other side of the p2p link as a single peer. Else, it should be
fine. 

Regards
Sri

On 9/9/11 9:35 AM, "Julien Laganier" <[email-masked]> wrote:

>>>> http://www.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-sup
>>>> po
>>>> rt-03.txt
>>>> 
>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-logical-interface-supp
>>>> or
>>>> t-03.txt