headers
Bernard King-Smith | 1 Sep 2005 02:10
Picon
Favicon

RE: Please read - proposed WG termination


Having IPoIB-CM is a very important feature to make IB a viable
interconnect in clustered systems. Without IPoIB-CM for HPC clusters, and
commercial clusters using IB to SAN, you need two networks for good total
cluster performance, one for IB ( non-IP traffic ) and an IP performance
network like GigE.  This means that IB is not cost effective as the GigE (
or 10 GigE) network which handles both types of traffic reasonably.

In the HPC world most clusters use the cluster fabric ( and IB is the
future direction ) for both MPI and IP traffic. The IP traffic is usually
for parallel file systems and system management and control. This high
bandwidth IP network is required in most production HPC clusters.  With the
current IPoIB only using UD, the performance is dismal. Our simulations
using the small packet MTU of IB says that the parallel file systems (
GPFS, PVFS, Lustre etc ) can only get 25% of a 4X IB link today and at 12X
it will be about 10%. The problem is that the IP drivers are single
threaded per adapter. Also the CPU utilization of TCP/IP at a MTU of the IB
link very high because of the per packet stack processing. Going to
IPoIB-CM means we can cut down the number of TCP/IP stack traversals from
32 to 1 for a 60K IP packet. This means that you have 30 times as much data
transmitted per device driver call. This will enable IP to show similar
bandwidth with multiple sockets as other protocols that can use RC or
fragment within the device driver.

For commercial clusters, if IB is used for storage, then you save a network
by having fast IP performance and can use the IB network for both. Why use
IB and another network for the commercial cluster, when the other network
supports similar bandwidth for storage and IP.

Implementing IPoIB-CM makes IB viable in the HPC cluster and some
(Continue reading)

Permalink | Reply | 4 comments |
headers
Harald Tveit Alvestrand | 1 Sep 2005 11:12
Picon

RE: Please read - proposed WG termination


--On 31. august 2005 20:10 -0400 Bernard King-Smith <wombat2 <at> us.ibm.com> 
wrote:

> Having IPoIB-CM is a very important feature to make IB a viable
> interconnect in clustered systems. Without IPoIB-CM for HPC clusters, and
> commercial clusters using IB to SAN, you need two networks for good total
> cluster performance, one for IB ( non-IP traffic ) and an IP performance
> network like GigE.  This means that IB is not cost effective as the GigE (
> or 10 GigE) network which handles both types of traffic reasonably.

Actually the numbers I've seen show that you can get more than 1 Gbit/sec 
(the test I was shown had 2 Gbit/sec) out of TCP/IP over Infiniband.
Still pitiful for an 8 Gbit/sec network, but faster than GigE.
(Limitation seems to be completely in the host stacks, btw)

So while parallell 10GigE and IB networks will probably give you more 
performance than an IB network alone, parallell 1GigE and IB networks will 
probably not.

Your mileage may vary, of course.

Apart from that, I agree totally with your logic - with the small provisos 
that 1) we do not know what the performance will be until we code it, and 
that 2) with smarter adapters and better stacks, performance of TCP/IP over 
DG is likely to improve too.

                          Harald
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Krause | 1 Sep 2005 19:38
Picon

RE: Please read - proposed WG termination

At 05:10 PM 8/31/2005, Bernard King-Smith wrote:




Having IPoIB-CM is a very important feature to make IB a viable
interconnect in clustered systems. Without IPoIB-CM for HPC clusters, and
commercial clusters using IB to SAN, you need two networks for good total
cluster performance, one for IB ( non-IP traffic ) and an IP performance
network like GigE.  This means that IB is not cost effective as the GigE (
or 10 GigE) network which handles both types of traffic reasonably.

In the HPC world most clusters use the cluster fabric ( and IB is the
future direction ) for both MPI and IP traffic. The IP traffic is usually
for parallel file systems and system management and control. This high
bandwidth IP network is required in most production HPC clusters.  With the
current IPoIB only using UD, the performance is dismal. Our simulations
using the small packet MTU of IB says that the parallel file systems (
GPFS, PVFS, Lustre etc ) can only get 25% of a 4X IB link today and at 12X
it will be about 10%. The problem is that the IP drivers are single
threaded per adapter. Also the CPU utilization of TCP/IP at a MTU of the IB
link very high because of the per packet stack processing. Going to
IPoIB-CM means we can cut down the number of TCP/IP stack traversals from
32 to 1 for a 60K IP packet. This means that you have 30 times as much data
transmitted per device driver call. This will enable IP to show similar
bandwidth with multiple sockets as other protocols that can use RC or
fragment within the device driver.

