RE: comments on draft-ietf-ips-fcovertcpip-00.txt

[Black_David@emc.com]

With my WG co-chair hat off, I have a few comments
and concerns to add to the discussion of this draft.

(1) As a co-author of the diffserv RFC referenced by
the draft, mostly support and want to expand on Glen
Turner's comments:

> QUALITY OF SERVICE WILL FAIL FOR MOST USERS
> 
> The document also states:
> 
>      DSCP (6 bits):  The Differentiated Service Code Points (DSCP) [6]
>      shall be set to correspond to the Premium Service.  This  service
>      provides "Expedited Forwarding" at each  IP hop (Per Hop Behavior
>      (PHB)).
> 
> "Shall" is one of the RFC 'magic words' indicating an absolute
requirement.
> There is no justification for insisting upon the Premium service.
> 
> It prevents ISPs from offering a DiffServ service that best meets
> the needs of FCIP users.  For example, the Premium service may have
> worse latency but better bandwidth than a service explicitly tailored
> for FCIP.  Similarly, the ISP may wish to implement a different
> protection mechanism for an FCIP path than for a Premium path.

The actual situation is even worse.  There is no such thing
as "Premium Service" defined in any standards-track DiffServ
document, and moreover the phrase "Premium Service" isn't used
in RFC 2474, the only DiffServ reference in the draft.  Despite
the name, Differentiated Services is not about specifying
services, so the whole notion of requiring a service is
incorrect.  Also, aside from the class selectors in RFC 2474,
there aren't any mandatory to implement PHBs, and requiring
the use of one that is not otherwise mandatory is not a good
approach for the sorts of reasons that Glen starts to explain
in his examples.  The underlying issue is that this restricts
the options a network operator has in the traffic engineering
area, and they don't like that (to be blunt).  This is not to
say that the IETF always behaves in exactly the fashion that
network operators desire, but rather to point out that this sort
of overly restrictive specification approach is unlikely to
be approved when there are less restrictive alternatives available.

A better approach is to specify the behavioral characteristics
of the forwarding service expected between two FCIP devices
(e.g., latency, advice on how to figure out what bandwidth is
adequate in specific circumstances), and leave the network operator
to figure out how to use DiffServ to make it happen.

> The requirement should be:
> 
>   FCIP targets and clients MUST allow the Differentiated Services
>   Code Point to be configured.  FCIP targets and clients SHOULD
>   use a DSCP of 0 until both parties are authenticated.
> 
> The second sentence allows easy policing of the use of whichever
> DSCP is used for FCIP traffic.

On the general topic of "the less said about this, the
better", I think Glen's second sentence ought to be
omitted.  The first sentence could be enhanced
by pointing out that FCIP devices are expected to be
edge nodes in diffserv domains and hence must comply
not only with this, but all other requirements in RFC
2474 (and I'd sneak in a reference to RFC 2475 [Diffserv
Architecture] as a pointer for those desiring
further explanation).

(2) I'm concerned about the level of detail of the
discussion of FSPF-based FC backbones for two reasons:

- None of this is normative, as all the relevant
	standards in this area are controlled by T11 and
	are transparent to/independent of FCIP.  This text
	is describing examples of how FCIP could be used,
	and that should be made clearer.  At least one
	person has already been confused about this.
- The level of detail carries a risk of version skew
	between the FCIP document and the relevant T11
	forwarding/routing standards.  It should be the
	case that however T11 specified E-ports, two
	E-ports can communicate over FCIP.  I know that
	tracking T11 is the intention, but it'd be a shame
	if something in this discussion prevented that
	from happening in the future.

(3) The approach to security seems to be to use a pair of
external (physically or logically) IPsec gateways to 
address any security issues.  I wonder if that's adequate
from a requirements standpoint - given the words about
security in the ips WG charter, this could become a "MUST
implement IPsec" requirement, leading me to suggest that
the authors give the security area some more thought.

(4) FWIW, I agree with the previous discussion about
needing to rethink the use of TCP segmentation and PSH
to make FC-2 frame boundaries visible at the TCP level.

--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
---------------------------------------------------