Re: IPoIB link address

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

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

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
>