Subject: RE: iFCP as an IP Storage Work Item

From: [email-masked]
Date: Wed, 3 Jan 2001 15:23:51 -0500

> The iFCP proposal for encapsulating Fibre Channel frames should not be a
> work item for the IP Storage working group.
> This view is taken by Cisco Systems and Brocade Communications for the
> following technical reasons.

Important procedural note - IETF is an organization of individuals, not
companies.
Official positions of companies are therefore generally not relevant to
decisions
like the one being made on iFCP.  The technical input is appreciated, and
will
be treated as the collected technical opinions of the three individuals
whose
names appeared at the bottom of the email.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Bill Terrell <[email-masked]>
Date: Wed, 3 Jan 2001 15:11:04 -0800

>The downside of this advantage is that native iFCP devices would be
burdened
>with greater complexity and cost. I therefor think iFCP should not be an IP
>Storage work item.
>
>Regards,
>-Steve

How is a native iFCP endpoint (initiator or target) more complex or costly
than an iSCSI native endpoint? What are the specific difficulties inherent
to native iFCP devices versus native iSCSI devices?

Bill

---

From: Charles Monia <[email-masked]>
Date: Wed, 3 Jan 2001 15:15:44 -0800

Hi Stephen:

See my responses below.

> -----Original Message-----
> From: Stephen Byan [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 1:29 PM
> To: 'David Peterson'; Ips@Ece. Cmu. Edu
> Cc: [email-masked]'
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> I agree with David Peterson, Bob Snively, and Mark Bakke. 
> 
> iFCP is quite different from FCIP; the two are not 
> functionally equivalent.
> 
> iFCP is functionally equivalent to iSCSI; it's technical 
> merit is that it is
> cheaper to build a bridge between iFCP and a fibre channel 
> storage device
> than it to build a bridge between iSCSI and a fibre channel 
> storage device.

You seem to be saying that iFCP adds value, so I'll grant you that.

> The downside of this advantage is that native iFCP devices 
> would be burdened
> with greater complexity and cost.

Here's where you lost me. I don't know what you mean by a "native iFCP
device" nor do I understand the basis for your cost and complexity
comparison?

>.......I therefor think iFCP 
> should not be an IP
> Storage work item.
> 

Frankly, I find this conclusion baffling.

Charles

---

From: "Hall, Howard" <[email-masked]>
Date: Wed, 3 Jan 2001 19:11:03 -0500

Charles and Stephen,

Considering iFCP as a replacement to iSCSI concerns me as well.  In this
case I share Stephen's concern that a native iFCP device must always be
burdened with applying a FCP header into the iFCP frames, as well as other
issues.  Neither iFCP or FCIP are conducive to HBA's in my opinion.  iFCP as
a replacement to FCIP is more palatable.   However, in comparing iFCP and
FCIP, I can't get past iFCP's interoperating issues with non-FCP frames,
like proprietary FC remote mirroring and clustering protocols and VI/FC.

-Howard 

> From: Charles Monia [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 6:16 PM
> To: Ips@Ece. Cmu. Edu

---

From: Wayland Jeong <[email-masked]>
Date: Wed, 3 Jan 2001 17:45:04 -0800

> 2. FCIP will function with any existing/future FC-4 protocol such as
> FCP/FCP-2, VI, SRP.
>
Even though the name and the current draft focuses on a single FC-4 mapping
(FCP) there is nothing inherent in the gateway concept that limits inclusion
of other FC-4 mappings. The gateway performs encapsulation at the core and
as such, should be suitable for transporting any protocol mapped over FC.

-Wayland

---

From: Wayland Jeong <[email-masked]>
Date: Wed, 3 Jan 2001 18:14:23 -0800

> issues.  
I'm not sure that anyone has really defined a "native" iFCP device. I would
venture to guess that a "native" iFCP device (or "native" FCIP device for
that matter) would perform encapsulation of FC frames in the HBA rather than
in a physically separate edge device. Thus, the FC HBA and the iFCP gateway
would be collapsed into a single physical realization. With this description
of a "native" iFCP device, I would argue that the overhead in implementing
FCP protocol, which would amount to header manipulations and context
management, is manageable and not entirely different than managing an iSCSI
protocol session. You have many analogous things to deal with like
exchanges, logins, flow-control, etc. So, I don't quite see the extra burden
on such an endpoint product. Now, the issue of replacing iSCSI with iFCP is
an entirely different question and I'm not sure I want to get anywhere near
that one ;-)

> Neither iFCP or FCIP are conducive to HBA's in my opinion.  iFCP as
I'm not sure I understand your comment regarding remote mirroring, but as
far as FC-VI is concerned, a modest extension to the iFCP proposal (support
for FARP) would be all that is necessary to support the transport of VI.

-Wayland

---

From: Charles Monia <[email-masked]>
Date: Wed, 3 Jan 2001 22:44:16 -0800

> From: David Peterson [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 9:42 AM
> To: Ips@Ece. Cmu. Edu
> Subject: iFCP as an IP Storage Work Item
> 
> 

The "technical reasons" given below seem to represent an amalgam of
corporate positioning statements, rather than issues posed for technical
consideration.  In that regard, I don't feel the need to add to Josh's
earlier response other than a few anecdotal remarks.

> 1. FCIP is aligned with the existing FC-BB-2 work in progress.

For those who don't follow Fibre Channel, VI refers to a mapping of the VI
architecture to Fibre Channel.  SRP , is a mapping of SCSI onto VI (I
believe this is targeted primarily at InfiniBand).  In the context of Fibre
Channel, it is functionally equivalent to FCP.

At any rate, there is no inherent reason why FC/VI (and hence SRP) or any
other upper layer protocol can't be supported by iFCP.

> 3. A native iSCSI device will provide the same functionality 
> as a device
> connected to an iFCP gateway.
> 4. Combining iFCP and FCIP does not make any sense since they are
> implemented using two different routing planes. In addition, FCIP is a
> tunneling protocol and requires minimal processing of the 
> Fibre Channel
> frame. In contrast, iFCP is a gateway protocol and requires much more
> processing such as the reading and modification of the Fibre 
> Channel header,

We don't see a problem.  We expect to keep the wire saturated with
flow-through FC frame traffic at Gb speed.

> augmentation data for specific Fibre Channel Extended Link 
> Services, and
> special handling of specific Fibre Channel Extended Link Services.

From firsthand experience, these are not daunting problems.

> 5. Existing Fibre Channel device addressing capability in 
> conjunction with
> FCIP is viable at this point in time.
> 6. Manipulation of N_Port ID's as specified in iFCP will make
> debugging/analysis extremely difficult.
> 

How did you arrive at that conclusion?  Again, this doesn't jibe with our
experience.

> In summary, FCIP exists today and is well-defined. FCIP 
> provides all of the
> features
> necessary to tunnel Fibre Channel over IP networks.  
> Similarly, iSCSI
> provides the
> capability for executing the SCSI command set over IP 
> networks.  Creating
> yet another
> protocol, such as iFCP, is redundant.
> 

In contrast to approaches which keep FC storage devices at arms length from
IP, iFCP enables such devices to fully exploit the technology.  In that
regard, it is definitely not redundant.

Charles
Charles Monia
Senior Technology Consultant
Nishan Systems
email: [email-masked]
voice: (408) 519-3986
fax:   (408) 435-8385

---

From: JP Raghavendra Rao <[email-masked]>
Date: Thu, 4 Jan 2001 11:18:57 -0500 (GMT)

> I believe iFCP should be an IPS work item for the following 
> technical reasons:
> 
> 1)  iFCP allows leverage of existing FCP-based driver stacks and
> preservation of the $$$ and @#$!!% that have been invested in them
> by vendor companies and their customers.
> 

I think the argument for preserving software doesn't make strong case in the
face of a migration to a new mapping/tunneling protocol, new software and new
administration challenges in spite of the fact that all of this is likely to
mimic FC and contained in one or two edge routers - Today's FC network is
difficult to administer and any bridging technology to a different interconnect
is only going to compound it.

It would be nice if somebody comes up with a stronger case for connecting an
iSCSI host to a FC device - Is this attempted for the survival of FC or for
a speedier deployment of iSCSI ?

-JP

---

From: Stephen Byan <[email-masked]>
Date: Thu, 4 Jan 2001 05:46:50 -0800

-----Original Message-----
From: Stephen Byan 
Sent: Thursday, January 04, 2001 8:40 AM
To: 'Bill Terrell'
Subject: RE: iFCP as an IP Storage Work Item

It's all the FC stuff that lets iFCP work over an unreliable data transport
like UDP. It's redundant when running over TCP/IP.

Regards,
-Steve

> From: Bill Terrell [mailto:[email-masked]]
> Sent: Wednesday, January 03, 2001 6:10 PM
> To: 'Stephen Byan'

---

From: "ELLIOTT,STEPHEN (HP-Roseville,ex1)" <[email-masked]>
Date: Thu, 4 Jan 2001 10:43:14 -0800

Regarding the statement of JP Raghavendra Rao:

I offer the following technical consideration.  Consider extremely large
storage arrays.  I think storage arrays tend to be FC devices.  Moreover, 
in some cases there are limitations on the number of SCSI devices that 
can be accomodated on a single host, which would prevent software RAID 
with SCSI from scaling to the same degree as FC in these cases.  

There are other devices as well that are FC-based in order to integrate 
within the FC-SAN that in some cases includes these extremely large storage
arrays.

In each of these cases, connectivity to these devices is essential.  
What SAN devices do you envision ISCSI connecting to?  In what timeframe
do you think the FC SAN market will disappear?

It seems that this issue is separate from the iFCP/iSCSI debate, 
because an appropriate iSCSI bridge could accomodate these 
SCSI-over-FC devices. 

Regards,

Stephen Elliott

-----Original Message-----
From: JP Raghavendra Rao [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 8:19 AM
To: [email-masked]
Subject: RE: iFCP as an IP Storage Work Item

I think the argument for preserving software doesn't make strong case in the
face of a migration to a new mapping/tunneling protocol, new software and
new
administration challenges in spite of the fact that all of this is likely to
mimic FC and contained in one or two edge routers - Today's FC network is
difficult to administer and any bridging technology to a different
interconnect
is only going to compound it.

-JP

---

From: "Franco Travostino" <[email-masked]>
Date: Thu, 04 Jan 2001 14:46:50 -0500

I support further development of iFCP within the IPS Storage WG. It breaks 
new grounds in the FC-to-IP transition realm.

I'm not satisfied with just iSCSI and FCIP. I often think of FCIP as a 
steep precinct wall that is being erected too high too fast. With a fair 
amount of risks lurking (one-fits-all TCP tunnel, dual routing planes, FC 
dialects' autobahn, manual administration). As for public scrutiny: Out of 
3000 messages in my [email-masked] mailbox, I only count about 30 messages 
with technical comments to the FCIP drafts.

Some of us can already give iFCP credit for making the FC-to-IP adaptation 
a more mundane subject. FCIP and the industry can as well benefit from this 
FCIP/iFCP constructive dualism in the WG (via interesting byproducts such 
as iSNS, or common framing techniques).

-franco

-----
Franco Travostino, Director Content Internetworking Lab
Technology Center
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: [email-masked]

---

From: [email-masked]
Date: Thu, 4 Jan 2001 16:49:00 -0500

Charles,

Sorry to jump on this one, but I must be misinterpreting what you wrote:

> Anyhow, the behavior on the FC side of the device is, of course, governed
by
> the applicable FC standards (or their proprietary equivalents). It's not
> required for iFCP devices to interoperate with one another and hence
doesn't
> belong in the spec. 

I hope you meant something along the lines of:

  The FC interfaces on iFCP devices are governed by the appropriate FC
standards
  (which require no modifications for iFCP) and hence must interoperate to
the degree
  required by those standards.  This may depend on implementation choices,
for example,
  an E port on a iFCP device would not be expected to communicate with an N
port.

If iFCP were to somehow make Fibre Channel interoperability worse (e.g., an
F port
that failed to work properly with N ports), that would be a severe problem.

Thanks,
--David

---

From: Joshua Tseng <[email-masked]>
Date: Thu, 4 Jan 2001 14:22:33 -0800

Cam,

I'm glad you find our web site interesting.  SoIP is
Nishan's brand name for its IP-based storage solutions.
This includes our products that use iSCSI, iFCP, iSNS and
other protocols that we are currently implementing.

Josh

> 
> That is an interesting statement considering that Nishan's 
> web site clearly states its purpose to develop SoIP as an 
> "...end to end storage networking solution"
> 
> Regards,
> 
> Cam Ford
> 
> From: Joshua Tseng [mailto:[email-masked]]
> Sent: Thursday, January 04, 2001 10:54 AM
> To: Ips@Ece. Cmu. Edu
> I don't want to stifle any creative technical discussion here,
> but I feel the need to remind everybody that iFCP is positioned
> as a gateway technology only.  While the thought of "native"
> iFCP HBA's might be interesting, this discussion is
> completely irrelevant with regard to whether iFCP should
> or should not become an IPS work item.  iFCP is being proposed
> as an IPS work item purely on its merits as a gateway technology.
> 
> Regards,
> Josh
> 
> > Sent: Thursday, January 04, 2001 5:47 AM
> > To: [email-masked]'
> > Subject: FW: iFCP as an IP Storage Work Item
> > 
> > 
> > 
> >

---

From: Charles Monia <[email-masked]>
Date: Thu, 4 Jan 2001 14:32:01 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 04, 2001 1:49 PM
> To: [email-masked]; [email-masked]

Yes -- your interpretation is correct.

<remainder deleted>

Charles
Charles Monia

---

From: Camden Ford <[email-masked]>
Date: Thu, 4 Jan 2001 13:58:41 -0800

That is an interesting statement considering that Nishan's web site clearly states its purpose to develop SoIP as an "...end to end storage networking solution"

Regards,

Cam Ford

-----Original Message-----
From: Joshua Tseng [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 10:54 AM
To: Ips@Ece. Cmu. Edu
Subject: RE: iFCP as an IP Storage Work Item

Regards,
Josh

---

From: "Grun, Paul" <[email-masked]>
Date: Thu, 4 Jan 2001 14:53:59 -0800

Here's the (crude) way I interpreted what Charles wrote:
an iFCP device has two sides; an FC side and an IP side.  On its FC side, it
better conform to the applicable FC standards, including interoperability
with other iFCP devices.  I agree with Charles that interoperability between
iFCP devices on their "FC side" doesn't seem like an iFCP problem per se;
rather it is a function of whatever interoperability exists between FC
devices today.
Charles?

-paul

Paul Grun                                              
Intel Corporation
Enterprise Platform Group
Fabric Components Division
(503) 677-6768
[email-masked] <mailto:[email-masked]> 

> To: [email-masked]; [email-masked]

---

From: Charles Monia <[email-masked]>
Date: Thu, 4 Jan 2001 15:58:56 -0800

> From: Grun, Paul [mailto:[email-masked]]
> Sent: Thursday, January 04, 2001 2:54 PM
> To: [email-masked]'; [email-masked]; [email-masked]
Hi Paul:

Basically, I agree with the above.

The job of an iFCP gateway is to present FC-side N_PORTs to the IP-side (and
vice-versa).  Everything else behind the gateway is otherwise opaque (as far
as the IP-side is concerned).

The FC side of the gateway may, of course, support interfaces to other kinds
of FC devices or topologies, such as FC switch elements, arbitrated loops,
you-name-it. Although the gateway must comply with the standards or specs
that apply in such cases, these are not within the scope of iFCP since these
interfaces and topologies are not presented on the IP side of the gateway
and are therefore not a factor in gateway-to-gateway interoperability.

Charles

---

From: Wayland Jeong <[email-masked]>
Date: Fri, 5 Jan 2001 07:43:06 -0800

Yes. I am a bit curious as well about the merit of having a common
encapsulation method. If the thought is to standardize on a common TCP
encapsulation method (i.e. hardware assist mechanisms such as TCP options
for PDU alignment or a periodic marker in the byte stream) then I can see
the value. But if the thought is to have a common encapsulation layer below
TCP (i.e. iFCP headers) then this doesn't make any sense to me. The FCIP
draft as it stands doesn't even require such a layer for tunneling FC
frames. Such a layer would be pure overhead for FCIP.

-----Original Message-----
From: Ken Hirata [mailto:[email-masked]]
Sent: Thursday, January 04, 2001 6:47 PM
To: Ips@Ece. Cmu. Edu
Subject: Re: iFCP as an IP Storage Work Item

David,

Why do you want to standardize a common encapsulation protocol
for FCIP and iFCP if their semantics and behavior are completely
different?  Would you want tunneling protocol implementations to
also augment certain ELSs even though it isn't necessary for tunneling
protocol operation?

If a common encapsulation protocol was defined, I believe a
negotiation protocol would be necessary to distinguish between
usage as a gateway or tunneling protocol.  After that behavior
would be completely different; the tunneling protocol doesn't
need to augment ELSs, resolve Fibre Channel Address Identifiers
to IP/N_Port IDs, or do anything else the gateway protocol
would do.

                                         Ken

David Robinson wrote:

> I am throwing in my hat to have the WG support both iFCP and
> FCIP.  From a business/customer perspective I find believable
> markets for both approaches (both of which are still speculation).
> >From a technical perspective they are similar enough that having
> one standard mechanism and one different defacto mechanism will
> cause more problems than it solves.
>
> It is clear that the semantic meaning of the two proposed protocols
> cannot be merged as they do not operate in the same plane of
> traditional stacks. However, from my reading of the two proposals
> the encapsulation mechanisms are remarkably similar even though
> their semantics are diverge significantly.  What I have started
> (before my two weeks away from work, ahhhh...) but haven't
> yet finished, is an investigation on standardizing a common
> encapsulation protocol for FC over TCP/IP. The the FCIP vs iFCP
> becomes a higher level interpretation of the semantics of the
> bits instead of also having two completely different stacks.
>
>         -David

--
Kenneth Hirata
Vixel Corporation
Irvine, CA 92618
Phone: (949) 450-6100
Email: [email-masked]

---

From: [email-masked]
Date: Fri, 5 Jan 2001 14:57:35 -0600

Regardless of native end to end IP SCSI transports, it is clear that we need
to address the existing "legacy" Fibre Channel devices (I still hesitate
calling Fibre Channel legacy, but that's a different story).  So, there is
an obvious need for bridging the gap between current FC devices and the
emerging IP storage networking realm.  On one hand we have a standard
tunneling protocol (FCIP) which would require the use of 1 FC switch port
and 1 FCIP "link extender" port on each side for each remote tunnel desired.
On the other hand the, iFCP equivalent would only require the use of 1 port
on the iFCP gateway (not per tunnel) which has the ability to route sessions
individually to the appropriate end iFCP gateway.  Assuming that the E-port
and L-port problems can be fixed, which supposedly should be no problem,
iFCP definitely seems to be a viable solution.  Whether iFCP or FCIP is the
functionality winner or not, I would say that it would be a loss for the IPS
working group to discard iFCP.  Also, the iSNS protocol, compatible with
both iSCSI and iFCP, has been accepted as a base for the iSCSI name service
and it seems to me that using iFCP would provide a perfect match for future
native iSCSI solutions to incorporate legacy FC devices over IP.  While FCIP
does address the issue of extending a FC link over IP,  I believe that iFCP
has added ip networking functionality and flexibility that is worth while
for the IPS working group to incorporate.

...that's my 20 centavos.....

Dan McConnell
Storage Systems Group
Storage Architecture and Technology Evaluation
[email-masked]

---

From: Charles Monia <[email-masked]>
Date: Fri, 5 Jan 2001 14:30:33 -0800

> Sent: Thursday, January 04, 2001 6:57 PM
> To: Ips@Ece. Cmu. Edu
> There's one item with your reply that I have a question 
> about.  With regards
> to processing overhead, do you agree that FCIP as a tunneling protocol
> would not have to look for ELSs in the Fibre Channel 
> datastream as iFCP
> must do?
> 

Hi Ken:

First of all, ELS's are well off the performance path, so there's no effect
on performance.

More to the point, we process ELS's and other frame traffic because doing so
gives us a big payoff in cost-performance.  A payoff that comes from
allowing iFCP implementations to intelligently leverage IP technology. For
example, maintaining a seperate session for each N_PORT login gives the
gateway  a handle for controlling the flows between individual FC storage
devices, thus fully exploiting IP-based routing and traffic management.
Concealing the Fibre Channel transport infrastructure behind the FC side of
the gateway eliminates the need to for a two-plane routing scheme. IP
routing is then unconstrained by and fully decoupled from FC routing.
More importantly, doing so makes it easier to integrate otherwise
incompatible FC infrastructures.

While I'm at it, and since this issue has come up several times, I should
point out that the NAT-like address translation we do reflects a design
choice made to exploit IP scalability. We could have made the tradeoffs
differently without affecting iFCP in any fundamental way.

Charles 
Charles Monia

---

From: [email-masked]
Date: Fri, 5 Jan 2001 18:58:07 -0500

> differently without affecting iFCP in any fundamental way.

I'm not sure about that.  An important consequence of the NAT-like address
translation is that the allocation of the 24 bit addresses used for S_ID and
D_ID
need not be coordinated across the iFCP boxes.  If two boxes happen to use
the same address(es), the conflicts are resolved by:
- Picking new addresses for the remote ports on the FC side of iFCP and
	translating appropriately.
- Using the IP addresses on the IP side of iFCP to disambiguate which
	iFCP box is involved.
If this address translation isn't done, the resulting need for coordination
of
address allocation strikes me as a "fundamental" change, especially given
the fact that both FC fabrics and loops have their own ideas about how
address allocation happens.

--David

---

From: Charles Monia <[email-masked]>
Date: Fri, 5 Jan 2001 19:17:33 -0800

> Sent: Friday, January 05, 2001 3:58 PM
> To: [email-masked]

Hi David:

You are correct about the need to coordinate such address assigments across
gateways. As you suggest, there are additional consequences stemming from
the way N_PORT addresses are assigned on the FC side of the gateway.  All of
these can be handled by  straighforward extensions to iFCP.

Relative to the basic iFCP model for communications between N_PORTs,
therefore, I don't consider these differences to be fundamental.

Charles

---

From: "Lawrence J. Lamers" <[email-masked]>
Date: Sat, 06 Jan 2001 07:38:18 -0800

The market analysis indicates that a fibre channel over
internet protocol approach, such as FCIP, provides the solution
needed to connect storage networks over Metropolitan and Wide
Area Networks for the foreseeable future. The FCIP proposal
still needs further work in order to provide the necessary
features for it to have long term viability, but we see no
reason that these features can not be added to this approach.

The long term solution  for native attachment of storage
devices to an IP network is iSCSI, a solution that conceptually
fits with the present operating system/software driver stacks,
has broad industry support, and is in process of becoming a
standard within IETF.  ISCSI is a protocol to do SCSI commands
and task management over Ethernet, much as FCP does for fibre
channel, SBP does for 1394, and SIP does for SPI.  Layering one
protocol on top of another to achieve SCSI functionality seems
to complicated an approach that will be difficult to debug and
certify, a field day for Murphy's law.

Certain market niches may be served by other solutions, but it
is believed that the complementary solutions of FCIP and iSCSI
are what should be standardized and promoted to the industry.
This avoids confusion and divisiveness and gets the world to a
storage networked future the fastest,  with the lowest cost and
the least un-productive effort.

It is my belief based on the technical merits and market needs
that the IETF should continue in its present course and support
the FCoverIP work item and the iSCSI work item and not add
additional work items that these solutions already address.

Regards,

Lawrence J. Lamers
Principal Engineer  Advanced Technology Group
SAN Valley Systems, Inc.
408-234-0071
[email-masked]
[email-masked]

---

From: Charles Monia <[email-masked]>
Date: Sat, 6 Jan 2001 09:00:37 -0800

> I agree with David.  While everyone thought that iFCP is just 
> a gateway
> protocol, I do believe iFCP could be used by an HBA talking to a fibre
> channel device from an Ethernet connection.  It puts together 
> an FCP frame,
> adds a TCP/IP header, and out goes to the Ethernet wire.  

Hi Y P:

I think it's important to be clear on one thing. While a product can be
built from a common encapsulation method, it is NOT iFCP. Such a product is
basically leveraging a commmon envelope that encloses different messages.
The sender and receiver reading the contents are different entities that
speak different languages. 

In iFCP, the communicating objects are Fibre Channel storage devices and
host adapters (N_PORTS) addressed through iFCP gateways.  In FCIP, the
communicating entities are FC fabric elements hauling frame traffic
(backbone switches and FC switch elements).

Anyhow, as I stated earlier, this is a useful but somewhat speculative
conversation, since the tunneling folks have yet to be heard from on this
topic.

Charles

> From: Y P Cheng [mailto:[email-masked]]
> Sent: Friday, January 05, 2001 6:59 PM
> To: [email-masked]
> > Before this goes any further ... the two of you may be
> > in violent agreement.  Charles objected to a "handshake";
> > I don't think this objection would preclude one end of
> > a connection announcing the protocol that it intends to
> > use so that the other end can cleanly and quickly
> > terminate the connection if it can't or won't use
> > that protocol (ideally with an error code to the
> > other end indicating protocol incompatibility, so
> > the misconfiguration becomes obvious).  Doug's
> > suggestion of IANA-allocated numbers for identifying
> > protocols for this purpose is reasonable.
> >
> > As to the virtues of being able to speak more than
> > one protocol on a port, Fibre Channel provides examples
> > of where this sort of thing has been added after the
> > initial specifications were done, so I wouldn't dismiss
> > this out of hand.
> >
> > --David
> 
> I agree with David.  While everyone thought that iFCP is just 
> a gateway
> protocol, I do believe iFCP could be used by an HBA talking to a fibre
> channel device from an Ethernet connection.  It puts together 
> an FCP frame,
> adds a TCP/IP header, and out goes to the Ethernet wire.  
> There is good
> reason that the same HBA may talk to another fibre channel 
> device through an
> FCIP port.  There would be different ways to create these connections.
> However, many fibre channel HBAs today support multiple 
> protocols like FCP,
> IP, and VI at the same time.  Therefore, it is possible for a 
> future HBA to
> speak iFCP, FCIP, and even iSCSI on an Ethernet connection at 
> the same time.
> While I don't know if this makes economical sense, but, 
> technically, this is
> definitely possible.
>

---

From: Charles Monia <[email-masked]>
Date: Sat, 6 Jan 2001 14:58:05 -0800

> mimic FC and contained in one or two edge router

I don't know how you equate these.  In my world, debugged and stable driver
stacks are a precious commodity not to be discarded lightly.  The other
factors seem equally pertinent to all IP storage solutions.

> - Today's 
> FC network is

How about the fact that users seem reluctant to trash their existing storage
investments every time a new interconnect technology shows up.  Is that
strong enough? 

Also, storage interconnects have greater market longevity, so I wouldn't
count on FC's demise any time soon. After all, people have been predicting
the demise of parallel SCSI for a while, but after 10+ years, it's still
thriving.

Charles

---

From: Charles Monia <[email-masked]>
Date: Sat, 6 Jan 2001 17:31:48 -0800

Hi Venkat:

I don't find much of technical substance to reply to here.  Obviously,
you're entitled to your views and a position based on your internal business
and product development considerations is not something that can be
productively debated in this or any other forum.

I've interspersed some additional comments below.

> From: Venkat Rangan [mailto:[email-masked]]
> Sent: Saturday, January 06, 2001 11:35 AM
> To: Charles Monia; Ips@Ece. Cmu. Edu
> Hi Charles,
> Thanks for offering your perspective. I respect your opinions 
> and I'm sure
> my responses would be exactly the same as yours if I were in 
> your position.
> 
> > That aside, the general thrust of this note seems
> > to reflect business rather than technical concerns.
> 
> I am not sure if we can separate the overall market viability from
> technical. From our perspective, we do not want the IPS 
> Working Group to
> endorse multiple technologies to address same or relatively 
> close solutions.
> While it is easy to say that as a vendor it should be 
> possible for them to
> support iSCSI, iFCP and FCIP protocols, the cost of 
> developing a solution
> that addresses all three (which includes not just product 
> development but
> testing, certifying and validating interoperable solutions) 
> is something
> that we as a vendor would not like to be drawn into. 
> If you 
> think this is a
> business reason, and should be ignored, we disagree with that opinion.
> 

How can product development concerns be anything else? That being the case,
I don't see how such issues can be productively addressed by the WG.

That said, I'm having a hard time connecting the dots of your market
viability argument.  On the one hand you imply that iFCP is not viable from
a marketing perspective, while asserting at the same time that you'll be
drawn into building iFCP products.  Why else would you have that problem
except in response to the demands of the marketplace? If you truly believe
it's not viable, then you can safely ignore the technology and go about your
business.

> > Such confusion, if it exists, is best sorted out in the 
> marketplace.  In
> my
> > opinion, it's not the business of standards organizations 
> to anoint any
> one
> > technology by picking winners and losers (as some would 
> apparently wish).
> 
> The standards organizations often pick something and others 
> are forced to
> support that. 
> We could let the marketplace decide, but that can be an
> expensive option for the market and can be detrimental to all 
> vendors. 

I don't understand where force enters the picture.

Your position seems based on the arbitrary assumption that some solutions
(namely yours) have a greater inherent claim to legitimacy than others.
That's certainly a matter of opinion. I've always believed that market
competition is a good thing. Obviously, you don't seem to share that view.

>...............................................As an
> example, while we are arguing about iFCP, FCIP and iSCSI, 
> InfiniBand may
> enter the market and with a coherent proposal, may make this 
> irrelevant.
> 

I don't think the time taken to settle this matter is going to make much
difference in the scheme of things. Nonethless, it strikes me that iSCSI and
FCIP are making good progress while this debate goes on.

> I assume that you agree that the combination of iSCSI, FCIP 
> and iFCP has
> redundant technology elements. 

Commonality -- yes to the extent that they all use the same set of wires and
deliver storage solutions.  Redundancy? Absolutely not.

>...............................We believe the IP Storage 
> Working Group needs
> to address the redundant parts which may mean picking 
> something. 
> When it
> does, we expect vendors to adopt and support what is picked.

Who decides what's 'redundant' and on what basis?  

> Do you not see
> a role in standards bodies to pick some technology? 

Absolutely not --  even if it were my favorite solution (as opposed to
yours).

>..............................If you do 
> not, why is
> iFCP being brought to the IP Storage Working Group as a work item?
> 

We brought iFCP to the WG not because we want to legislate what the market
should have but because we believe it can coexist with and offer benefits
that are unique and distinct from the other technologies on the table.

Will we also support iSCSI? You bet. We're in the business of supplying
end-to-end IP-based storage solutions. Unlike some, we see these
technologies as opportunities to be exploited, not threats to be feared or
suppressed.

> > Such assertions about processing overhead are totally without
> > foundation or substance.
> 
> I do not think so. To perform cut-through routing, we only 
> need to examine
> the first 8 bits of a frame (the domain id part of D_ID) to 
> send it to an
> E_Port. If it is within the switch, you can do so by 
> examining the first 24
> bits of the frame (D_ID). Typically, most switches can do 
> this by adding
> less than two to five microseconds to the latency. To perform 
> a lookup to
> establish the From and To of both S_ID and D_ID and 
> substitute the addresses
> and recompute a new CRC or digest would, in my opinion, take 
> more cycles.
> Evidently, you seem to disagree, which is fine.
> 

While a discussion around clock cycles would be fun sometime, I'll simply
point out that we also have a similar bag of tricks and we expect our
performance to be on a par.  Anyhow, in the context of a total system, I
believe this is something that gets lost in the noise.

<remainder deleted>

Charles
Charles Monia

---

From: Charles Monia <[email-masked]>
Date: Sat, 6 Jan 2001 20:45:09 -0800

Hi:

It appears to me that this thread has pretty much deteriorated into a
billboard for marketing messages and positioning statements.  Apparently, a
lot of folks have decided that repeating the same mantras over and over is a
good substitute for an in-depth technical discourse based on the merits.
Solemn pronouncements about the viability of this or that "long term
solution" also appear to serve the same purpose.

I'm a also little fed up with the bogus notion that it ought to be the job
of this organization to bless one technology under the pretext that others
are "unproductive", would "cause confusion and divisiveness", or would be
"difficult to debug", etc, etc, ad nauseum. Those who think they have a
better way ought to waste less time trying to stifle innovation and take
their case to the marketplace.

Yes, iFCP, like any other proposal, needs to come up to the bar by uniquely
adding technical value. In that regard, no one gets a pass. As far as that
criteria for acceptance is concerned, we believe we meet the standard.

Next....

Charles
Charles Monia

> From: Lawrence J. Lamers [mailto:[email-masked]]
> Sent: Saturday, January 06, 2001 7:38 AM
> To: [email-masked]

---

From: Joshua Tseng <[email-masked]>
Date: Sun, 7 Jan 2001 22:44:44 -0800

See below

<Snip..snip>
> No, the world does not need two standards and the IPS WG 
> should force the
> issue.  While companies will always do their own, the mission 
> of a standard
> committee is to find one and only one standard to make everyone's life
> easier.  Failing to do so does not serve this community.
> 
> If FCIP is good enough, why do I need iFCP?  Do I really need the
> scalability of 4 billion fibre channel nodes visible to me?  
> For Internet
> domain names I may need IPv6, but, for storage devices?  
> 24-bits of D_ID
> with 16 million nodes are a lot of addresses.  I do 
> understand perfectly if
> one wishes to dominate the FC switch market.  As a consumer, 
> this is not my
> concern unless one can provide me alternatives with a much 
> lower costs.

<Remainder deleted>

Where have we heard the above line of reasoning before?
Does it sound familiar to...."why do we need OSPF if we have RIP?"
..."why do we need IP/MPLS if we already have ATM?"...."why do we
need DiffServ when we already have a standard for IP precedence?"
.... "why do we need Qualcomm's CDMA when we have GSM?"....
"why do we need iSCSI when we have Fibre Channel?"

If the technology is superior and/or provides additional
capabilities, it should be admitted to IETF.  Admitting only
the first standard to come along is a recipe for mediocrity.
The Internet would not be what it is today if the IETF were
to operate according to this standard.  It hasn't in the past,
and it should not start today with the IPS WG.

iFCP provides truly superior capabilities to the alternative
technologies, and may prove to be disruptive to the business plans
of some companies.  I believe therein lies the real reason why
some object to its admission to the IPS.

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Mon, 8 Jan 2001 12:59:14 -0800

David,

See below:
> 
> See comments below [dap]:
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Joshua Tseng
> Sent: Wednesday, January 03, 2001 6:22 PM
> To: [email-masked]
> [dap]: Maybe I'm mistaken but I believe connecting an 
> existing FCP-based
> driver stack to an iSCSI gateway or FCIP implementation would preserve
> the investment.

I agree iSCSI and FCIP are viable solutions.  But there are also
end users who would like to migrate to a 100% IP network, and to
internetwork all of their existing storage assets through a 100%
IP network.  FCIP cannot provide this, and iFCP is the most efficient
and straightforward way to accomplish this.

> 
> 2)  IP switching and routing technology is far more mature,
> stable, and scalable than the Fibre Channel equivalent.  iFCP
> leverages this aspect of IP technology, while FCIP does not.
> 
> [dap]: The IP switching and routing technology may also be used
> in a FCIP implementation that is FC-BB-2 capable.

Yes, agreed, but FCIP connects E_PORTs, and that requires that
a Fibre Channel fabric be in place.  Once again, some customers
would rather not have this, in order to internetwork their existing
FC storage assets.

> 
> With regard to your reasons why iFCP should not be permitted:
> >
> We support independent development of the FCIP separate from iFCP, but
> this point has nothing to do with iFCP.
> 
> Again, this point says nothing about the technical 
> feasibility of iFCP.
> Regardless, iFCP can encapsulate any protocol that FCIP does.
> 
> Just because iSCSI is an official IPS WG item doesn't mean that
> FC devices will disappear from the face of the earth.  There is still
> a market need to internetwork FC devices over IP networks.
> 
> [dap]: Correct, this is what FCIP and FC-BB-2 are all about.
> 
> > tunneling protocol and requires mimimal processing of the
> > Fibre Channel
> I disagree that the amount of processing is prohibitive in any
> way.  I would like to understand why you feel this way.  As iFCP is
> a gateway protocol, a gateway device typically has more resources
> available to perform these types of operations than an end device.
> 
> Again, this says nothing about iFCP.
> 
> [dap]: You are missing the point. Collectively these are the technical
> reasons
> we believe yet another protocol is not required to achieve the same
> functionality
> that iSCSI and FCIP already provide.

We believe iFCP provides additional capabilities that FCIP cannot provide.
With regard to iSCSI, iFCP is a gateway technology and is designed
to work with existing FC devices.  iSCSI has no such objectives in mind.
> I am confused as to why you think debugging/analysis will be
> difficult.  Please explain.  I don't think this is true, but even
> if it is, the same can be said of many technologies that are described
> in RFC's.  Take NAT for example.  I and my former network buddies have
> had a #@!&% of a time working with NAT.  Does that mean NAT should be
> outlawed in the IETF?  No, of course not!  It is needed to 
> internetwork
> subnets numbered under the "old" IPv4 regime.  Until we reach the
> promised land of IPv6 everywhere, we will continue to see a 
> lot of NAT.
> Even after IPv6, I still think there will be a lot NAT 
> around, probably
> until the year 2654.  Same thing for iSCSI.  I believe iFCP and iSCSI
> will coexist into the forseeable future.
> 
> [dap]: An always-current translation table will be required 
> to debug and
> analyze the iFCP protocol.

Yes, and this is the norm in IP networking itself.  ARP tables and
caches exist in every network switch and router, to translate
IP addresses to ethernet MAC addresses.  This hasn't proven to be a
serious problem in debugging IP networks.

> Of course FCIP allows tunneling--it IS a tunneling protocol.  iFCP
> is NOT a tunneling protocol.  iFCP does NOT tunnel Fibre 
> Channel frames.
> Rather, it allows FC devices to be natively internetworked over an IP
> fabric.  You can't do that with FCIP. You can't do that with 
> iSCSI.  iFCP
> is NOT redundant.
> 
> Regards,
> Josh
> 
> > provides the
> > David Peterson
> > Cisco Systems, Inc (SRBU)
> > Lead Architect - Standards Development
> > Office: 763-398-1007
> > Cell: 612-802-3299
> > e-mail: [email-masked]
> >
> > Bob Snively
> > Brocade Communications Systems
> > Principal Engineer
> > Office:  408 487 8135
> > e-mail:  [email-masked]
> >
> > Mark Bakke
> > Cisco Systems, Inc (SRBU)
> > Chief Architect
> >
>

---

From: Charles Monia <[email-masked]>
Date: Mon, 8 Jan 2001 13:01:56 -0800

Hi David:

Thanks for the feedback.

To avoid losing sight of the forest for the trees, I'd like to step back and
look at the broader picture.

Our basic position is that the combination of features provided by iFCP,
taken in totality, provide unique and useful capabilities.  Yes, there is
overlap to some degree with other proposals.  iSCSI is a new paradigm for
storage and FCIP will provide users with the ability to use IP in a limited
role to integrate existing FC infrastructures.

As we've stated before in some detail, to the extent that iFCP fully
leverages IP technology as the basis for a FC storage solution, we believe
it offers unique intrinsic value.  Obviously, others may not see it that
way.  At this point, I can't think of what more to say that might change
their perception.  So be it.

As to the technical difficulty of debugging such systems, we've had a lot of
hands on experience here and haven't found it to be a problem.  What's more,
the experts tell me there are network black boxes that do similar kinds of
address mapping, so I assume the problem (if there is one) is manageable. In
any event, I believe reasonable people can disagree on this point.

Charles

> Sent: Monday, January 08, 2001 10:55 AM
> To: Joshua Tseng; [email-masked]

---

From: Kevin Gibbons <[email-masked]>
Date: Mon, 8 Jan 2001 17:56:36 -0800

With respect to merging FCIP and iFCP: 
	I do not feel they should be merged.  I do not think the
capabilities of iFCP and FCIP could be easily merged because their
connection models are significantly different.
	Regards, Kevin

-----------------------------------------
Kevin Gibbons
Nishan Systems, Inc.
(408) 519-3756
[email-masked]
-----------------------------------------

---

From: Kevin Gibbons <[email-masked]>
Date: Mon, 8 Jan 2001 17:58:43 -0800

With respect to iFCP as an IP Storage work item:
	I believe there are enough technical contributions to IP storage for
iFCP to be considered as a work item.  My reasoning is based on the ability
of iFCP to support traffic management for individual storage entities.
According to the iFCP specification, individual iFCP entities behind a
gateway have separate addresses and registrations in the iSNS.  This allows
MPLS and other traffic management standards to be specified and used for
individual sessions between initiators and targets. This provides the
ability to control individual session storage traffic, ensuring storage data
can receive priority service.  Additionally, each connection between an
initiator and target has a separate connection built.  If problems occur,
the connection can be torn down without impact to other storage entities.
	Regards, Kevin

---

From: Joshua Tseng <[email-masked]>
Date: Mon, 8 Jan 2001 21:39:18 -0800

Venkat,
> 
> Josh,
> 
> Thanks for the clarification that iFCP is only presented as a gateway
> protocol. The one comment we would make is that we have FC to 
> SCSI gateways
> already in place, without the need for any standards body 
> standardizing a
> new protocol. The function of the gateway is defined by the 
> standards for
> the two protocols being "connected", and gateway details are left as
> implementation details.

Actually, what I meant by gateway protocol is that it is a protocol
spoken by gateways.  It doesn't specify anything about how to
implement the protocol, which is internal to the gateway device as you
point out.  iFCP is the protocol that shows up on the IP network when
at least two iFCP gateways transport storage data between them.

> 
> On another note, it should be feasible to build a gateway 
> that receives FCP
> frames from an N_Port or NL_Port of a SCSI Initiator and map 
> the FCP frames
> into iSCSI frames. The frames are sent on an IP interface and 
> routed by a
> normal IP network and another gateway reconverts the iSCSI 
> PDUs back to FCP
> frames and sends them to the target. You will notice that 
> this does not
> require any routing in the FC Plane and accomplishes the same 
> end goals as
> iFCP. Also, this does not require any further standards work, 
> besides the
> usual FCP, iSCSI and related naming protocols. This also 
> provides the same
> scalability of number of nodes on the network, because the 
> conversion from
> locally significant S_ID and D_ID to iSCSI IP addresses can 
> be done, with
> help from a standardized naming effort such as iSNS.

Yes, I agree.  But this is a different gateway which has nothing
to do with an iFCP gateway.  Definitely these types of gateways
will be needed as we transition to iSCSI.  The new iSNS draft has
a diagram showing both iSCSI-FC gateways and iFCP gateways.  They
have different roles.

> 
> Based on these, we believe the need for IP Storage working 
> group to pick up
> iFCP as a work item is reduced.

hmmm....you lost me here.  An iFCP gateway has nothing to do with
iSCSI.  They are completely separate.

In order to use iSCSI, you need one of the following:

1)  Two iSCSI devices
2)  One iSCSI device, one FC device, and one iSCSI-FC gateway
    (which you described above)

The situation of two FC devices and two iSCSI-FC gateways is clearly
not a design objective of iSCSI.  Of course it can be done, but we 
believe iFCP is clearly the best solution here.

Fibre Channel has its issues, but one thing is certain:  the FCP driver
stacks are very stable and can provide excellent performance for storage
applications.  But the drawback is FC's networking capabilities leave
much to be desired.  On the other hand, IP networking capabilities are
quite stable and work exceedingly well, but the iSCSI driver stack does
not exist yet.

So, iFCP's objective is to marry the best of both worlds--to take the
existing stable, high-performance driver stacks of Fibre Channel and
directly internetwork their individual N_PORTs using TCP/IP.

Therefore, iFCP is an opportunity to leverage the existing and proven
Fibre Channel driver stacks and combine them with the capabilities that
IP networking can provide.  Until the day we have stable iSCSI driver
stacks everywhere, this may prove to be an attractive alternative for
many end users.  Another comparison I liken it to is the need for
NAT until we have IPv6 everywhere.

Josh

> 
> Regards,
> 
> Venkat Rangan
> Rhapsody Networks Inc.
> http://www.rhapsodynetworks.com
> 
>

---

From: "harwood, jack" <[email-masked]>
Date: Tue, 9 Jan 2001 09:44:25 -0500

While in concept FCIP and iFCP both provide gateway functionality I do not
believe they can be merged into one specification.  Both however do provide
useful functions and should be supported as work group items for IPS, I
understand FCIP is already a work item today.  

As mentioned in previous emails FCIP connects E_Ports, which supports
exisiting switch SAN technology.  As such, all of the traffic is sent across
one connection without regard to priority with many FC ports funneled
through single E_Ports.  The benefit to this is connecting existing SAN
technology with all of the control provided by the FC domain.   iFCP
provides the ability to map the FC port connections to the IP domain and
allow for distinguishing FC connections.  With this the FC traffic can be
prioritized according to the connection, traffic, application, etc...  This
perspective for a gateway allows for building SANs while utilizing network
traffic management tools.

As neither covers all cases for connecting Fibre Channel domains both should
be pursued.

Thanks

jack

*****************************************
jack harwood
EMC Corporation
228 South St.
Hopkinton, MA 01748
Phone: 508-435-1000  x22094
FAX: 508-544-2164
email: [email-masked]

---

From: Wayland Jeong <[email-masked]>
Date: Tue, 9 Jan 2001 06:28:16 -0800

I am in support of having iFCP as a IP Storage Work Item for the following
two technical reasons.

1. FCIP is currently not fully specified.

As it stands today, FCIP relies on the concepts of Autonomous Regions (AR's)
and Border Switches (BSW's). The role of a BSW and the structure of AR's in
a FC fabric are not currently well defined in FC-SW-2 (btw, I am willing to
be educated here). A new effort within T11, FC-BB-2, has the charter for
encompassing connectivity to IP networks, but the current BB specification
only addresses ATM and SONET. I have no doubt that T11 can solve these
problems, but without seeing a proposal, it is difficult for me to support
FCIP in its current form.

2. iFCP is a more robust way of connecting SAN islands.

As I understand it, an FCIP connected wide area SAN is virtually a
contiguous fabric (maybe not from a routing perspective, but at least from a
naming perspective). I believe that the Achilles heel of FC fabrics is its
use of a single coherent name space and its reliance on distributed services
(i.e. fabric SNS). When two remote SAN's are connected together,
re-configurations in one SAN will impose a re-configuration in the other
SAN. SSP's for example, have to jump through hoops to avoid these issues
(they don't like the idea of having their customer networks have the ability
to re-configure their data center). Furthermore, when AR's with conflicting
domains are connected, those domains become isolated until the global domain
assignments can be made. I don't see this as a very scalable solution. The
iFCP gateway definition will more effectively isolate FC SAN island's
allowing for connectivity over legacy IP networks, without tightly coupling
the remote storage devices. 

I would like to put one caveat on my position. I want to see iFCP extended,
fully embracing connectivity to existing FC fabrics (i.e. E-ports) and fully
supporting multi-protocol SAN's (IP, VI, etc.).

-Wayland

---

From: Charles Monia <[email-masked]>
Date: Tue, 9 Jan 2001 16:07:19 -0800

Hi Matt:

To clarify matters.

The response was in reference to a thread discussing a "native" iFCP device.
I assume the authors' envisioned that this would be implemented in a NIC of
some sort.  Hence, the reminder.

In any event, iFCP gateways convert iFCP to native FC.

Charles

> From: Matt Wakeley [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 2:09 PM
> To: IPS Reflector
> Joshua Tseng wrote:
> > as a gateway technology only.
> 
> If iFCP is a "gateway", that to me means that it will convert 
> FCP to iSCSI. 
> In that case, FCP is defined as a standard, and iSCSI is a 
> work in progress by
> this group.  Those building such gateways then only have to 
> figure out how to
> make one side of the gateway look native to the other.  What 
> is there to
> standardize?
> 
> -Matt Wakeley
> Agilent Technologies
>

---

From: Wayland Jeong <[email-masked]>
Date: Tue, 9 Jan 2001 15:50:53 -0800

Yes. I did not mean to imply that Class-2 had a built-in
retry mechanism. Class-2 is simply an error handling mechanism
which provides a more timely notification of un-delivered data.
Any reliable delivery mechanism similar to TCP would need to be
implemented as a session layer above FC Class-2.

Thanks for the clarification.

-----Original Message-----
From: Matt Wakeley [mailto:[email-masked]]
Sent: Tuesday, January 09, 2001 2:46 PM
To: Wayland Jeong
Cc: IPS Reflector
Subject: Re: iFCP as an IP Storage Work Item

Sorry,

Fibre Channel, does not guarantee delivery.  The main reason is that FC does
not have transport layer as robust as TCP.  A FC ACK simply informs that the
frame was delivered.  FC does not have any reliable mechanism to handle
retransmission when an ACK is not delivered.

-Matt

Wayland Jeong wrote:
> 
> I think there are some misconceptions here. As you probably know, the ANSI
> FC standard is a collection of specifications that are thick enough to
choke
> an elephant. Of that large body of work, only a portion of it has been
> implemented in the commercial world. I would guess from your comments that
> you are referring to one of the ways that FC attempts to guarantee
delivery.
> The two most notable mechanisms in FC are buffer-to-buffer credit and
> Class-2.
> 
> Now, BB credit is a link-layer concept which ensures that when a FC frame
is
> sent, it will not be dropped on the floor due to congestion. You can
achieve
> the same functionality in Ethernet using 802.3x flow control. That said,
> BB-credit is a layer below what is encapsulated in iFCP. iFCP encapsulates
> FC at frame level and largely does not concern itself with an FC
primitives
> (frame delimiters are an exception to this).
> 
> Fibre Channel has a class of service called Class-2 which provides an ACK
> mechanism to guarantee delivery to the end station. It uses frame-level
> acknowledgements of received data as well as end-to-end buffer credit.
This
> level of service ensures that data sent is delivered at the FC peer level.
> But, Class-2 was not intended to be a congestion management solution.
> Class-2 is an error recovery concept and it will not work well in a lossy
> network (i.e. IP networks with congestion management through WRED and
such).
> Moreover, Class-2 is not generally deployed and the FC industry has
largely
> settled on Class-3.
> 
> Thus, there is nothing within a FC encapsulated in iFCP environment that
> makes this protocol inherently reliable. iFCP specifies TCP as the
transport
> layer and mFCP uses UDP in conjunction with a well-behaved network.
>

---

From: [email-masked]
Date: Fri, 12 Jan 2001 07:23:17 +0200

Josh,

iFCP as way to keep your investment in FCP stacks is a very weak argument.
FCP stacks are not that stable neither that prevalent (there is none in the
most widespread OS family - Windows).

A gateway for a single device should be the exception rather than the rule.

I can support it as a work item ONLY if it plays a real gateway role and
can coexist with FCIP is some synergistic fashion.
As a end-to-end proposal is has little value IMHO.

Julo

Joshua Tseng <[email-masked]> on 09/01/2001 07:39:18

Please respond to Joshua Tseng <[email-masked]>

To:   Venkat Rangan <[email-masked]>
cc:   "Ips@Ece. Cmu. Edu" <[email-masked]>
Subject:  RE: iFCP as an IP Storage Work Item

Venkat,

1)  Two iSCSI devices

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 12 Jan 2001 09:06:43 -0800

Rob,

Thanks for your good insights.  Regarding the following

<much deleted>
> To your point that 'can iFCP co-exist with FCIP', there
> is no technical reason (or even non-technical) why it
> cannot.  After all, we have had BGP and OSPF co-existing
> for approaching a decade now.  Also, there is no doubt
> that iFCP is a gateway-oriented proposal, just as there is
> no doubt that well-written FCP (or FCP-2) device stacks are 
> very reliable.  Having said that, I believe that there probably
> will be more initial implementations of FCIP than iFCP, but
> that is surely not - among reasonable IETF people - a reason
> to quash discussion.

I believe the comparison between FCIP and iFCP is more like that
of RIP and OSPF, not BGP and OSPF.  BGP and OSPF coexist because
they perform completely different roles.  BGP is used to route
between autonomous systems, and OSPF is used for intra-autonomous
system routing.  The Internet could not possibly exist today
without one or the other.

RIP provides a subset OSPF's capabilities, just as Murali pointed
out that FCIP provides a subset of iFCP's capabilities.  Could you
do both in the same network?  Of course you can, but the chances
are if you're using OSPF, you would not need RIP.  Does that
mean RIP is not viable?  Of course not!  RIP exists because it
is simple and can be used to achieve limited objectives.

Josh

> 
> Thank you,
> Rob
> 
> Rob Peglar
> Director, Storage Architecture
> XIOtech Corporation
> (314) 308-6983
> 
> 
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, January 11, 2001 11:23 PM
> > To: [email-masked]

---

From: Charles Monia <[email-masked]>
Date: Fri, 12 Jan 2001 14:35:52 -0800

> most widespread OS family - Windows).

I don't understand where you're coming from.

Granted, you won't find many FC adapters on notebooks and desktops.  However
every enterprise-class operating system, including Windows NT/2000, provides
robust Fibre Channel support.  What's more HBAs, host driver stacks and
middleware for management and failover have been deployed and in-service in
mission-critical applications for some time.

End users have an enormous investment in qualifying, deploying and
supporting these systems. Anyone who's ever had to deal with such users in
major accounts will appreciate what's at stake. From that perspective, I
believe there's value in an approach to IP migration that protects that
investment.

Charles
> Sent: Thursday, January 11, 2001 9:23 PM
> To: [email-masked]
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Joshua Tseng

---

From: [email-masked]
Date: Sat, 13 Jan 2001 17:20:32 +0200

There is no NT/2000 FCP support. Drivers are build on the "old" SCSI port
driver. Very little if any FC is visible (even addressing is twisted).

Julo

Charles Monia <[email-masked]> on 13/01/2001 00:35:52

Please respond to Charles Monia <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  RE: iFCP as an IP Storage Work Item

Granted, you won't find many FC adapters on notebooks and desktops.
However
every enterprise-class operating system, including Windows NT/2000,
provides
robust Fibre Channel support.  What's more HBAs, host driver stacks and
middleware for management and failover have been deployed and in-service in
mission-critical applications for some time.

Charles

---

From: "Peglar, Robert" <[email-masked]>
Date: Sat, 13 Jan 2001 17:03:26 -0600

Some HBA vendors offer a full-blown NT port driver
now, instead of the (prior) NT mini-port which indeed
interfaced with the standard NT SCSIPORT.SYS driver.

Viz. Qlogic with their QLDirect driver.  It bypasses
SCSIPORT.SYS completely.

Rob

> Sent: Saturday, January 13, 2001 9:21 AM
> To: [email-masked]

---

From: Joshua Tseng <[email-masked]>
Date: Mon, 15 Jan 2001 21:25:51 -0800

Yes, you are correct.  A disruption in the IP network at an
inopportune moment can lead to the FC fabric deciding the tunneled
ISL is no good, leaving it isolated indefinitely.  Human intervention
will be necessary (unless the FCIP gateway does it) to reconfigure
the fabric (and trigger the reallocation of DOMAIN_ID's) so that
connectivity across the tunnel can be restored.

BTW, this isn't a small issue either, as disruptions in the
IP network are a common and expected event.

Thanks,
Josh

> Sent: Monday, January 15, 2001 10:49 AM
> Cc: Y P Cheng
> Just a nit, see embedded comment.  Ken
> 
> Joshua Tseng wrote:
> 
> > Furthermore, as Wayland pointed out earlier, a single large 
> FC fabric
> > stretched over multiple WAN links by FCIP is vulnerable to temporary
> > disruptions in the IP network which may trigger reconfigurations in
> > the FC fabric, such as reallocations of DOMAIN_ID's.
> 
> Reallocations of Domain IDs will not occur without administrative
> intervention if the switches in the Fibre Channel Fabric comply with
> the Methodologies for Interconnects (FC-MI) specification.
> 
> >  iFCP addresses
> > this issue by assigning N_PORT ID's locally, eliminating 
> the dependence
> > on a central addressing authority and the need for any 
> "Class F" traffic.
> > The stability and scalability of a large storage network is 
> thus improved.
> >
> > Josh
> 
> --
> Kenneth Hirata
> Vixel Corporation
> Irvine, CA 92618
> Phone: (949) 450-6100
> Email: [email-masked]
> 
>