Re: IPoIB link address

>> >In the IP encapsulation draft , section 6.1.2, it is indicated that the
>> >Q_Key used should be that of the
>> >broadcast-GID. Which broadcast GID should be used? Specifically, if the
>> >IPv4 and IPv6 broadcast GIDs are assigned different Q_keys, which Q_Key
>> >should be used?
>>
>>You should look at the link & multicast draft, not the encapsulation
>>draft for the Q_Key assignment. In that draft Q_Key is described as an
>>IPoIB link attribute shared by both IPv4 and IPv6. (See section 6.2 IPoIB
>>Link Q_Key.)
>
>So what you are saying is that because of what is said in the link & 
>multicast draft, the 2 broadcast
>groups have to have the same link attributes, i.e. the option #1 indicated 
>below is the solution. If this is the case, either draft should at the very 
>least make this requirement explicit.
>
>I would prefer to have a single broadcast group for both IPv4 and IPv6 as I 
>do not understand the rationale behind requiring the IPoIB driver to 
>maintain IP specific information.

Not sure what "IP specific info" you're alluding to. The driver is already
required to know something about L3 in order to demux inbound IPv4, IPv6
and ARP/RARP traffic. IMO a truly L3 agnostic link-layer broadcast group
should've come from IBA. In fact, one such group called "All channel
adapters multicast group" (FF02::1) has been defined by IBA.
Unfortunately it did not take into account the istence of partitions
so it seems pretty useless.

Having different broadcast groups also provide some separation on the
broadcast traffic between v4 and v6. All said, I'm not totally against
a single broadcast group, it'd work too. I'm still in favor of what we
have now simply because that's what we've had for the past couple of
years. Unless something is terribly wrong, why change it?

Again all the above are my personal opinion!

Jerry

>-Vandana
>
>> >
>> >The issue with potentially allowing different Q_Key values for the 2 GIDs
>> >is that 2 separate QPs will have to
>> >be allocated for IPv4 and IPv6 traffic respectively and will require the
>> >IPoIB driver to keep track of upper layer protocols.
>> >If everyone agrees that this is a problem, there are 2 ways to address the
>> >issue:
>> >1) Require the 2 broadcast GIDs to have the same attributes such as Q_key,
>> >MTU etc.
>>
>>See above. Q_Key and MTU are considered "link" attributes. By definition,
>>IPv4 and IPv6 running on top of the same link must use the same set of
>>"link" attributes. If this is not clear from the current drafts we can
>>certainly fix it. (Well Vivek and I are working on combining the two drafts
>>into one. One benefit of the merge is to remove any possible inconsistency.)
>>
>>Thanks for pointing this out,
>>
>>Jerry (speaking obviously as a co-author not a co-chair)
>>
>> >or
>> >2) Create a single broadcast GID to define the link.
>> >
>> >-Vandana
>> >
>> >
>> >
>> >_______________________________________________
>> >IPoverIB mailing list
>> >[email protected]
>> >https://www1.ietf.org/mailman/listinfo/ipoverib
>