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

[<[e-mail]>]

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

>Hi Sri,
>
>Yes, it's been a while, I tend to only lurk on the MLs these days...
>
>More inline.
>
>On 09/07/2011 12:09 AM, Sri Gundavelli wrote:
>> Hi Brian,
>> 
>> Long time :)
>> 
>> Thanks for the review comment. Please see inline.
>> 
>> 
>> 
>> On 9/6/11 6:36 AM, "Brian Haley" <[e-mail]> wrote:
>> 
>>> Hi Sri,
>> 
>>> 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.
>>>
>> 
>> 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.
>
>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 :)
>
>>> BTW, I'm not subscribed to net-next, so haven't seen any previous
>>>discussion
>>> on
>>> the draft.
>> 
>> Will surely help us, if you are on the list.
>
>I'll try if the bandwidth is low...
>
>-Brian
>_______________________________________________
>netext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/netext