Re: IPoIB link address

At 10:27 AM 9/30/2003 -0700, Vivek Kashyap wrote:

<snip>

> >
> > I'd suggest "191B" (for "IPIB") as the signature 
> (FF1x:191B::255.255.255.255)
> > to reflect the fact that the broadcast group is for both v4 and v6.
> >
> > But if people prefer any of the above it's fine with me too, as long as
> > we can get a closure on this sooner.
>
>:) - that is close 19 == IP.  For the discussion (b) therefore becomes
>FF1x:191B::255.255.255.255.
>
>OK  by me. Between a signature of 191B and 401B I believe Vandana and Kanoj
>have preferred the latter. If they are still in favour of 401B then let us
>choose that.
>

I would still prefer 401b as v6 does not really have a broadcast group defined.

<snip>

> > >
> > >I agree. If end-nodes do not want to join the broadcast GID, they need to
> > >deal with all the requirements that
> > >you have detailed above.
> >
> > Vivek brought up a good point that the empty broadcast group risks being
> > deleted by SM. But unfortunately this problem already exists in the current
> > draft regardless of one or two broadcast groups.
>
>I don't think that this risk existed .. one had to join the broadcast-GID
>permanently -- an IPv4 node couldn't leave the v4 broadcast GID and the v6
>couldn't leave the all-nodes multicast GID since those mappings are always
>required by the v4/v6 stacks. The above issues crop up if
>we allow acquiring the information but not full-joining - as some v6
>only implementations are likely to do.
>
>The thing is that if a group has users(full-join) then the deletion of the
>group is not very likely -- the SM will complain or disallow the deletion.
>Thus there is some admin control and check.  However, if no one is 'joined'
>then there is nothing distinguishing it from no members or no one is
>interested. The SM will quietly acquise to it being deleted OR even delete
>the broadcast-GID by itself since there are no members.

I agree with Vivek. This is not an issue if the nodes join the broadcast 
group as full members.
I do not think there should be any admin control required in creating  and 
maintaining the IB multicast groups.


> >
> > In my mind the broadcast groups for IPoIB are to be treated differently 
> by IB
> > fabric adminstrator/management software compared with other IB MC groups.
> > They are to be created as part of configuring an IPoIB link, and their
> > livelihood should not depend on the condition of nodes running an IP stack.
> > (E.g. your Ethernet VLAN doesn't disappear when you shutdown all the 
> nodes.)
>
>I think it is reverse -- a stack might report a link down if  the
>switch/NIC is down. In this case the broadcast-GID is down/gone -- which
>implies that the link is down since we can't broadcast or new interfaces
>can't join it.
>
>
> > This reasoning is compatible with IBA 1.0 spec when there was 
> "MCGroupRecord"
> > to hold MC groups separate from "MCGroupRecord" that tracks membership.
> > Unfortunately "MCGroupRecord" got removed in 1.0a spec. Now it seems 
> that one
> > must join a MCMemberRecord before an IB MC group can be successfully 
> created.
> >
> > Instead of adding more complexity to the draft, can we leave this to the
> > implementation, e.g., the fabric software to ensure the continuous 
> existence of
> > the special broadcast group as part of IPoIB link? I've checked with 
> some people
> > from IBTA and this seems to be a reasonable requirement that is very 
> easy to
> > meet.
> >
> > We can simply add a clause requiring implementations to ensure that the 
> special
> > broadcast group won't be deleted other than when the IPoIB link is torn 
> down.
> > Then we don't need to require v6 node to JOIN the broadcast group. 
> (Note that
> > even if we require v6 to JOIN, it doesn't solve the problem as I stated 
> ealier.)
>
>
>Yes, the requirement is that the link not be deleted. My interest is to
>determine the level of specification. We could do one of following:
>
>
>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.
-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