These performance problems are primarily implementation-specific and have little to do with IB technology itself.  In addition, nearly all IB solutions use a 2KB not the smallest MTU to transfer data - no different than Ethernet.   As I and others have raised over the years, the enablement of IP over IB to perform well is a local HCA issue not a standards issue.  Addition of checksum off-load support to the HCA is rather trivial and does not require standardization (this is what is done for Ethernet today and is non-standard).  Addition of large send off-load support is a local HCA issue not a standards issue and effectively provides the same benefit as connected mode.  The use of multiple QP to spread work across CPU for both send / receive ala the multi-queue support I've worked with various Ethernet IHV to get in place is again a local HCA issue (does not have to be visible as part of the layer 2 address resolution).  One can construct a very nice performing IP over IB solution but there hasn't been much public progress to implement these de facto capabilities found in Ethernet solutions on IB.  Getting these into a HCA implementation is a heck of a lot easier and faster to do than to develop a standard and getting all of the OS changes made (the HCA implementation issues can all be done underneath the IP stack just like with Ethernet so no real OS impacts).


For commercial clusters, if IB is used for storage, then you save a network
by having fast IP performance and can use the IB network for both. Why use
IB and another network for the commercial cluster, when the other network
supports similar bandwidth for storage and IP.

There will always be Ethernet in any cluster so the fabric is there.  The question is whether it is just for low-bandwidth / management services or for applications.  For storage, need to separate the discussion into whether it is block or file.  For block, IB gateways to Fibre Channel, etc. can and are being used today quite nicely.  Performance is reasonable and the ecosystem costs, target availability, customer "pain", etc. are much lower than attempting to move to native IB storage.  The same applies to file based where IB gateways to Ethernet which then attaches to file servers works quite nicely.  In fact, the original vision of IB was that of an I/O fabric to create modular server solutions.  The addition of IPC came later in the process when it was found to be relatively low cost to define.  So, IB is successful in the HPC world and slowly entering some commercial solutions.  To state that its future relies on getting an IP over IB RC solution is perhaps blowing it a bit out of proportion.   The easier path for all is to simply use the techniques I and others have advocated for years now and solve the problems within the HCA implementation.  Much lower costs and will result in delivering a good performance solution.

BTW, RNIC / Ethernet solutions implement these techniques today.  With the arrival of 10 GbE and the lower prices of RNIC and 10 GbE switch ports, lower latency switches (competitive enough with IB for commercial and many HPC clusters), etc. the success of IB must lie elsewhere and not on an IETF spec.   This was noted at the recent IEEE Hot Interconnects conference as well so isn't just my opinion.

Mike

Implementing IPoIB-CM makes IB viable in the HPC cluster and some
commercial clusters. Otherwise I don't think it competes economically with
other network technologies.

Regards.

Bernie King-Smith
IBM Corporation
Server Group
Cluster System Performance
wombat2 <at> us.ibm.com    (845)433-8483
Tie. 293-8483 or wombat2 on NOTES

"We are not responsible for the world we are born into, only for the world
we leave when we die.
So we have to accept what has gone before us and work to change the only
thing we can,
-- The Future." William Shatner


                                                                          
             Dror Goldenberg                                              
             <gdror <at> mellanox.c                                            
             o.il>                                                      To
             Sent by:                  kashyapv <at> us.ltcfwd.linux.ibm.com,  
             ipoverib-bounces <at>          "H.K. Jerry Chu"                   
             ietf.org                  <Jerry.Chu <at> eng.sun.com>            
                                                                        cc
                                       margaret <at> thingmagic.com,           
             08/30/2005 09:32          ipoverib <at> ietf.org,                 
             AM                        Bill_Strahm <at> McAfee.com             
                                                                   Subject
                                       RE: [Ipoverib] Please read -       
                                       proposed WG termination            
                                                                          
                                                                          
                                                                          
                                                                          
                                                                          
                                                                          








> From: Vivek Kashyap [ mailto:kashyapv <at> us.ibm.com]
> Sent: Tuesday, August 30, 2005 8:39 AM
>
> On Mon, 29 Aug 2005, H.K. Jerry Chu wrote:
>


