Re: RARP usage
Vivek Kashyap <[email protected]>
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <[email protected]> |
Kanoj, Yes... similar to the issue with DHCP. It probably is true that the QPN will not be constant across boots - or, at least it is likely given no responses indicating the contrary during the DHCP discussions. I agree that the draft can be updated to include the caution about invariant hardware address. Will update it. Note that the draft states the ethertype to be used if RARP is used but does not require that RARP be used. Vivek -- Vivek Kashyap Linux Technology Center, IBM [email protected] [email protected] Ph: 503 578 3422 T/L: 775 3422 Kanoj Sarcar <Kanoj.Sarcar@sun To: [email protected] .com> cc: Sent by: Subject: [Ipoverib] RARP usage ipoverib-admin@ie tf.org 03/03/2003 05:52 PM Please respond to Kanoj.Sarcar Hi, In section 3.0 of http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-01.txt RARP is indicated as one of the valid traffic types. This might lead people to falsely believe that RARP needs to be implemented on IPoIB. In fact, this might not be possible, since there is no mechanism in IBA to allocate the same QPN to the same interface each time the machine reboots, thus the mac address defined in the draft is variable across reboots, and thus RARP does not make sense. As pointed out in section 2.1.1 in http://www.ietf.org/internet-drafts/draft-ietf-ipoib-dhcp-over-infiniband-05.txt some implementations might choose to preserve the same QPN for the same interface (refer to "... if the implementation is designed to keep this association constant across boots"), and only then RARP might make sense. I propose some verbiage to the effect of "Implementation of RARP is optional for IPoIB and is only suggested on implementations designed to keep the QPN (which is a part of the mac address) to network interface association constant across boots. If the implementation does support RARP, it must use the 'ETHER TYPE' specified in this document." be added in section 3.0 of the previous draft just after Table 1. Thanks. Kanoj _______________________________________________ IPoverIB mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ipoverib