RE: [Ipoverib] Please read - proposed WG termination

[Michael Krause <[e-mail]>]

Am I missing something here?  I don't recall ever having to tell everyone 
to unarp when I migrate an IP address from one NIC to another.  The network 
stack issues the new address and remote endnodes note the change.  I don't 
recall ever having to tell everyone when I migrate a MAC address from one 
NIC to another.  Why is IB any different in this regard for either of these 
cases?  The layer 2 address which includes all of the parameters subject to 
change is updated and the remote endnodes note the change.  What is so hard 
about that?

Mike


At 11:40 PM 8/29/2005, Vivek Kashyap wrote:
>On Tue, 30 Aug 2005, Yaron Haviv wrote:
>
>>IB availability is defined today and one can migrate between ports and
>>given the use of UD, can easily migrate between HCA either completely or
>>relatively transparent to the network stack using the IB methods or the
>>same IP address update using the same methods deployed today on all OS
>>offerings.  In the end, it really is an implementation issue and fixing
>>the OpenSM implementations not an IETF issue to resolve any
>>deficiencies.
>>
>>Mike
>>
>><Yaron>
>>
>>Mike, the solution that may work over IB is sending gratuitous ARPs
>>
>>This doesn't cover all the cases, e.g. how would VRRP or MAC faking work
>>over IB ?
>>
>>
>>
>>By nature an IPoIB endpoint also contains QPs, so even theoretically an
>>SM cannot deal with the problem
>
>Am I right in assuming that you are suggesting LID + QPN + GID failover? 
>LID is certainly beyond IPoIB. QPN + GID are in the ambit.
>
>Vivek
>
>>If we want to address interoperability between different vendors I
>>believe we need to address it through standardization
>>
>>
>>
>>If you believe there is a solution that addresses my concerns and can be
>>done in a standard/interoperable way please let me know
>>
>>
>>
>>Yaron
>>
>>>-----Original Message-----
>>>From: [e-mail] [ mailto:[e-mail]
>><mailto:[e-mail]> ] On
>>>Behalf Of H.K. Jerry Chu
>>>Sent: Monday, August 29, 2005 1:38 PM
>>>To: [e-mail]
>>>Cc: [e-mail]; [e-mail]
>>>Subject: [Ipoverib] Please read - proposed WG termination
>>>
>>>Hi folks,
>>>
>>>With the DHCP over IB draft in IESG's hand, we are done with all
>>>the basic IPoIB work, including the architecture (informational),
>>>encapsulation, and DHCP (standard tracked). Now seems a good time
>>>to decide the next step for the WG.
>>>
>>>The work on IPoIB connected mode and most of the MIB drafts started
>>>a while back (2003/2002). Over the years the interest/participation
>>>level on these work has not been high, and now the work seems to drag
>>>on indefinitely. The AD has recently questioned whether the remaining
>>>work should be continued or not.
>>>
>>>The following is a quick update on their status:
>>>
>>>1. IPoIB connected mode
>>>draft-ietf-ipoib-connected-mode-00.txt
>>>updated recently
>>>
>>>2. MIB drafts
>>>IPoIB Textual Conventions MIB
>>>draft-ietf-ipoib-ibmib-tc-mib-06.txt
>>>
>>>IPoIB InfiniBand Interfaces MIB
>>>draft-ietf-ipoib-ibif-mib-07.txt
>>>
>>>IPoIB subnet Management Agent MIB
>>>draft-ietf-ipoib-subnet-mgmt-agent-mib-07.txt
>>>
>>>IPoIB Channel Adapter MIB
>>>draft-ietf-ipoib-channel-adapter-mib-06.txt
>>>
>>>IPoIB Baseboard Management Agent MIB
>>>draft-ietf-ipoib-baseboard-mgmt-agent-mib-02.txt
>>>
>>>IPoIB performance Management Agent MIB
>>>draft-ietf-ipoib-perf-mgmt-agent-mib-03.txt
>>>
>>>The above 6 MIB drafts have gone through the
>>>MIB doctor (Randy Presuhn) review late 2003 and
>>>updated accordingly. All the updated drafts expired
>>>in April 2005.
>>>
>>>3. IPoIB Subnet Manager MIB
>>>draft-ietf-ipoib-subnet-manager-mib-00.txt
>>>
>>>Submitted 3/2004 but has expired too.
>>>
>>>If you want to see any of the above work continue in the WG,
>>>AND is willing to participate to get the work completed, please
>>>speak up NOW! You will have until Sep. 20 to do so. After
>>>that unless there is evidence a "sufficient" interest level
>>>on any of the work above still exists, the WG will be disbanded
>>>(or become dormant in order to handle the on-going work on
>>>the standard-tracked RFCs) and the unfinished work abandoned.
>>>
>>>Note that authors of the above drafts may choose to resubmit
>>>their drafts as individual submissions if they want to continue
>>>to pursue their work at IETF.
>>>
>>>Thank you!
>>>
>>>Jerry & Bill
>>>
>>>IPoIB co-chairs
>>>
>>>
>>>_______________________________________________
>>>IPoverIB mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/ipoverib
>>
>>_______________________________________________
>>IPoverIB mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/ipoverib
>>

_______________________________________________
IPoverIB mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipoverib