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

[Brian Haley <[e-mail]>]

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