Subject: Re: [Ipoverib] Bridging of IP over IB

From: "H.K. Jerry Chu" <[email-masked]>
Date: Fri, 11 Jan 2002 12:51:07 -0800 (PST)

Vivek and I are submitting a new draft (it should show up anytime now)
covering IPoIB link and multicast that removes the contraint you alluded
to below. We believe that IPoIB links can be defined abstractly without
requiring all the IB routing/bridging details. This separation allows
us to proceed and focus on IP in IETF while leaving all the incomplete
IB work for IBTA to handle. Your comments are much welcomed.

Jerry Chu
Sr. Staff Engineer
Solaris Networking
Sun Microsystems, Inc.
(650) 786-5146
 
>From: "Roger Ronald" <[email-masked]>
>To: <[email-masked]>
>Date: Fri, 11 Jan 2002 14:27:20 -0600
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>x-mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
>X-scanner: scanned by Inflex 0.1.5c+ on vieo.com
>Content-Transfer-Encoding: 7bit
>Subject: [Ipoverib] Bridging of  IP over IB
>X-Mailman-Version: 1.0
>List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
>X-BeenThere: [email-masked]
>
>Howdy,
>
>I'll apologize for subscribing and immediately diving in to a heavy
>duty topic. I've noticed text in the IP over IB Architecture draft and 
>IPv4 over IB drafts that imply that bridging/IB routing of IP over IB is 
>stuck until the IBTA makes changes. I don't believe that this needs to be true.
>
>In "IB routing" between IB subnets, the same issues arise as with 
>bridging IP over IB to Ethernet. While it's certainly not easy to do
>this IB routing or Ethernet bridging, I don't believe that it's all that
>different than other bridging problem. There are a few spec issues
>that need resolution, but these aren't too tough. I'm convinced that
>there is a need to allow such bridging.
>
>To start, I will postulate a bridge that joins an Ethernet and an IB
>fabric. To simplify, my hypothetical bridge will only be concerned with
>IP traffic. To move traffic, it will rely on MAC layer addresses. 
>
>Each packet that is forwarded through the bridge must have source 
>and destination addresses replaced with addresses appropriate to
>the destination side's address format (Ethernet devices cannot
>be changed to recognize anything but 48 bit ULAs and IB devices
>probably cannot be persuaded to deal with addresses other than
>LIDs or GIDs. These addresses must be assigned by the bridge and 
>remembered for subsequent use. They must be unique and have 
>no possibility of colliding with addresses already in the address domain.
>
>The fact that each side of the bridge has a well known broadcast 
>(or multicast) address and a protocol for learning addresses 
>allows resolving addresses so that the address resolution is known
>to the requestor AND an address mapping can be established in the bridge.
>
>Given address translation and packet format translation in the 
>bridge for the MAC header, the balance of the bridging problem
>is pretty well covered in the IEEE 802.1d spec.
>Despite the address swizzling, the Spanning Tree Algorithm and
>Protocol seems applicable and usable to prevent topology
>loops (although there might need to be an extension to prevent
>multiple IB subnets from using the same 48 bit ULAs and 
>GIDs for the proxied addresses).
>
>I have some additional input on the direct text of the two affected 
>IP over IB internet drafts, but this email is already too long. I'll save them
>for a bit. I will say that the only protocol changes to these documents
>that I envision involves increasing the requirement for use of the GRH 
>to cover bridged messages as well as the multicast address.
>
>Roger Ronald
>VIEO, Inc.
>
>
>
>_______________________________________________
>IPoverIB mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/ipoverib

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

---

From: Vivek Kashyap <[email-masked]>
Date: Fri, 11 Jan 2002 13:06:43 -0800 (PST)

Oh yes! and I forgot to mention that as far as IPoIB multicast is
concerned, but for the scope bits, there is no other restriction in
defining it for spanning multiple IB subnets. However it will work
only if IB provides the necessary underlying infrastructure.

Vivek

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)

---

From: "Roger Ronald" <[email-masked]>
Date: Fri, 11 Jan 2002 15:15:35 -0600

Great. I'm completely in accord with leaving those details
out of the spec. 

As long as the GID gets included when needed and
the current draft comments that claim it can't be done (section 3.1
in the IPv4 over IB and 3.3 in the IP over IB Architecture draft)
are cleaned up, the details can be documented elsewhere.

RR

---

From: Vivek Kashyap <[email-masked]>
Date: Fri, 11 Jan 2002 13:51:32 -0800 (PST)

> in the IPv4 over IB and 3.3 in the IP over IB Architecture draft)

        You need the LID to the bridge too. You need the GID of the
        host on the remote subnet. So LID+GID but the usage of the GRH
        cannot be mandated. It is upto the implementation and the
        administrator to set it up.

        See my earlier note on this subject. The architecture draft is
        correct in what it says - we can't implement IP subnets across
        IB subnets at this point. A specialised IPoIB-bridge is not
        part of the IB architecture. IB architecture has to inherently
        provide the necessary infrastructure.

        However the specification in the drafts is such that when the
        infrastrucuture comes into being things will work.

Vivek