Subject: Re: [ipoverib] Scope of QPN in ARP Request

From: "H.K. Jerry Chu" <[email-masked]>
Date: Mon, 11 Feb 2002 11:08:03 -0800 (PST)

This is an old thread that I missed. But I just discovered the
clarification clause in the encapsulation draft is completely unnecessary.
The original suggestion of the ARP responder using the QPN in an ARP
request for sending only ARP response but not IP pkts won't work anyway
because it violates the ARP RFC. RFC826 only supports the notion of
a node's "hardware address", and it doesn't support a separate "hardware
address" for IPv4 from the one for ARP reply. QPN as part of IB "hardware
address" can have only one value for both ARP and IPv4 frames, period.

Vivek, I suggest we strike out the sentence "All IP communication to the
relevant IPoIB interface MUST be directed to this QPN." in 6.1.1b.
It's completely superfluous and might cause unnecessary confusion.

Jerry
 
>> In the Ethertype thread, it was implied by some that the QPN could be used
>> to demultiplex all protocols carried by IPoIB.  For this to be true, nodes
>> receiving the ARP request broadcast can not assume that the source link
>> address is the destination link address for IPv4 frames.  That is, it is
>> only guaranteed to accept ARP replies.
>> 
>> The encapsulation draft must be clear on the scope of the QPN carried in an
>> ARP request.  If it only specifies the ARP reply queue, then a single ARP
>> request/reply transaction can not identify both IPv4 endpoints.
>> 
>> Since limiting the scope of the QPN in this way would double ARP traffic, I
>> would like to propose the encapsulation draft state that the QPN specified
>> in the ARP request source hardware address MUST be able to except all ARP
>> and IPv4 protocol frames.
>> 
>
>Yes, that is correct. The QPN included in the ARP request/reply MUST
>accept both IPv4 and ARP packets in IBA's unreliable mode. Otherwise
>we need to exchange two QPNs or exchange two messages.
>
>Vivek
>
>> Roy
>> 
>> _______________________________________________
>> IPoverIB mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipoverib
>> 
>
>
>-- 
>Vivek Kashyap
>Linux Technology Center, IBM
>[email-masked] 
>[email-masked] 
>503 578 3422 (o)
>
>_______________________________________________
>IPoverIB mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipoverib

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

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 12 Feb 2002 01:15:31 -0800 (PST)

Jerry,

        In a message a few days back Roy suggested a detailed
        description instead of this sentence. The suggested text
        clarifies the points a lot better and we can use that
        instead. 

Vivek

P.S.    RFC826 does not define the format and contents of the hardware
        address. It is perfectly feasible to format the structure in
        any way an IPoverFoo finds necessary. So, if it makes people
        more comfortable if they exchange two QPNs in the ARP packets
        then it is fine by me. Exchanging two QPNs doesn't double the
        traffic. 
        We have not defined it that way though.