SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: FCencap: List ALL SOF/EOF codes



    Ralph:
    
    I did a quick check with the FC-FS list of codes against the ones listed in
    FC-BB-2 Rev. 5.1 and found that all FC-BB-2 SOF and EOF codes defined in
    Tables A.3 and A.4 are legal and only defined for Class 2, 3, and F.
    
    The following codes which appear in a separate OS table  A.1 are not defined
    in FC-FS and I guess that makes them illegal:
    SOFc2
    SOFc3
    SOFcf
    SOFnf
    
    I guess you can still pick up tables A.3 and A.4 safely which are legal and
    only define Class 2, 3, and F.
    
    -Murali
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ralph
    Weber
    Sent: Friday, November 09, 2001 8:24 AM
    To: IPS Reflector
    Cc: Elizabeth Rodriguez; Murali Rajagopal
    Subject: Re: FCencap: List ALL SOF/EOF codes
    
    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...
    
    


Home

Last updated: Fri Nov 09 14:17:40 2001
7700 messages in chronological order