<snip>


> > 1. IPoIB connected mode draft-ietf-ipoib-connected-mode-00.txt
> > updated recently
>
> Well, in recent days there has been a discussion going on
> based on Dror's input. I also made some updates after some
> discussion on OpenIB (not on
> IETF though).  This draft itself became a working group draft
> this february
> after some lively discussion just before that.  It appears to
> me that we
> should be possible to finalise this draft soon enough.
>
> 20th sept. might be long enough to know one way or the other...
>
> vivek
>


We would like to see IPoIB-CM being finalized in IETF. We see
great value in having a standard for connected mode which effectively
increases the MTU. We are willing to contribute to the standardization
effort. We're also looking at the implementation of IPoIB-CM in Linux.


-Dror _______________________________________________
IPoverIB mailing list
IPoverIB <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipoverib





_______________________________________________
IPoverIB mailing list
IPoverIB <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipoverib 
_______________________________________________
IPoverIB mailing list
IPoverIB <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipoverib
Permalink | Reply | 1 comment |
headers
Vivek Kashyap | 1 Sep 2005 19:51
Picon
Favicon

Re: Please read - proposed WG termination

On Thu, 1 Sep 2005, Roland Dreier wrote:

>    Bernard> In the HPC world most clusters use the cluster fabric (
>    Bernard> and IB is the future direction ) for both MPI and IP
>    Bernard> traffic. The IP traffic is usually for parallel file
>    Bernard> systems and system management and control. This high
>    Bernard> bandwidth IP network is required in most production HPC
>    Bernard> clusters.  With the current IPoIB only using UD, the
>    Bernard> performance is dismal. Our simulations using the small
>    Bernard> packet MTU of IB says that the parallel file systems (
>    Bernard> GPFS, PVFS, Lustre etc ) can only get 25% of a 4X IB link
>    Bernard> today and at 12X it will be about 10%.
>
> It's not clear to me that IPoIB-CM is really the answer here.  First
> of all, for Linux to take advantage of a 64K MTU, major surgery to the
> network stack will be required.  Production systems have trouble even
> enabling 8K jumbo frames, because the kernel can't allocate two
> physically contiguous buffers to use for receive.  Given that no

That is an implementation issue in Linux and shouldn't effect the protocol.

> current IB hardware can offload TCP/IP checksums for multi-packet RC
> messages, it's not clear how feasible this network stack surgery is.

Checksum offload is not part of the specification but an HCA feature.

>
> Second, if the justification for IPoIB-CM is really for parallel file

The justification is better performance through larger MTU, and leveraging 
connectd modes's apm capability.  I'd view parallel fs is just one application 
that can use it.

Vivek

> systems, then it seems much more promising to run the file system
> natively on InfiniBand.  For example, since Lustre is implemented on
> top of the Portals abstraction, native implementations of Lustre have
> been in use on IB, Myrinet, Quadrics, etc. for quite some time.
>
> - R.
>
>
Permalink | Reply | 2 comments |
headers
Roland Dreier | 1 Sep 2005 19:45
Picon
Favicon

Re: Please read - proposed WG termination

    Bernard> In the HPC world most clusters use the cluster fabric (
    Bernard> and IB is the future direction ) for both MPI and IP
    Bernard> traffic. The IP traffic is usually for parallel file
    Bernard> systems and system management and control. This high
    Bernard> bandwidth IP network is required in most production HPC
    Bernard> clusters.  With the current IPoIB only using UD, the
    Bernard> performance is dismal. Our simulations using the small
    Bernard> packet MTU of IB says that the parallel file systems (
    Bernard> GPFS, PVFS, Lustre etc ) can only get 25% of a 4X IB link
    Bernard> today and at 12X it will be about 10%.

It's not clear to me that IPoIB-CM is really the answer here.  First
of all, for Linux to take advantage of a 64K MTU, major surgery to the
network stack will be required.  Production systems have trouble even
enabling 8K jumbo frames, because the kernel can't allocate two
physically contiguous buffers to use for receive.  Given that no
current IB hardware can offload TCP/IP checksums for multi-packet RC
messages, it's not clear how feasible this network stack surgery is.

Second, if the justification for IPoIB-CM is really for parallel file
systems, then it seems much more promising to run the file system
natively on InfiniBand.  For example, since Lustre is implemented on
top of the Portals abstraction, native implementations of Lustre have
been in use on IB, Myrinet, Quadrics, etc. for quite some time.

 - R.
