Re: IPoIB link address

"H.K. Jerry Chu" wrote:
> 
> <snip>
> 
> (co-chair hat off!)
> 
> >>a) make it a requirement that the broadcast-GID won't be torn down unless
> >>the link is torn down.
> >>
> >>
> >>This is somewhat circular since we define the link using the broadcast-GID.
> >>Additonally, the admin will have to find some method to know that the link
> >>can be brought down.
> >>
> >>b) Always have to full-member join broadcast-GID.
> >>
> >>Now, the admin will always know if someone is using the link and can do a
> >>managed shutdown.
> >>
> >>
> >>c) Always derive the data from the broadcast-GID and track it either by
> >>full-member joining or reports.
> >>
> >>Now, the admin can delete/modify as needed. the nodes will respond
> >>accordingly.
> >>
> >
> >I would prefer (c) too. This allows a deployment to not have any admin
> >involvement if necessary. Again, as I said before, if the implementation
> >decides to join full-member, there is no issue.
> 

Hi,


> Not sure I understand what exactly c) is. It refers to v6 only so v4 MUST
> always join the broadcast group, right?
> 

Isn't it true that in limited v4 configurations, you can use static ARP
tables on the hosts to eliminate broadcast traffic? If you want to optimally
support this, I think even the requirement to JOIN for v4 has to be
rethought.

I think whatever decision we take (MUST JOIN, should JOIN, MUST JOIN or
MUST track) can apply to both v4 and v6.

Thanks.

Kanoj


> I prefer not to require v6 to join the broadcast group. This is compatible
> with c). But I prefer to continue to leave the creation/maintainence of
> the broadcast group out of scope because the broadcast group should really
> be managed together with the IPoIB link as part of the fabric management
> function. (Note that this doesn't necessarily imply admin involvement.
> If implementations can somehow find a way to embed this function in IPoIB
> drivers that is fine too.) If we start getting into problems that really
> belong to fabric management, we may never find a bullet-proof solution within
> IPoIB itself. E.g., if we don't require the continuous existence of the
> broadcast group as part of the IPoIB link, but we merely rely on IP nodes
> joining so the broadcast group won't go away, what happen if for some reason
> all the IP nodes went down, and the broadcast group got deleted as a result
> of zero member. On a subsequent boot, what should IPoIB driver do? Create
> the broadcast group? But how would the driver know what link attributes
> to use? Implementations may supply link attributes to the IPoIB driver
> through some implementation-specific mechanism. But we can't make this a
> requirement in IPoIB spec, right?
> 
> Similarly link attributes shouldn't be modified without some coordination
> between fabric mgmt and IP software and that coordination shouldn't be part
> of IPoIB spec just like IP over Ethernet doesn't talk about how to cope
> with VLAN reconfiguration or changes in VLAN properties.
> 
> So my preference remains to be a).
> 
> Jerry
> 
> >-Vandana
> >
> >>We can avoid going into the details in the specification since the details
> >>listed above are largely informational. However, I believe that the case
> >>of 'no-broadcast GID' needs to be specified. Is it not similar to the case
> >>of a downed interface?
> >>
> >>
> >>
> >>My preference is for (c).
> >>
> >>Vivek
> >>
> >>
> >>
> >>Vivek
> >>
> >> >
> >> > Jerry
> >> >
> >> > >
> >> > >-Vandana
> >> > >
> >> > >
> >> > >_______________________________________________
> >> > >IPoverIB mailing list
> >> > >[email protected]
> >> > >https://www1.ietf.org/mailman/listinfo/ipoverib
> >> >
> >> >
> >> > _______________________________________________
> >> > IPoverIB mailing list
> >> > [email protected]
> >> > https://www1.ietf.org/mailman/listinfo/ipoverib
> >> >
> >> >
> >>
> >>__
> >>
> >>Vivek Kashyap
> >>Linux Technology Center, IBM
> >
> 
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib