RE: Please read - proposed WG termination

________________________________

From: Michael Krause [mailto:[email protected]] 
Sent: Tuesday, August 30, 2005 12:47 PM
To: Vivek Kashyap; Yaron Haviv
Cc: [email protected]; [email protected]; [email protected]
Subject: RE: [Ipoverib] Please read - proposed WG termination

 


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



<Yaron>

The scenario you present is true for a case with a node supporting
single/few IP addresses 

That is not a case for routers that relay on MAC spoofing solutions
(VRRP protocol for example)

In a case of a router there are many IP addresses that can traverse a
single MAC, in some cases the IP addresses are unknown, that's why
instead or taking over an IP address, you take over the MAC which result
in a much faster and robust take-over, this (MAC spoofing) is used in
variety of applications today that would have hard time with IB.

 

The problem is that in IB unlike GbE you cannot take over the MAC 

This requires to either find an IB way to take over the MAC (GID/LID+QP)
or invalidate the IP-MAC relation on the sender side 

 

An example can be seen in:

RFC2176 - IPv4 over MAPOS, that uses UNARP to invalidate the ARP cache
for the same reasons 

 

<Yaron>



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: [email protected] [ mailto:[email protected]

< mailto:[email protected] <mailto:[email protected]> >
] On



Behalf Of H.K. Jerry Chu
Sent: Monday, August 29, 2005 1:38 PM
To: [email protected]
Cc: [email protected]; [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib


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

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