Permalink | Reply | 3 comments |
headers
H.K. Jerry Chu | 1 Sep 2005 20:19
Picon

RE: Please read - proposed WG termination

[co-chair hat off]

...
<snip>

>These performance problems are primarily implementation-specific and have 
>little to do with IB technology itself.  In addition, nearly all IB 
>solutions use a 2KB not the smallest MTU to transfer data - no different 
>than Ethernet.

Ethernet is adopting jumboframe to get more firing power. Where is IB's
equivalent of jumboframe?

>As I and others have raised over the years, the enablement 
>of IP over IB to perform well is a local HCA issue not a standards 
>issue.  Addition of checksum off-load support to the HCA is rather trivial 
>and does not require standardization (this is what is done for Ethernet 
>today and is non-standard).  Addition of large send off-load support is a 
>local HCA issue not a standards issue and effectively provides the same 
>benefit as connected mode.

Yes LSO (or TSO as some call it) is relatively easy. But LRO (large receive
offload) is a heck more difficult. IB connected transports already have all
silicons to do it. Why not just use it?

>The use of multiple QP to spread work across 
>CPU for both send / receive ala the multi-queue support I've worked with 
>various Ethernet IHV to get in place is again a local HCA issue (does not 
>have to be visible as part of the layer 2 address resolution).  One can 
>construct a very nice performing IP over IB solution but there hasn't been 
>much public progress to implement these de facto capabilities found in 
>Ethernet solutions on IB.  Getting these into a HCA implementation is a 
>heck of a lot easier and faster to do than to develop a standard and 
>getting all of the OS changes made (the HCA implementation issues can all 
>be done underneath the IP stack just like with Ethernet so no real OS impacts).

I don't understand the large MTU issue to the OS (requiring continguous physical
addresses). Aren't all decent hardware capable of scatter/gather these days?

What's more hairy to the OS stack is the per-destination MTU and different
MTU for multicast than for unicast inherited in IPoIB CM.

Jerry

