Re: IPoIB link address

At 11:26 PM 9/22/2003 -0700, H.K. Jerry Chu wrote:
> >> >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

Not all implementations have this requirement. For e.g. in the DLPI 
environment, the DLPI layer protects the interface
drivers from having to demux on the basis of IP protocols.

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

Agreed.

>Having different broadcast groups also provide some separation on the
>broadcast traffic between v4 and v6. All said, I'm not totally against

I do not see how this separation is provided as in the generic case, all 
nodes will register for
both the broadcast groups; so, the fabric will have 2 multicast groups 
setup which will be exactly the same.
The only separation that I can see is potentially segregating the 2 
broadcast traffic onto different QPs. But the added complexity of the 
driver having to track this is not necessary.

-Vandana

>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
> >