RE: iFCP as an IP Storage Work Item, Reset

[Joshua Tseng <jtseng@NishanSystems.com>]

Folks,

Charles asked me to send the following message, as he is at
the IPS WG meeting and does not have access to e-mail.  He
also wants everyone to know he will respond to e-mails this
weekend when he gets back.

--------------------------------------

Hi John:

Thanks for helping to refocus the discussion.

I want to emphasize once again that iFCP is a gateway to gateway protocol.
Other discussions to the contrary are simply not relevant or productive.

As much as I dislike playing the role of thought policemen, I feel it's
important to move beyond these debates and focus on matters of technical
substance.  That said, I'm not sure whose job it is to declare these issues
off limits.  I simply hope folks will cooperate and let the matter rest.

Charles Monia

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Monday, January 15, 2001 12:14 PM
> To: ips@ece.cmu.edu
> Subject: iFCP as an IP Storage Work Item, Reset
> 
> 
> I think the messages on iFCP have become somewhat decisive 
> and unfocused.
> And quite frankly it has been permitted to happen by both 
> supporters and
> detractors.  I think this has occurred because engineers tend to solve
> things, whether or not the solution is useful  or if it has a 
> business need
> requiring a fix.  Therefore, having said that, we need to 
> restate what the
> playing field looks like. (The reader is cautioned that this 
> is a lengthy
> note.)
> 
> The iFCP draft says that it is intended to be a Gateway to Gateway
> protocol.  Therefore supporters of iFCP  should stop responding to the
> infinite possibilities to hallucinate various other purposes for this
> protocol.  The protocol is NOT an end to end protocol, and 
> responses that
> do not end the speculation waist our joint time, and polarizes iSCSI
> end-to-end folks against iFCP.   I believe, there are a 
> number of things
> that maybe missing for a robust end-to-end protocol with iFCP, but the
> point is it does not matter, the protocol is structured, proposed and
> analyzed as a Gateway to Gateway protocol, and nothing else 
> is proposed or
> analyzed as part of iFCP.  The head of the company that 
> brought us iFCP,
> has stated that he only wants this as a gateway to gateway 
> protocol, and
> that they are committed to iSCSI also.
> 
> I blame the iFCP supporters for not just shutting down these variant
> thoughts.  The iSCSI supporters would be expected to worry 
> and be paranoid
> about anything they can hallucinate that might threaten 
> iSCSI.  Therefore,
> because the iFCP authors did not stop these thoughts dead in 
> their tracks
> (although Josh tried a couple of time), things got completely 
> out of hand,
> and we moved from a protocol, that in some ways was redundant 
> to FCIP (or
> visa versa), to something that also seemed to threaten iSCSI. 
>  I strongly
> suggest that no real interests are served by this wild speculation
> (Note: I am not completely pure here either, since I also let paranoia
> force me off the reservation when I worried about mFCP and a related
> organization.)  So I want to strongly suggest that we look at 
> iFCP for only
> what it is proposed to be, and NOT stray into other areas.
> 
> To get my head straight, I had to refocus on the environments 
> where FC,
> FCIP, iFCP and iSCSI are going to play to see where the effective
> redundancy and conflict might exist.  Clearly if I thought 
> that iFCP gave a
> serious problem to iSCSI and to FCIP, and was redundant to 
> both, I would
> have a problem.  To analyze this, I had to go through some 
> "market think".
> I know that we are suppose to be in an engineering 
> environment, but it is
> our views of the market that get us polarized.  So the 
> following is the
> analysis I went though and I hope it is helpful to others.
> 
> Working with iFCP defined as a Gateway to Gateway protocol, 
> lets look at
> the various environments where this technology could be 
> deployed.  Also,
> even though there are two types of Gateways that could be 
> built with this
> protocol, a Router, and a Switching Router (Switch with Router
> capabilities) I will assume that a Switching Router is the 
> subject product.
> A Switching Router has several ports that can either be 
> plugged with FC
> cable or Gigabit Ethernet cable, in various combinations.  If only FC
> cables are connected, it is a FC switch, when only Ethernet cables are
> connected it is a IP Switch, with various combinations of FC 
> and Ethernet,
> it is a iFCP Routing Switch, called hereafter an iFCP Switch 
> or an iFCP
> Gateway.
> 
> We should also note that the iFCP Switch Vendor(s) are also 
> claiming (as I
> said above) that they will have, over time, iSCSI support 
> also.  I will
> submit that those environments which have iFCP (with latent iSCSI
> capability) solutions will also help the deployment of iSCSI 
> solutions.
> This is because, the Gateways to FC Host and FC Storage will 
> have already
> have been put in place.
> 
> Here are the environments I examined:
> 
> 1. Existing Single SAN Fibre Channel environments with a number of FC
> Switches.  If the FC SAN already exists, the assumption here 
> is that the
> customer might want to replace his current FC Switches and 
> Hubs with an
> iFCP set of switches and LAN type interconnects.  However, I 
> submit this is
> not really very fertile ground for iFCP switches.  (By the 
> way it is not
> very fertile for iSCSI or FCIP solutions, in the short term, 
> either.)  This
> set of customers will be very hesitant to change since they 
> have already
> had a lot of investment, and they probably think they are on 
> the down hill
> slop of the compatibility and support issues.  They may wish 
> that the cost
> were lower, but any change will be only lots of additional 
> cost to them.
> Continuing with FC will be their probably action.
> 
> 2. Existing Single FC environment, that uses FC to connect 
> mostly point to
> point and not invested in many, if any, switches.  This type 
> of environment
> may use Sharks or Symmetrix type Storage Controllers 
> directly.  And some
> time they will need to expand with new storage controllers, 
> Host  etc. This
> gives a possible reason to install a FC Switch with iFCP 
> capability, (for
> future expansion).  But this will be a head to head fight 
> with existing FC
> Switch vendors, and therefore such iFCP Gateways will not 
> have a strong
> market here.  (By the way, the iSCSI message is hard in this 
> environment,
> unless the customer has visions of important future expansion 
> with iSCSI
> storage controllers, or needs to bring Desktops and Laptops 
> into the common
> storage pool.)   Likewise there is not a FCIP message here either.)
> 
> 3 a. Existing Multiple FC environments (locations) on a 
> single campus.  FC
> with normal Switch to Switch E-Port connections via long FC 
> cables will be
> able to easily bring interconnection to this environment.  
> However, the
> bringing together of various FC environments is also a strong 
> play for iFCP
> Gateways.  That is, each environment can add a iFCP capable 
> Gateway and
> thereby interconnect the environments, and permit the sharing 
> of various
> storage facilities.  Each individual iFCP interconnected FC 
> environment
> will be able to change its addressing etc., without needing 
> to coordinate
> with any other local site (a Big Plus).   The FCIP solution 
> is also viable
> in this environment, however, when you get to more then two 
> environments,
> the number of (single in -- single out) Edge Connect FCIP 
> routers, go up
> dramatically as the number of locations increase.  The 
> physical space issue
> can be mitigated by a multi-in, multi-out FCIP capable router 
> box.  That
> is, a box that puts the electronics for multiple connections 
> on the FC side
> -- one for each location to location interconnect.  Note, this also
> requires a FC switch with a E-Port that can be connected to 
> an E-Port at a
> specific target location.   Also the FCIP has a disadvantage 
> in each of the
> locations that might look like environment 2 above (since 
> they have few or
> no FC Switches).  iSCSI will find this a difficult 
> environment in general
> because of the existing FC investment.   (Note:  proposed 
> combinations sets
> of "FC-to-iSCSI boxes which route to iSCSI-to-FC boxes" can 
> not be assumed
> to work since iSCSI has not defined any protocol to handle FC 
> ELS, as has
> iFCP.)  Therefore, iSCSI will not be a popular solution here. 
> The higher
> the number of location the stronger the iFCP appears (cost 
> wise) against
> FCIP.  Note: if a iFCP Gateway gets installed, and if the unit also
> supports iSCSI  (as the primary vendor has committed), the inroad for
> iSCSI, in general, will be greatly simplified.  iSCSI folks, 
> therefore,
> should be careful in their dismissing of iFCP, because when 
> it is teamed up
> with iSCSI in this manor, it becomes be a great ally.
> 
> 3 b. Existing Multiple FC environments across a Wide Area.  
> This case is
> the same as 3a above, except normal FC techniques do not 
> apply.  However,
> both iFCP and FCIP approaches apply.  Again the advantage of 
> iFCP vrs FCIP
> have to do with the number of sites that are interconnected, 
> and the site
> independence that iFCP offers.  Also, if the iFCP Gateway has iSCSI
> capabilities, it should permit strong and quick inroads for 
> iSCSI into this
> environment.
> 
> 4. SCSI, and ATA based Host environments that need to grow 
> into a network
> attachment. The non server host, Desktops and Laptops, and 
> servers that
> have incidental remote Storage Access will not generally 
> consider FC as an
> approprate option.  Generally this environment is approprate 
> for the iSCSI
> initiators  (with normal TCP/IP NICs, and iSCSI SW Drivers).  
> Without FC
> the FCIP will not apply to this environment.  iSCSI to FC 
> Gateways will
> exist at the remote environments and possibly iSCSI  native Storage
> Controllers.  iFCP itself is not approprate but if the iFCP 
> box also has
> iSCSI capability, then that can be as valuable as any iSCSI 
> to FC gateway.
> 
> 5. Single  SCSI, based Server environments with needs to grow.  These
> environments will have high access requirements.   When iSCSI HBAs are
> available (1H2001), and with the availability of iSCSI to FC Routers
> (1H2001), this is a fertile market for an iSCSI sale.  When 
> iSCSI Storage
> Controllers are available, this environment will be a 
> significant growth
> area for iSCSI.  It has a head to head message with FC SAN.  
> However, the
> existing knowledge of IP networks and IP Switch cost will be the swing
> consideration to iSCSI.  FCIP has no evolvement in this 
> environment.  iFCP
> in this environment would require FC HBAs, and at lest two 
> iFCP Switching
> Routers. If the customer wants to add iSCSI Storage 
> Controllers, the iFCP
> Switches will not be useful (until it supports iSCSI also).  In this
> environment where the target storage is FC based, iSCSI requires (in
> addition to iSCSI HBAs, & IP Switches),  one or more iSCSI to 
> FC Gateways.
> The winner here, between iFCP and iSCSI will be the solution 
> with the least
> cost. That is, the total cost of the HBAs (initially this maybe a push
> between FC and iSCSI), the IP Switches, and the iSCSI to FC 
> Gateways vs the
> Cost of FC adapters, IP Switches and iFCP Gateways.  If the 
> resultant cost,
> is close, then iSCSI will probably be the winner here, 
> because of industry
> direction.  Having said that, this is one of the environments 
> where iSCSI
> folks think that the iFCP message is diversionary.   If the 
> customer is not
> polarized against FC, and the customers looks at having to 
> buy FC adapters
> for the iFCP deployment, they are probably going to look at a 
> complete FC
> SAN as a more straight forward deployment.  Therefore, the 
> competitive play
> will very often be between FC and iSCSI the possibly diversionary iFCP
> messages  will not be significant and maybe helpful selling 
> the IP Storage
> message.
> 
> 6 a. Multiple  SCSI, based Servers environments (locations) 
> on a single
> campus.  Like 5. above, these environments will have high access
> requirements, and when iSCSI HBAs are available (1H2001), and 
> the iSCSI to
> FC Routers (Gateways) are available (1H2001), this becomes a 
> fertile market
> for an iSCSI sale.  iSCSI will then have a head to head 
> competitive message
> in this environment with FC SANs, and very probably a head to head
> competitive message with the FC and FCIP combo.  (So lets not deceive
> ourselves that iSCSI doesn't have a market conflict with 
> FCIP.)  Since I
> believe that in this environment, the customer probably had a 
> reason for
> not already jumping on FC, and because since I also think 
> they are probably
> well versed in TCP/IP Networks, the iSCSI message, will be 
> well received.
> The iFCP message may also have a play in this environment, 
> they can play to
> the same TCP/IP knowledge as iSCSI does, and suggest to the 
> customer that
> iFCP is a better choice because there are more HBAs and 
> Storage Devices
> based on FC then on iSCSI, etc.  Therefore I think that this is a
> competitive play between everyone, FC SAN, FC and FCIP, iFCP, 
> and iSCSI.
> However. the more iSCSI based storage controllers are 
> shipped, the more the
> play tips toward iSCSI in this environment.  Some iSCSI folks 
> look at iFCP
> having a diversionary message in this case also, however it 
> looks to me as
> a general free for all amongst all the options that are valid in this
> environment and cost will be the driving force.  By the way, 
> the iFCP IP
> Storage message will probably do more to help iSCSI, then it does to
> distract from iSCSI.  Also, in this environment, the trade 
> offs between
> FCIP and iFCP, mentioned in 3a. above, apply here as well.
> 
> 6 b. Multiple  SCSI, based Servers environments (locations) 
> across a wide
> area. This environment fits the same solutions as 6 a. above, 
> except a FC
> only solution is not an option.  That is, an iFCP or FC&FCIP 
> solution is
> approprate as is the iSCSI option, just as in 6a above, but 
> not FC only.
> 
> 7. Multi Hosting environments with Storage Service Providers 
> (SSPs).  These
> environments will be primarily networked environments which when built
> today, are Fibre Channel, but here a iFCP Gateway would be a 
> reasonable
> consideration.  In this environment today, the Hosts will have a FC
> adapters so in either case,  the question is -- will the cost 
> be less using
> iFCP Gateways (where the FC Fibre leave the "Cage", and then 
> goes through
> IP Switches, and then terminates at a iFCP Gateway  just before the FC
> based Storage Units)?  Since the SSPs will be competent in 
> both FC and IP
> networks, the trade off will be primarily cost.  If the costs 
> are close,
> the edge will probably go to iFCP since it can also combine 
> multiple sites
> at less cost then multiple FCIP Gateways (see discussion in 
> point 3 above).
> Having said all that, if iSCSI HBAs, and iSCSI Gateways are available
> (1H2001), then, the SSP  will be able,  to apply additional security
> features (if required by the customer), and they only need low cost IP
> Switches all the way into the Storage Area.  This  will 
> probably the most
> flexible and lowest cost.  Since iSCSI will also be able to 
> glue multiple
> sites together it will be the most probable configuration in this
> environment, over time.   Until that time, iFCP has a strong chance of
> being heavily  used in a SSP environment, perhaps supplanting 
> FC networks
> in this environment.   An iFCP & iSCSI Gateway, would seem to 
> be a very
> high seller, and permit graceful migration to an all iSCSI network.
> 
> --------------------------------------------------------------
> 
> The iFCP messages, in all but environment #7, will be dwarfed 
> by the number
> of vendors shipping iSCSI, and the iSCSI message will be the 
> only important
> IP Storage message that will come through.  But since the 
> number of SSPs is
> small they are easy to market too, and will be fully aware of the
> approprate maturity of iFCP and iSCSI.  However, iFCP will 
> probably only be
> a stepping stone to iSCSI in an SSP environment.  Further, if 
> you take the
> primary iFCP vendor at their word, they will combine their 
> iFCP product by
> including iSCSI, and therefore the total message will be very 
> supportive of
> iSCSI.
> 
> Let me build a matrix that can summarize the above 
> environments (Cases)
> with probability of success.
> 
> Here are the cases again:
> 1. Existing Single SAN Fibre Channel environments with a number of FC
> Switches.
> 2. Existing Single FC environment, that uses FC to connect 
> mostly point to
> point and not invested in many, if any, switches.
> 3 a. Existing Multiple FC environments (locations) on a single campus.
> 3 b. Existing Multiple FC environments across a Wide Area.
> 4. SCSI, and ATA based Host environments that need to grow 
> into a network
> attachment.
> 5. Single  SCSI, based Server environments with needs to grow.
> 6 a. Multiple  SCSI, based Servers environments (locations) 
> on a single
> campus.
> 6 b. Multiple  SCSI, based Servers environments (locations) 
> across a wide
> area
> 7. Multi Hosting environments with Storage Service Providers (SSPs).
> 
> +----+-------+-------+-----+------+----------+--------+
> |Case|FC only|FC&FCIP|iFCP | iSCSI|iFCP&iSCSI|iFCP Msg|
> +----+-------+-------+-----+------+----------+--------+
> | 1  | High  |   NA  | Low | Low  |   Med    |Helpful |
> +----+-------+-------+-----+------+----------+--------+
> | 2  | High  |   NA  | Low | Low  |   Med    |Helpful |
> +------------+-------+-----+------+----------+--------+
> | 3a | High  |  High |High+| Low  |Very High |Helpful |
> +----+-------+-------+-----+------+----------+--------+
> | 3b | NA    |  High |High+| Low  |Very High |Helpful |
> +----+-------+-------+-----+------+----------+--------+
> | 4  | Low   |   NA  | NA  | High |   Med    |NA      |
> +----+-------+-------+-----+------+----------+--------+
> | 5  | Low+  |   NA  |Low+ | High |   Med    |Min Help|
> +----+-------+-------+-----+------+----------+--------+
> | 6a | Med   |  Med  |Med+ | High |Very High |Min Help|
> +----+-------+-------+-----+------+----------+--------+
> | 6b | NA    |  Med  |Med+ | High |Very High |Min Help|
> +----+-------+-------+-----+------+----------+--------+
> | 7  |Hi->Med|  Med  |High |Med>Hi|Very High |Helpful |
> +----+-------+-------+-----+------+----------+--------+
> 
> This table says that in the existing FC environment Case 1-3b,  iSCSI,
> will have tough play.  On the other hand, in multiple location
> environments,  iFCP will have a strong play, against FC & 
> FCIP.   When the
> iFCP product is combined with iSCSI support its  probability 
> of success
> becomes Very High.   In other environments (4-7),  iSCSI has a high
> probability of success.  And when the iFCP product gets iSCSI 
> support it
> will greatly improve its success position.  The marketing 
> messages from
> iFCP are Helpful, or Minimally Helpful.
> 
> Hence the only important conflict is between FCIP and iFCP, 
> and this is
> mostly a "push" except for Multiple Sites, where the Cost 
> might favor iFCP
> (and that is not completely obvious).
> 
> Many of us wanted the FCIP and the iFCP combined so this 
> conflict does not
> exist, however, this looks like both sides have refused to 
> cooperate, so a
> product shoot out will occur.  It looks to me that both will 
> take a piece
> of the market and continue to exist.
> 
> The table indicates that when iFCP is combined with iSCSI, the results
> offers a better product in several areas then either by themselves.
> 
> Therefore, I believe that iFCP has important potential value to our
> customers, and should be part of the IP Storage effort within 
> the IETF.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403
> Internet address: hufferd@us.ibm.com
>