>
>
>>For commercial clusters, if IB is used for storage, then you save a network
>>by having fast IP performance and can use the IB network for both. Why use
>>IB and another network for the commercial cluster, when the other network
>>supports similar bandwidth for storage and IP.
>
>There will always be Ethernet in any cluster so the fabric is there.  The 
>question is whether it is just for low-bandwidth / management services or 
>for applications.  For storage, need to separate the discussion into 
>whether it is block or file.  For block, IB gateways to Fibre Channel, etc. 
>can and are being used today quite nicely.  Performance is reasonable and 
>the ecosystem costs, target availability, customer "pain", etc. are much 
>lower than attempting to move to native IB storage.  The same applies to 
>file based where IB gateways to Ethernet which then attaches to file 
>servers works quite nicely.  In fact, the original vision of IB was that of 
>an I/O fabric to create modular server solutions.  The addition of IPC came 
>later in the process when it was found to be relatively low cost to 
>define.  So, IB is successful in the HPC world and slowly entering some 
>commercial solutions.  To state that its future relies on getting an IP 
>over IB RC solution is perhaps blowing it a bit out of proportion.   The 
>easier path for all is to simply use the techniques I and others have 
>advocated for years now and solve the problems within the HCA 
>implementation.  Much lower costs and will result in delivering a good 
>performance solution.
>
>BTW, RNIC / Ethernet solutions implement these techniques today.  With the 
>arrival of 10 GbE and the lower prices of RNIC and 10 GbE switch ports, 
>lower latency switches (competitive enough with IB for commercial and many 
>HPC clusters), etc. the success of IB must lie elsewhere and not on an IETF 
>spec.   This was noted at the recent IEEE Hot Interconnects conference as 
>well so isn't just my opinion.
>
>Mike
>
>>Implementing IPoIB-CM makes IB viable in the HPC cluster and some
>>commercial clusters. Otherwise I don't think it competes economically with
>>other network technologies.
>>
>>Regards.
>>
>>Bernie King-Smith
>>IBM Corporation
>>Server Group
>>Cluster System Performance
>>wombat2 <at> us.ibm.com    (845)433-8483
>>Tie. 293-8483 or wombat2 on NOTES
>>
>>"We are not responsible for the world we are born into, only for the world
>>we leave when we die.
>>So we have to accept what has gone before us and work to change the only
>>thing we can,
>>-- The Future." William Shatner
>>
>>
>>
>>              Dror Goldenberg
>>              <gdror <at> mellanox.c
>>              o.il>                                                      To
>>              Sent by:                  kashyapv <at> us.ltcfwd.linux.ibm.com,
>>              ipoverib-bounces <at>          "H.K. Jerry Chu"
>>              ietf.org                  <Jerry.Chu <at> eng.sun.com>
>>                                                                         cc
>>                                        margaret <at> thingmagic.com,
>>              08/30/2005 09:32          ipoverib <at> ietf.org,
>>              AM                        Bill_Strahm <at> McAfee.com
>>                                                                    Subject
>>                                        RE: [Ipoverib] Please read -
>>                                        proposed WG termination
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > From: Vivek Kashyap [mailto:kashyapv <at> us.ibm.com]
>> > Sent: Tuesday, August 30, 2005 8:39 AM
>> >
>> > On Mon, 29 Aug 2005, H.K. Jerry Chu wrote:
>> >
>>
>>
>><snip>
>>
>>
>> > > 1. IPoIB connected mode draft-ietf-ipoib-connected-mode-00.txt
>> > > updated recently
>> >
>> > Well, in recent days there has been a discussion going on
>> > based on Dror's input. I also made some updates after some
>> > discussion on OpenIB (not on
>> > IETF though).  This draft itself became a working group draft
>> > this february
>> > after some lively discussion just before that.  It appears to
>> > me that we
>> > should be possible to finalise this draft soon enough.
>> >
>> > 20th sept. might be long enough to know one way or the other...
>> >
>> > vivek
>> >
>>
>>
>>We would like to see IPoIB-CM being finalized in IETF. We see
>>great value in having a standard for connected mode which effectively
>>increases the MTU. We are willing to contribute to the standardization
>>effort. We're also looking at the implementation of IPoIB-CM in Linux.
>>
>>
>>-Dror _______________________________________________
>>IPoverIB mailing list
>>IPoverIB <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/ipoverib
>>
>>
>>
>>
>>
>>_______________________________________________
>>IPoverIB mailing list
>>IPoverIB <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/ipoverib
Permalink | Reply | 5 comments |
headers
Roland Dreier | 1 Sep 2005 19:27
Picon
Favicon

P_Key membership bit

What is the intention of the language

        1. P_Key
            A "Full Membership" P_Key (high-order bit is set to 1) MUST
            be used so that all members may communicate with one
            another.

in ietf-ipoib-ip-over-infiniband-09.txt?  Let's say that a node has a
P_Key table programmed with P_Key 0x0001 (ie the full membership bit
is _not_ set).  Is the intention that the node should not be able to
join an IPoIB link with that P_Key, or does the node just have to make
sure it joins the broadcast group corresponding to P_Key 0x8001 (with
the full membership bit set)?

Thanks,
  Roland
Permalink | Reply | 0 comments |
headers
H.K. Jerry Chu | 1 Sep 2005 20:26
Picon

Re: FW: Please read - proposed WG termination

>Hi IPoIB folks,
>
>My name is Eitan Zahavi and I work for Mellanox Technologies.
>As my responsibility is IB management software I would like to update the forum
>Mellanox would be interested in contributing to the existing MIB drafts.
>We already have several minor issues with the
>draft-ietf-ipoib-ibif-mib-07.txt and draft-ietf-ipoib-channel-adapter-mib-06.txt
>
>What is not clear to me is how do we work with the forum on these issues?

Just join the list (which you already did) and bring your comments/issues
to the list before it's too late! (May already be too late though.)

Jerry

IPoIB co-chair

