Re: IPoIB link address

Hi Vivek,

At 09:59 AM 10/2/2003 -0700, Vivek Kashyap wrote:
>On Thu, 2 Oct 2003, H.K. Jerry Chu wrote:
>
> > <snip>
> >
> > >> Not sure I understand what exactly c) is. It refers to v6 only so v4 
> MUST
> > >> always join the broadcast group, right?
> > >
> > >The suggestion is in general for an IPoIB link. The link attributes are
> > >derived from the IPoIB broadcast-GID. In the case of v4 it just so happens
> > >that IP broadcast maps to this and so a node will surely join it. We have
> > >earlier always talked of full-join since the node will send and receive
> > >packets on the broadcast GID. However, with the notion that one need not
> > >join the broadcast GID I believe we need to, irrespective of the IP layer,
> > >state that :
> >
> > I am confused. What is the notion that "one need not join the broadcast
> > GID" for v4? There isn't any leeway for v4 - it must join the broadcast
> > group for ARP to work.
>
>Jerry, I think we are all confused :).
>
>
>Join is of three types: Full member, Nonmember, Sendonlynonmember.
>
>
>As far as I know one will have to join (implying one of the above three) to
>retrieve the multicast information. In the case of v4, for the broadcast-GID
>one will have to either full-member join or non-member join. Both allow for
>sends and receives except the latter does not count the requester for
>deletions(at the SM).

A node does not have to join the group to retrieve the multicast information.

<snip>

> >
> > >
> > >In summary it appears to me that we can combine the two. (A) describes the
> > >requirement on the administrator to keep the link consistent. (B)
> > >describes the requirement on the hosts.
> > >
> > >A) Broadcast-GID defines the link. It MUST not be deleted/modified if the
> > >IPoIB subnet is in use.
> > >
> > >[Just (A) has the following issues issues:
> > >     what about managed shutdown of the link?
> > >     what about erroneous deletion/modification of broadcast-GID?]
> >
> > I'd say both are out-of-scope. See my IPoE analogy above.
> >
> > >
> > >B) Nodes always derive link attributes from the broadcast-GID. If a node
> > >discovers that the broadcast-GID is no longer in existence it MUST declare
> > >the interface 'down'. If the node discovers that the link-attributes are
> > >different than the ones that it had discovered earlier then it SHOULD
> > >reconfigure itself with the new attributes. A node may detect the
> > >existence/disappearance of the broadcast-GID by using traps/reports or the
> > >node might choose to full-member join the broadcast-GID.
> >
> > Although I still don't see the necessity of including the above paragraph,
> > it does look much better and more acceptable.
>
>OK. Is the above (A) and (B) acceptable to all?
>Note: read 'down' above as 'no link'.

It is fine by me except that I would like stronger language on (B) 
indicating that all those requirements
in (B) apply only if the node did not full-member join the broadcast-GID.
-Vandana