Re: FCencap: List ALL SOF/EOF codes

[Ralph Weber <ralphoweber@compuserve.com>]

Murali,

> I also recollect that there was some discussion about some illegal 
> codes in that table either in that meeting or in one of the ensuing 
> T11 meetings.

If the SOF/EOF definitions are wrong in FC-BB then someone needs to
get an amendment going to fix that. If they are correct in the published
FC-BB, then copying them to the FC Encapsulation will not be a problem.
It makes very little sense for the FC Encapsulation draft to be the
place where T11 corrects its mistakes.

Elizabeth,

> We had this discussion back in January, and basically came to the 
> conclusion that Class 1 and Class 4 should not be included, for the 
> reasons that class 1 really cannot be supported across the IP network 
> and class 4 is not really not defined yets, so the codes are not 
> guaranteed to remain constant.

However, that discussion back in January concerned the FCIP draft.
The FC Encapsulation draft was not devised until February.

The argument that Class 4 should not be included because it is
not defined is no longer valid because Gary Stephens has almost
completed all the tasks needed to define Class 4 and none of
his changes affect the SOF/EOF codes for Class 4.

It is true that Gary's changes say that Class 4 frames will not
transit ISLs, but the iFCP folks might choose to support them.

As for Class 1, the question becomes which of the following two
reasons motivated the decision last January:

  1) TCP absolutely positively cannot support Class 1, no matter
     how well designed the protocol is; or
  2) The amount of FCIP design effort needed to support Class 1
     is beyond that thought sensible, so FCIP is not going to
     support Class 1.

If choice 1 was the motivation, then it is true that Class 1
should not be added to the FC Encapsulation draft. However, this
choice means telling the IESG that there is something that TCP
cannot do. I see no reason why the IPS working group needs to
undertake rolling that rock up that hill.

If choice 2 was the motivation, then Class 1 should be listed
in the FC Encapsulation draft because somebody someday might
want to design a suitably inventive protocol for transporting
FC Class 1 over TCP and the FC Encapsulation should not be
a road block to that effort.

> Even if we do decide to accept Ralph's arguments to include 
> class 1 and class 4 SOF/EOF codes, we cannot take ALL the codes 
> from FC-BB and incorporate them into the FC Encapsulation draft.
> Recall, we started out by including all the SOF/EOF codes from 
> FC-BB-2.  We reevaluated in January 2001, when we analyzed the 
> codes themselves. Several that we excluded I think were valid 
> (e.g. for class 1 and class 4), but others were completely bogus 
> and undefined anywhere other than in FC-BB. We cannot just blindly 
> accept those codes. If this motion is considered, we need to reopen 
> that evaluation made in the January interim meeting and make a 
> determination as to what codes need to be included in FC Common 
> Encapsulation, and make sure not to include invalid codes.

It is most unfortunate that, in the ten months since all those 
bogus codes were discovered, not one attempt has been made in
T11 to correct those errors. None the less, the lack of corrective
action in T11 suggests that there are far fewer problems with
bogus codes than the above diatribe suggests.

However, I am not opposed to keeping demonstrably nonsense
SOF/EOF codes out of the FC Encapsulation draft. SOF/EOF
codes related to the various classes of service DO NOT
fall into the bogus category.

>  (Participant mode)I disagree with this motion. 

Please reconsider your opposition to this proposal.

Thanks.

Ralph...