>
>Please advice
>
>Eitan Zahavi
>
>> -----Original Message-----
>> From: H.K. Jerry Chu [mailto:Jerry.Chu <at> eng.sun.com] 
>> Sent: Monday, August 29, 2005 8:38 PM
>> To: ipoverib <at> ietf.org
>> Cc: margaret <at> thingmagic.com; Bill_Strahm <at> McAfee.com
>> Subject: [Ipoverib] Please read - proposed WG termination
>> 
>> 
>> Hi folks,
>> 
>> With the DHCP over IB draft in IESG's hand, we are done with all the
>> basic IPoIB work, including the architecture (informational),
>> encapsulation, and DHCP (standard tracked). Now seems a good time to
>> decide the next step for the WG.
>> 
>> The work on IPoIB connected mode and most of the MIB drafts started a
>> while back (2003/2002). Over the years the interest/participation level
>> on these work has not been high, and now the work seems to drag on
>> indefinitely. The AD has recently questioned whether the remaining work
>> should be continued or not.
>> 
>> The following is a quick update on their status:
>> 
>> 1. IPoIB connected mode
>> draft-ietf-ipoib-connected-mode-00.txt
>> updated recently
>> 
>> 2. MIB drafts
>> IPoIB Textual Conventions MIB draft-ietf-ipoib-ibmib-tc-mib-06.txt
>> 
>> IPoIB InfiniBand Interfaces MIB draft-ietf-ipoib-ibif-mib-07.txt
>> 
>> IPoIB subnet Management Agent MIB
>> draft-ietf-ipoib-subnet-mgmt-agent-mib-07.txt
>> 
>> IPoIB Channel Adapter MIB draft-ietf-ipoib-channel-adapter-mib-06.txt
>> 
>> IPoIB Baseboard Management Agent MIB
>> draft-ietf-ipoib-baseboard-mgmt-agent-mib-02.txt
>> 
>> IPoIB performance Management Agent MIB
>> draft-ietf-ipoib-perf-mgmt-agent-mib-03.txt
>> 
>> The above 6 MIB drafts have gone through the
>> MIB doctor (Randy Presuhn) review late 2003 and
>> updated accordingly. All the updated drafts expired
>> in April 2005.
>> 
>> 3. IPoIB Subnet Manager MIB draft-ietf-ipoib-subnet-manager-mib-00.txt
>> 
>> Submitted 3/2004 but has expired too.
>> 
>> If you want to see any of the above work continue in the WG, AND is
>> willing to participate to get the work completed, please speak up NOW!
>> You will have until Sep. 20 to do so. After that unless there is
>> evidence a "sufficient" interest level on any of the work above still
>> exists, the WG will be disbanded (or become dormant in order to handle
>> the on-going work on the standard-tracked RFCs) and the unfinished work
>> abandoned.
>> 
>> Note that authors of the above drafts may choose to resubmit their
>> drafts as individual submissions if they want to continue to pursue
>> their work at IETF.
>> 
>> Thank you!
>> 
>> Jerry & Bill
>> 
>> IPoIB co-chairs
>> 
>> 
>> _______________________________________________
>> IPoverIB mailing list
>> IPoverIB <at> ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib
>
>
>_______________________________________________
>IPoverIB mailing list
>IPoverIB <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/ipoverib
Permalink | Reply | 0 comments |
headers
Sean Harnedy | 1 Sep 2005 20:29

RE: FW: Please read - proposed WG termination

Eitan,
Please post your comments and issues and I will update the I-Ds for the
IPOIB MIBs. 

Jerry,
Is it too late to reissue the IPOIB MIB I-Ds? I could do it next week if
there is interest.

/sean

-----Original Message-----
From: ipoverib-bounces <at> ietf.org [mailto:ipoverib-bounces <at> ietf.org] On
Behalf Of H.K. Jerry Chu
Sent: Thursday, September 01, 2005 2:26 PM
To: ipoverib <at> ietf.org; eitan <at> mellanox.co.il
Cc: gdror <at> mellanox.co.il; amitk <at> mellanox.co.il; Sujal <at> Mellanox.com;
"Michael Kagan " <at> mellanox.co.il
Subject: Re: FW: [Ipoverib] Please read - proposed WG termination

>Hi IPoIB folks,
>
>My name is Eitan Zahavi and I work for Mellanox Technologies.
>As my responsibility is IB management software I would like to update
the forum
>Mellanox would be interested in contributing to the existing MIB
drafts.
>We already have several minor issues with the
>draft-ietf-ipoib-ibif-mib-07.txt and
draft-ietf-ipoib-channel-adapter-mib-06.txt
>
>What is not clear to me is how do we work with the forum on these
issues?

Just join the list (which you already did) and bring your
comments/issues
to the list before it's too late! (May already be too late though.)

Jerry

IPoIB co-chair

