> -----Original Message----- > From: Yanjun Zhu [mailto:yanjun.zhu@xxxxxxxxxx] > Sent: Tuesday, May 15, 2018 10:28 PM > To: Parav Pandit <parav@xxxxxxxxxxxx>; Jason Gunthorpe <jgg@xxxxxxxx> > Cc: Tom Talpey <tom@xxxxxxxxxx>; Moni Shoua <monis@xxxxxxxxxxxx>; > dledford@xxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 4/4] IB/rxe: exchange the 2 udp ports > > > > On 2018/5/15 23:42, Parav Pandit wrote: > > > >> -----Original Message----- > >> From: linux-rdma-owner@xxxxxxxxxxxxxxx [mailto:linux-rdma- > >> owner@xxxxxxxxxxxxxxx] On Behalf Of Jason Gunthorpe > >> Sent: Tuesday, May 15, 2018 9:46 AM > >> To: Yanjun Zhu <yanjun.zhu@xxxxxxxxxx> > >> Cc: Tom Talpey <tom@xxxxxxxxxx>; Moni Shoua <monis@xxxxxxxxxxxx>; > >> dledford@xxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx > >> Subject: Re: [PATCH 4/4] IB/rxe: exchange the 2 udp ports > >> > >> On Tue, May 15, 2018 at 08:24:37PM +0800, Yanjun Zhu wrote: > >>> > >>> On 2018/5/15 3:41, Jason Gunthorpe wrote: > >>>> On Mon, May 14, 2018 at 09:42:31AM +0800, Yanjun Zhu wrote: > >>>>> On 2018/5/13 19:49, Tom Talpey wrote: > >>>>>> On 5/12/2018 9:00 PM, Yanjun Zhu wrote: > >>>>>>> On 2018/5/12 22:24, Tom Talpey wrote: > >>>>>>>> On 5/12/2018 9:54 AM, Zhu Yanjun wrote: > >>>>>>>>> When udp port 4791 is blocked, the udp port 4891 is used and > >>>>>>>>> vice versa. > >>>>>>>> Port 4891 is currently unassigned in the IANA registry. Do you > >>>>>>>> intend to request this? > >>>>>>> Yes. If this patch is merged, I will request it. > >>>>>> That is improper - the standards assignment must come first. In > >>>>>> my opinion the firewall reasoning will be rejected by the IANA, > >>>>>> and there's no guarantee what number will be assigned in any > >>>>>> case. The process is defined here: > >>>>>> https://tools.ietf.org/html/rfc6335 > >>>>>> > >>>>>> Do the hard stuff first; develop a solid justification why this > >>>>>> is a good and proper approach, before deploying it on the IP > >>>>>> Internet by making it part of Linux. > >>>>> Thanks a lot for your suggestions. I will request the udp port now. > >>> Hi, Jason > >>> > >>> I checked the Annex 17: RoCEv2. From this spec, the udp is specified > >>> to carry rdma. > >>> This feature is based on the above. And it is transparent to RDMA. > >>> That is, RDMA will not detect udp port exchange. And this feature is > >>> helpful to RDMA. > >> IBTA controls the port numbers that rocev2 uses, and how it should > >> intereact if there are suddently two port numbers. > >> > >>> So I do not know why IBTA do not want to give us a ROCE related port. > >>> I will request the port with IETF. > >>> > >>> If I can get the port, will you merge these patches into mainline? > > I don't think this is right direction. > > I don't see there is any problem here that requires IBTA or IETF's attention. > > In fact this method is creating more security issues and requires mores > administrative hand holding where now administrator needs to block multiple > UDP ports to disable RoCE. > Why is this method creating more security issues? Does another udp port in this > method cause more security issues? > > > Leon already explained this. > > > > What is the inspiration for administrator to block port 4791 and not > > port 4891, where the service is offered on port 4791 Why vxlan UDP > encapsulation doesn't face this problem, which likely/might have wider user > base. > > You intent to create a software extension which bypasses administrative > policy; - not a good idea. > > > > Again rxe will not be able have control of the udp ports that it intend to use, > even if it is coded this way currently. > Sorry. I do not think it is a good idea that ib_core controls upd ports. > According to the layering principle, network should control udp port. > RDMA controls its affairs. > Network and RDMA should split. RoCEv2 is networking over UDP. Provider driver (rxe) cannot own the UDP port. It is in control of ib core to provide right socket to use; it doesn’t matter whether it is hw/sw provider. > > Zhu Yanjun > > It will be ib_core. So the patches in current form won't make progress until the > ib_core rework is finished. > > ��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
