Re: IPoIB link address

Vandana Rao wrote:
> 
> At 04:02 PM 9/24/2003 -0700, Kanoj Sarcar wrote:
> 
> <snip>
> 
> >I think we have already decided on the other solution, but maybe I can
> >clarify my comment here.
> >
> >Notice that whatever the IP layer does, finally device creation,
> >and/or possibly IP configuration, is dependent on an L2 property for
> >IPoIB, namely the existance of broadcast group(s). I am not suggesting
> >everyone's implementation should error out V4 and/or V6 configuration
> >depending on the group's existance, but pointing out that is a possibility
> >for certain implementations (in lieu of a central administrative tool
> >that can control v4/v6 plumbing on a node basis).
> >
> >Why I think it might be more important to control v4 and/or v6 protocol
> >plumbing in an IBA fabric (vs ethernet) is that each v4 and v6 configuration
> >on a node adds routing overhead to the fabric for the various multicast
> >groups. This is absent in ethernet (or at least the switches' spanning
> >trees know how to gracefully handle too many multicast groups). Section
> >11 of the multicast draft discusses some of these limitations.
> 

Hi,

> The issue with IB multicast resource limitation has nothing to do with
> allowing v4 and/or v6 configuration.
> It has to do with using too many  (v4 or v6) IP multicast groups. I do not
> understand what you mean by each v4/v6 configuration requiring additional
> routing overhead to the fabric for the various multicast groups. I do not
> believe configuring a new IP address will add any extra overhead to the
> fabric for multicast groups.

This is academic at this point, but when v4 or v6 is configured on a device, 
normally IP tries to JOIN to a few multicast groups (224.0.0.1 et al). These 
map to IBA JOINs, which are messages to the SM to arrange the switching tables 
in all the IBA switches so that the multicast packets are appropriately 
forwarded. Thats fabric overhead, and also consumes switching resources at 
the IBA switches.

> 
> > >
> > > >
> > > > Wrt a single QP supporting both v4/v6, two broadcast groups with the same
> > > > attribute set allow that too.
> > > >
> > > > >
> > > > >> > There is also the issue of broadcast traffic isolation that has been
> > > > >> > pointed out; any port which has a only a single qpn accepting v6
> > traffic
> > > > >> > currently does not need to receive broadcast traffic, saving
> > both fabric
> > > > >> > resources and host interruption.
> > > > >>
> > > > >>The v6 qpn need not join the broadcast-GID if option 2) below is
> > chosen. The
> > > > >>driver can, on startup, join the broadcast-GID on the qpn
> > associated with v4
> > > > >>broadcasts. The attributes can then be borrowed for the v6 qpn
> > without it
> > > > >>having to actually join the broadcast-GID. The isolation can still be
> > > > >>maintained in those implementations that prefer it.
> > > > >
> > > > >The expectation was that this broadcast GID was primarily "management"
> > > > >focused (e.g. ARP / ND) thus the overhead / interrupt rate / etc. is
> > > > >expected to be relatively low.  If we all agree that the separation does
> > > > >not impact interoperability, then it is a local issue.
> > > >
> > > > Actually the broadcast traffic is not rare either, not until we move
> > > > all the apps off broadcast to SLP/DHCP or well-known multicast.
> > > > IPv6 has got it right by basing ND on multicast addresses instead of
> > > > the broadcast address.
> > >
> > > Yes, however, as I noted earlier an implementation can always join the
> > > broadcast-GID on one QP and then borrow its attributes for v6
> > > multicast related QPs; it does not have to join the broadcast-GID
> > > itself. Therefore an implementation can choose to keep the traffic
> > > separate.
> >
> >Agreed. By extension, I think we should be careful not to require a
> >node to JOIN the combined broadcast group if it can determine that
> >only v6 will be used on the device, and leave that as an implementation
> >decision.
> 
> Again, could you clarify what you mean here? The node HAS to join the
> combined broadcast group
> if it has to support either or both protocols. In the example given above,
> the v4 QP  (if different for v4 and v6) does not have to attach to the
> broadcast MGID.

If a node only ever intends to support v6 traffic, it might have no reason 
to join the combined broadcast group; rather it can just QUERY the attributes
for the combined group, and then just JOIN the appropriate V6 multicast 
groups as instructed by IP.

Thanks.

Kanoj
 
> -Vandana
> 
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib