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

From: "Larsen, Roy K" <[email-masked]>
Date: Mon, 11 Feb 2002 12:18:15 -0800

I completely agree that IPoIB ARP and ND protocol frames will carry the
moral equivalent of a hardware address.  In which case, the QPN can not be
used for explicit LSAP demulteplexing as some had advanced in earlier
threads.  This was the only reason for raising the issue and getting
clarification.

Because it caused confusion within the working group, it is safe to say it
is bound to cause confusion in the Internet community.  Therefore, once we
agree on the method for LSAP determination, the language of the draft should
be specific as to the MAC/LSAP relationship.

Roy

-----Original Message-----
From: H.K. Jerry Chu [mailto:[email-masked]]
Sent: Monday, February 11, 2002 11:08 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [ipoverib] Scope of QPN in ARP Request

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:33:01 -0800 (PST)

Some time back you had suggested a detailed description for 6.1.1b and
I noted that your suggestion made sense. That description essentailly
noted that the QPN in ARP packets is for IPv4/ARP packets and the QPN
in ND is for IPv6 packets. ARe we not revisiting the same discussion
and repeating the need for greater detail as against the sentence in
question? 

Vivek