>
>Please advice
>
>Eitan Zahavi
>
>> -----Original Message-----
>> From: H.K. Jerry Chu [mailto:Jerry.Chu <at> eng.sun.com] 
>> Sent: Monday, August 29, 2005 8:38 PM
>> To: ipoverib <at> ietf.org
>> Cc: margaret <at> thingmagic.com; Bill_Strahm <at> McAfee.com
>> Subject: [Ipoverib] Please read - proposed WG termination
>> 
>> 
>> Hi folks,
>> 
>> With the DHCP over IB draft in IESG's hand, we are done with all the
>> basic IPoIB work, including the architecture (informational),
>> encapsulation, and DHCP (standard tracked). Now seems a good time to
>> decide the next step for the WG.
>> 
>> The work on IPoIB connected mode and most of the MIB drafts started a
>> while back (2003/2002). Over the years the interest/participation
level
>> on these work has not been high, and now the work seems to drag on
>> indefinitely. The AD has recently questioned whether the remaining
work
>> should be continued or not.
>> 
>> The following is a quick update on their status:
>> 
>> 1. IPoIB connected mode
>> draft-ietf-ipoib-connected-mode-00.txt
>> updated recently
>> 
>> 2. MIB drafts
>> IPoIB Textual Conventions MIB draft-ietf-ipoib-ibmib-tc-mib-06.txt
>> 
>> IPoIB InfiniBand Interfaces MIB draft-ietf-ipoib-ibif-mib-07.txt
>> 
>> IPoIB subnet Management Agent MIB
>> draft-ietf-ipoib-subnet-mgmt-agent-mib-07.txt
>> 
>> IPoIB Channel Adapter MIB draft-ietf-ipoib-channel-adapter-mib-06.txt
>> 
>> IPoIB Baseboard Management Agent MIB
>> draft-ietf-ipoib-baseboard-mgmt-agent-mib-02.txt
>> 
>> IPoIB performance Management Agent MIB
>> draft-ietf-ipoib-perf-mgmt-agent-mib-03.txt
>> 
>> The above 6 MIB drafts have gone through the
>> MIB doctor (Randy Presuhn) review late 2003 and
>> updated accordingly. All the updated drafts expired
>> in April 2005.
>> 
>> 3. IPoIB Subnet Manager MIB
draft-ietf-ipoib-subnet-manager-mib-00.txt
>> 
>> Submitted 3/2004 but has expired too.
>> 
>> If you want to see any of the above work continue in the WG, AND is
>> willing to participate to get the work completed, please speak up
NOW!
>> You will have until Sep. 20 to do so. After that unless there is
>> evidence a "sufficient" interest level on any of the work above still
>> exists, the WG will be disbanded (or become dormant in order to
handle
>> the on-going work on the standard-tracked RFCs) and the unfinished
work
>> abandoned.
>> 
>> Note that authors of the above drafts may choose to resubmit their
>> drafts as individual submissions if they want to continue to pursue
>> their work at IETF.
>> 
>> Thank you!
>> 
>> Jerry & Bill
>> 
>> IPoIB co-chairs
>> 
>> 
>> _______________________________________________
>> IPoverIB mailing list
>> IPoverIB <at> ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib
>
>
>_______________________________________________
>IPoverIB mailing list
>IPoverIB <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/ipoverib

_______________________________________________
IPoverIB mailing list
IPoverIB <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipoverib
Permalink | Reply | 501 comments |
headers
H.K. Jerry Chu | 1 Sep 2005 20:35
Picon

RE: FW: Please read - proposed WG termination

>Eitan,
>Please post your comments and issues and I will update the I-Ds for the
>IPOIB MIBs. 
>
>Jerry,
>Is it too late to reissue the IPOIB MIB I-Ds? I could do it next week if
>there is interest.

No please proceed as nothing will happen. Even if we decide to shut down
the WG you may still continue your work as an individual submission.

Thanks,

Jerry

