Re: FCencap: List ALL SOF/EOF codes

["Franco Travostino" <travos@nortelnetworks.com>]

I vote for 3) as well. I still feel it would be useful to have a sentence
in the introductory scope section (1.) to crisply define the FC
scope  (and discourage anyone else from falling into this rathole).
Minimally, such sentence could be a forward pointer to the SOF table near
the end, with supporting T11 citations (including FC-MI if this is the
most authoritative doc we have got).

thanks
-franco

At 04:21 PM 11/13/2001, Ralph Weber wrote:
> I support option 3.
>
> Option 1 fails to reflect the reality of current T11 work on
> Class 4.
>
> Option 2 fails to consider the recent debate over iSCSI profiles. 
> The IETF position on profiles (as stated by the ADs during last 
> summer's debate) is that profiles must be stated as requirements 
> in RFCs. Therefore, the T11 FC-MI carries the weight of a standard 
> in the IETF and the FC-MI interoperability prohibition for Class 1
> must be stated in the FC Encapsulation. (Either that or those 
> folks wanting to write iSCSI profiles can resharpen their pens
> for round two.)
>
> Option 4 attempts to link the good works of option 3 with
> the bogus concept of profiles in option 2, which makes it
> every bit as bogus.
>
> Murali's option 5 guarantees that there will be no RFC on
> FC Encapsulation until 2003 since there will be no FC-BB-2
> standard to reference until then.
>
> Thanks.
>
> Ralph...
>
> Elizabeth Rodriguez wrote:
>
> >
> > (Chair hat on)
> >
> > Let me jump back in here, and summarize as I see it:
> >
> > Codes from FC-BB cannot be taken intact, since there are invalid
> codes
> > in that specification.
> > Codes initially trimmed in January of this year, but Ralph
> correctly
> > points out, that was prior to the formation of the FC
> encapsulation
> > draft (e.g. discussion pertained directly to FCIP; did not take
> into
> > consideration iFCP)
> >
> > That said, we can modify the current FC encapsulation draft to
> include
> > other classes of service, if we so choose.
> >
> > We can choose to
> > 1) Keep the table as is.
> > Note: The current SOF/EOF codes defined in the FC encapsulation
> draft
> > match the currently defined FC-BB-2 subset.
> >
> > 2) Add Class 1 codes
> > Note:  FC-MI (technical report, not a standard) does not
> support Class
> > 1.
> > Note2: Practicality of Class 1 over IP questioned.
> >
> > 3) Add Class 4 codes
> > Note:  Class 4 work is ongoing, but SOF/EOF codes currently
> defined for
> > class 4 unchanged.
> >
> > 4) Add both class 1 and class 4 codes
> >
> > I would like to solicit input from everyone on what codes people
> feel
> > should be included in the FC encapsulation draft.
> > Note:  Drafts following FC encapsulation may restrict classes
> of service
> > that draft supports.
> >
> > Thanks,
> >
> > Elizabeth
> >
> > -----Original Message-----
> > From: Murali Rajagopal
> [mailto:muralir@lightsand.com]
> > Sent: Monday, November 12, 2001 6:01 PM
> > To: Charles Monia; IPS Reflector
> > Subject: RE: FCencap: List ALL SOF/EOF codes
> >
> > On the specific topic of supported SOF and EOF codes the ietf
> documents
> > should be driven by the specification provided in the *most relevant
> *
> > document which in this case happens to be FC-BB-2 ant FC-MI. 
> FC-MI
> > should
> > be kept out of this.
> >
> > If we simply accept to adopt the SOF and EOF codes listed for BB-2
> the
> > problem is solved. FYI, BB-2 only supports Class 2, 3, and F
> codes.
> > I don't see why we are making a big deal about this.
> >
> > -Murali
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu
> [mailto:owner-ips@ece.cmu.edu]On
> Behalf Of
> > Charles Monia
> > Sent: Monday, November 12, 2001 3:33 PM
> > To: IPS Reflector
> > Subject: RE: FCencap: List ALL SOF/EOF codes
> >
> > Hi Folks:
> >
> > > David's observation is correct. FC-MI rev 1.8 (28 Sept
> 2001)
> > > prohibits Class 1 and I can find no letter ballot 
> comments
> > > asking that it be reinstated.
> >
> > The last time I checked, the FC-MI spec was not a "standards
> track"
> > document
> > (to use IETF terminology). If that's still the case, is 
> FC-MI's
> > prohibition
> > of class 1 a sufficient basis for precluding class 1 support in
> the
> > encapsulation spec?
> >
> > Charles
> > > -----Original Message-----
> > > From: Ralph Weber
> [mailto:ralphoweber@compuserve.com]
> > > Sent: Saturday, November 10, 2001 8:52 AM
> > > To: IPS Reflector
> > > Cc: Black_David@emc.com
> > > Subject: Re: FCencap: List ALL SOF/EOF codes
> > >
> > >
> > > David's observation is correct. FC-MI rev 1.8 (28 Sept
> 2001)
> > > prohibits Class 1 and I can find no letter ballot 
> comments
> > > asking that it be reinstated.
> > >
> > > Therefore, I am forced to agree with David. Class 1 MUST
> NOT
> > > be mentioned in the FC Encapsulation draft. If necessary,
> a
> > > note discussing interoperability and FC-MI can be added.
> > >
> > > Thanks.
> > >
> > > Ralph...
> > >
> > > Black_David@emc.com wrote:
> > >
> > > > FC-MI was going to prohibit Class 1 last time I
> checked.  Since the
> > > > I in FC-MI stands for "Interoperability", this
> seems like a
> > > reasonable
> > > > rationale for excluding Class 1 service.
> > > >
> > > > --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
> > > > ---------------------------------------------------
> > >