Subject: RE: iFCP: Responses to David Black iFCP Technical review comment s

From: [email-masked]
Date: Tue, 7 May 2002 12:19:28 -0400

Sorry this took so long; I have two issues regarding the proposed
resolutions of my comments.

-- FC-AL support

The responses to Comments 5, 6, and 47 imply that iFCP supports both
private (ALPA addressing only) and fabric-attach loops whose members
are attached to different gateways.  I don't understand how this
can work because it requires forwarding FC-AL loop initialization
ELSs (LINIT) among gateways, but those ELSs do not have a usable
destination port (they're passed directly among neighbors), and
the ports involved in the loop have not performed either FLOGI or
PLOGI when the loop is initializing.  So how does a gateway figure
out whether and where to forward a LINIT that it receives?  I can
figure out how to make this work if only fabric-attached loops are
supported and loops never span gateways, but even that will need
some explanation.

--- Multiple Gateways

The proposed new text is:

             For either iFCP fabric type, an N_PORT may be behind more than
             one gateway provided:

             a) One gateway becomes the 'principal switch' and

             b) All gateways attached to a given gateway region coordinate
                the assignment of N_PORT IDs and N_PORT aliases such that
                each N_PORT has one and only one assigned address.

             The above will be added to the specification.

The implications of multiple gateways for the same N_Port on iSNS
servers and other gateways needs to be discussed.  This may be short,
because if the Port's Network Address is registered with iSNS as
a consequence of FLOGI, only one address will be registered because
FLOGI only occurs once, and hence all traffic to the N_Port will
flow through one gateway.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

---

From: Charles Monia <[email-masked]>
Date: Fri, 10 May 2002 18:50:15 -0700

Hi David:

Please see responses in line.

> supported and loops never span gateways, but even that will need

The issue is whether or not a gateway can support a loop topology. Currently
deployed gateway and FC switch products support such topologies in one of
the following ways:

a) Loop topology emulation in which remotely attached N_PORTs are presented
locally as loop-connected devices.  As you suggest, the loop is emulated
locally and does not span gateways. The emulated device can support either
the public or private loop protocol.  The 'view' looking into the gateway
port from the fibre channel side is a series of N_PORTs presented as
loop-attached devices (NL_Ports).  The loop population consists of
externally attached devices and gateway-emulated NL_Ports.

b) An FL port, which provides fabric access for loop-connected devices.

Neither of these approaches requires anything special on the part of the
iFCP protocol.

The primitives with the behavior you ascribe to LINIT are those such as LIRP
(Loop Initialization Report Position) and LILP (Loop Initialization Loop
Position), which are frames serviced sequentially as they flow though
NL_Ports on the loop. The loop primitive semantics may emulated locally by
the gateway implementation and need not be propagated by iFCP.  How the
gateway populates the loop with emulated NL_Ports is up to the
implementation.

As to LINIT, it is one in a set of ELS functions for remote control of a
fibre channel public loop.   As such, these are standard ELSs which are sent
to the 'Loop Fabric Address' (LFA) of the FL port controlling the loop. 

This, however, does bring up the issue of exposing the fc network topology
of the remote gateway region.  A gateway that chooses to expose remote,
loop-connected devices as NL_Ports should assign the local alias such that
the corresponding LFA can be derived by setting the port_id component of the
address to zero.

The discussion in the spec should be expanded to include these issues.

> flow through one gateway.

The constraints that should be documented are as follows: 

a) Within a gateway region, all N_PORTs whether locally or remotely
attached, must have one and only one N_PORT address.

b)  All iFCP frame traffic between any two N_PORT pairs must flow through a
single iFCP session.  However, each session may traverse a different gateway
attached to the region.

In order to meet these constraints, a multi-gateway implementation may
require an out of band mechanism for redirecting frame traffic from one
physical gateway to another.

Charles

---

From: Charles Monia <[email-masked]>
Date: Fri, 10 May 2002 18:50:15 -0700

Correction
================================
b)  All iFCP frame traffic between any two N_PORTs <pairs> must flow through a
                                                   [delete]
single iFCP session.  However, each session may traverse a different gateway
attached to the region.
=================================

b)  All iFCP frame traffic between any two N_PORTs must flow through a
single iFCP session.  However, each session may traverse a different gateway
attached to the region.

Charles

---

From: [email-masked]
Date: Tue, 14 May 2002 02:52:25 -0400

> gateway populates the loop with emulated NL_Ports is up to the

Yes, I did get confused about which primitive was which ...
The important thing to state here is that an iFCP implementation MUST NOT
forward LIRP, LILP and the like over IP.  The result is that an FC-AL loop
cannot include any iFCP inter-gateway links, and the topology discussion
of how iFCP participates in an FC fabric needs to reflect this.

The resolution of the "port behind multiple gateways" issue looks ok.

Thanks,
--David

---

From: Charles Monia <[email-masked]>
Date: Tue, 14 May 2002 17:01:23 -0700

Hi:

I believe the rule for arbitrated loop support is that loop primitives must
be emulated by the local gateway.  The iFCP protocol does not support the
forwarding of loop control primitives to a remote gateway for emulation.

Charles
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, May 13, 2002 11:52 PM
> To: [email-masked]; [email-masked]
> Subject: RE: iFCP: Responses to David Black iFCP Technical review
> comment s 
> 
> 
> > The primitives with the behavior you ascribe to LINIT are 
> those such as
> LIRP

---

From: [email-masked]
Date: Wed, 15 May 2002 03:45:33 -0400

Say that with an upper case MUST for local emulation and a MUST
NOT for forwarding of loop primitives between iFCP gateways
and this issue is closed.

Thanks,
--David

> From: Charles Monia [mailto:[email-masked]]
> Sent: Tuesday, May 14, 2002 8:01 PM
> To: [email-masked]

---

From: Charles Monia <[email-masked]>
Date: Wed, 15 May 2002 12:33:51 -0700

Will do.

Charles

> Sent: Wednesday, May 15, 2002 12:46 AM