>
>/sean
>
>
>-----Original Message-----
>From: ipoverib-bounces <at> ietf.org [mailto:ipoverib-bounces <at> ietf.org] On
>Behalf Of H.K. Jerry Chu
>Sent: Thursday, September 01, 2005 2:26 PM
>To: ipoverib <at> ietf.org; eitan <at> mellanox.co.il
>Cc: gdror <at> mellanox.co.il; amitk <at> mellanox.co.il; Sujal <at> Mellanox.com;
>"Michael Kagan " <at> mellanox.co.il
>Subject: Re: FW: [Ipoverib] Please read - proposed WG termination
>
>>Hi IPoIB folks,
>>
>>My name is Eitan Zahavi and I work for Mellanox Technologies.
>>As my responsibility is IB management software I would like to update
>the forum
>>Mellanox would be interested in contributing to the existing MIB
>drafts.
>>We already have several minor issues with the
>>draft-ietf-ipoib-ibif-mib-07.txt and
>draft-ietf-ipoib-channel-adapter-mib-06.txt
>>
>>What is not clear to me is how do we work with the forum on these
>issues?
>
>Just join the list (which you already did) and bring your
>comments/issues
>to the list before it's too late! (May already be too late though.)
>
>Jerry
>
>IPoIB co-chair
>
>>
>>Please advice
>>
>>Eitan Zahavi
>>
>>> -----Original Message-----
>>> From: H.K. Jerry Chu [mailto:Jerry.Chu <at> eng.sun.com] 
>>> Sent: Monday, August 29, 2005 8:38 PM
>>> To: ipoverib <at> ietf.org
>>> Cc: margaret <at> thingmagic.com; Bill_Strahm <at> McAfee.com
>>> Subject: [Ipoverib] Please read - proposed WG termination
>>> 
>>> 
>>> Hi folks,
>>> 
>>> With the DHCP over IB draft in IESG's hand, we are done with all the
>>> basic IPoIB work, including the architecture (informational),
>>> encapsulation, and DHCP (standard tracked). Now seems a good time to
>>> decide the next step for the WG.
>>> 
>>> The work on IPoIB connected mode and most of the MIB drafts started a
>>> while back (2003/2002). Over the years the interest/participation
>level
>>> on these work has not been high, and now the work seems to drag on
>>> indefinitely. The AD has recently questioned whether the remaining
>work
>>> should be continued or not.
>>> 
>>> The following is a quick update on their status:
>>> 
>>> 1. IPoIB connected mode
>>> draft-ietf-ipoib-connected-mode-00.txt
>>> updated recently
>>> 
>>> 2. MIB drafts
>>> IPoIB Textual Conventions MIB draft-ietf-ipoib-ibmib-tc-mib-06.txt
>>> 
>>> IPoIB InfiniBand Interfaces MIB draft-ietf-ipoib-ibif-mib-07.txt
>>> 
>>> IPoIB subnet Management Agent MIB
>>> draft-ietf-ipoib-subnet-mgmt-agent-mib-07.txt
>>> 
>>> IPoIB Channel Adapter MIB draft-ietf-ipoib-channel-adapter-mib-06.txt
>>> 
>>> IPoIB Baseboard Management Agent MIB
>>> draft-ietf-ipoib-baseboard-mgmt-agent-mib-02.txt
>>> 
>>> IPoIB performance Management Agent MIB
>>> draft-ietf-ipoib-perf-mgmt-agent-mib-03.txt
>>> 
>>> The above 6 MIB drafts have gone through the
>>> MIB doctor (Randy Presuhn) review late 2003 and
>>> updated accordingly. All the updated drafts expired
>>> in April 2005.
>>> 
>>> 3. IPoIB Subnet Manager MIB
>draft-ietf-ipoib-subnet-manager-mib-00.txt
>>> 
>>> Submitted 3/2004 but has expired too.
>>> 
>>> If you want to see any of the above work continue in the WG, AND is
>>> willing to participate to get the work completed, please speak up
>NOW!
>>> You will have until Sep. 20 to do so. After that unless there is
>>> evidence a "sufficient" interest level on any of the work above still
>>> exists, the WG will be disbanded (or become dormant in order to
>handle
>>> the on-going work on the standard-tracked RFCs) and the unfinished
>work
>>> abandoned.
>>> 
>>> Note that authors of the above drafts may choose to resubmit their
>>> drafts as individual submissions if they want to continue to pursue
>>> their work at IETF.
>>> 
>>> Thank you!
>>> 
>>> Jerry & Bill
>>> 
>>> IPoIB co-chairs
>>> 
>>> 
>>> _______________________________________________
>>> IPoverIB mailing list
>>> IPoverIB <at> ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib
>>
>>
>>_______________________________________________
>>IPoverIB mailing list
>>IPoverIB <at> ietf.org
>>https://www1.ietf.org/mailman/listinfo/ipoverib
>
>
>_______________________________________________
>IPoverIB mailing list
>IPoverIB <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/ipoverib
>
Permalink | Reply | 0 comments |

Gmane