RE: iFCP: iFCP -06 comments

[Black_David@emc.com]

Charles,

> > 9.2.1 - The last paragraph on what to do on loss of synchronization
seems
> > inadequate.  Its current state appears to allow stale frame propagation
> > by a compliant implementation.  Was this the intended outcome?
> > 
> The issue is what to do if a gateway that was enforcing stale frame
> detection enters the unsynchronized state. The original intent was to make
> the gateway response discretionary.  i.e..  Either continue operation but
> suspend enforcement or terminate operation.
> 
> For consistency, we propose that an implementation enforcing the detection
> of stale frames should always do the latter (terminate operation).
> Otherwise, of course, stale frame detection would not have been enabled to
> begin with.

Ok, also please make sure that clear guidance and requirements are provided
for when to use stale frame detection - I think this is at least a SHOULD,
and we'll need to make this consistent among FCIP and iFCP to the extent
possible.

> > 10.4 b) What happens when the broadcast frame exceeds the MTU size?
This
> > seems to result in a rather unreliable broadcast service, as all of the
UDP
> > datagrams could well be dropped, consistently and repeatedly for large
> > enough broadcast frames.
> 
> We will rewrite the section to:
> 
> a) Specify the use of source fragmentation if the datagram exceeds the
PMTU.

Details will need to be supplied, as the large FC frame is being fragmented
into UDP datagrams, and hence the UDP datagrams each need to contain
information about how to reassemble them into an FC frame (unlike TCP
where one can simply follow the bytestream delivered by TCP).  Also, please
add a discussion about the different levels of reliability assumed/provided
by Fibre Channel vs. UDP - FC expects that all frames will be delivered in
the absence of unusual/extraordinary circumstances, whereas UDP is best
effort, and the network is free to drop UDP datagrams if delivering them
would be seriously inconvenient (e.g., router or switch ran out of buffer
space).  The latter discussion is needed to check whether UDP is an
acceptable implementation of FC broadcast.

> b) Require that the receiving broadcast server be capable of accepting the
> maximum FC frame size.

Fine.

> > 7.3.7 - Why is PLOGI in a subsection of 7.3 when it's not augmented?
> > 
> iFCP defines an augmented ELS as any ELS requiring gateway intervention,
> whether or not there's supplemental information to be processed.

This strikes me as excessive consistency and a poor definition of
augmentation.  PLOGI is already discussed in the material on iFCP
session setup in Section 5.  A note at the top of Section 7.3 pointing
back to that discussion of special handling of PLOGI is sufficient
and may allow the PLOGI frame diagram to be deleted (if it's not
deleted, moving it to Section 5 would be a good idea).

> > 7.3.8 - Three translation types are shown for the REC Exchange
originator.
> > Again, I think this should be type 1.  Variants of this problem are also
> > present in all of 7.3.9 through 7.3.15.
> > 
> The issue relates to the manner in which the following ELSs 
> are augmented:
> 
> 7.3.10, 7.3.11  -- Read Exchange Status Block (RES) and RES accept
> 7.3.12 -- Read Link Error Status (RLS)
> 7.3.13 -- Read Sequence Status Block (RSS)
> 7.13.14 -- Reinstate Recovery Qualifier (RRQ)
> 7.13.15 -- Request Sequence Initiative (RSI)
> 
> (REC has since been deleted from FC-FS and will be removed from the iFCP
> spec.)
> 
> As we interpret FC-FS, RES, RLS, and RSS contain N_PORT identifiers in the
> payload which may not necessarily correspond to those of the frame source
or
> destination.  In the case of RES, for example, FC-FS states:
> 
> "The RES ELS Request Sequence requests an N_Port to return the Exchange
> Status Block as defined in 17.8.1 for the RX_ID or OX_ID originated by the
> S_ID specified in the Payload of this Request Sequence..."
> 
> To us, it appears that nothing in the spec requires the S_ID to correspond
> to that of the requesting or responding N_PORTs. We will request
> clarification on this point from T11.

It might also be useful to ask Bob Snively directly, as the most
important ULP for these ELSs is FCP-2.

> For RSI (Request Sequence Initiative) and RRQ (Reinstate Recovery
> Qualifier), the parameter in question is the S_ID of the exchange
> originator, which may correspond to either the ELS originator or
recipient,
> hence we believe a translation type of 1 (frame originator) or 2 (frame
> recipient) is correct.

In any case, it is necessary to spell out the rules/procedures that the
gateway originating the augmented ELS MUST follow in order to determine
which type of translation to use.  The current text leaves it to the
gateway implementer's discretion which is almost certain to result in
incorrect choices being made.

> > 12.2 - Please delete d) as MPLS is *NOT* a QoS technology.  
> 
> After a discussion of over-provisioning, IntServ and DiffServ, we feel
MPLS
> is appropriate since it touches on traffic engineering. For instance, one
> may load a MPLS forwarding equivalence class (FEC) with QoS class
> significance, in addition to other considerations such as protection and
> diversity for the given path. The complementarity and compatibility of
MPLS
> with, say, DiffServ is explored in draft-ietf-mpls-diff-ext-09.txt
(wherein
> the PHB bits are copied to the EXP bits of the MPLS shim header). 

The text starting with "For instance" above is fine.  Insert that
discussion,
remove the existing MPLS RFC reference and replace it with a reference to
that draft (which has been approved by the IESG to become an RFC).

> > In addition,
> > the entire paragraph after d) appears to have very little content, and
> > I'm not at all sure about the value of discussion SLAs here.
> 
> While we are willing to remove this, we believe there is value in taking
the
> reader through a QoS use case for iFCP.
> 
> If possible, we'd like to salvage this material and would appreciate
> suggestions on enhancing or presenting it more appropriately.

I offer the following guidance ...
- Discussing the QoS requirements of iFCP and how existing IETF mechanisms
	can be used to meet them is fine and encouraged.  Explaining how and
	why Fibre Channel traffic may need low jitter, high bandwidth, etc.
	from an IP network is relevant.
- Discussion of SLAs and related contractual arrangements is not a good
idea.
	The IETF considers an SLA to be a contractual vehicle that will
	not be specified in any RFC.  The terms closest to what you're
trying
	to convey are Service Level Specification and Traffic Conditioning
	Specification -- see Section 2 of
draft-ietf-diffserv-new-terms-06.txt .

I'm also interested in the outcome/resolution of the 6.2.1 issue:

> > Use of an IP address to identify a remote gateway needs to be
reconsidered.
> > Please add something to allow multiple iFCP implementations to exist at
> > different TCP ports on the same IP address (or explain why this has to
> > be prohibited).  This is strongly related to the NAPT issues that the
> > FCIP folks are in the midst of working through.

Please inform the list of how the authors propose to resolve this.

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
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------