Subject: RE: FCencap: List ALL SOF/EOF codes

From: "Franco Travostino" <[email-masked]>
Date: Fri, 09 Nov 2001 09:36:51 -0500

If one cannot enumerate the legitimate SOF/EOF codes as of 00:00 on Nov. 09 
2001, then there is a standard body out there (not this one :-) with a big 
problem on its hands. I would hate to see this problem propagating into our 
IETF document, or being an excuse for any vague text of ours. Should new 
SOF/EOF codes emerge, and should there be enough IP interest around them, 
it should not be a problem to reissue a new FC common encapsulation 
specification with just new SOF/EOF codes, and the stale RFC will be marked 
as obsoleted by RFCxxx.

-franco

At 01:05 PM 11/8/2001, Elizabeth Rodriguez wrote:
>(Participant mode)
>
>I disagree with this motion.
>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.
>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.
>
>Thanks,
>
>Elizabeth
>-----Original Message-----
>From: Franco Travostino [mailto:[email-masked]]
>Sent: Wednesday, November 07, 2001 9:32 AM
>To: [email-masked]; IPS Reflector
>Cc: Murali Rajagopal; Elizabeth Rodriguez
>Subject: Re: FCencap: List ALL SOF/EOF codes
>
>I agree with this motion.
>
>You wrote under another heading: "Vague may be vague but it also is not 
>unnecessarily constraining." What a troubling statement was this. I'm glad 
>we now appear to be moving towards a constructive end after all.
>
>thanks
>-franco
>
>At 08:15 AM 11/7/2001, Ralph Weber wrote:
>>Upon further reflection, I think the right thing to do
>>is to list all the SOF/EOF codes defined in FC-BB in
>>the FC Encapsulation draft.
>>
>>FIRST
>>
>>There is nothing in the FC Encapsulation draft other
>>than to omission of Class 1 SOF/EOF codes that prevents
>>encapsulating FC Class 1 frames for TCP transport.
>>Sure, a TCP ULP that is smarter than anything anybody
>>has thought about will be required to do it.  BUT
>>there is (or should be) nothing the the FC Encapsulation
>>draft that prevents such a protocol from being invented.
>>AND the FC Encapsulation draft specifically says that
>>you need the wisdom of some other protocol document in
>>order to get any use out of the FC Encapsulation draft.
>>Why force the mad man that devises a way to transport
>>Class 1 over TCP/IP to revise the FC Encapsulation
>>SOF/EOF tables?
>>
>>SECOND
>>
>>It is conceivable that a future version of iFCP
>>(or maybe even FCIP) might want to support Class 4.
>>Again, there is nothing in the FC Encapsulation
>>draft that prevents this, except the omission
>>of the SOF/EOF codes.
>>
>>FINALLY
>>
>>I believe that the elimination of all SOF/EOF
>>codes other than Class 2, Class 3, AND CLASS F
>>is a hold over from the early FCIP work, before
>>the FC Encapsulation was split into a separate
>>draft. I believe that decision was right for
>>FCIP but wrong for an FC Encapsulation intended
>>to be used by ALL FC protocols running over
>>TCP/IP.
>>Thanks for your consideration.
>>
>>Ralph...

---

From: [email-masked]
Date: Mon, 12 Nov 2001 12:25:05 -0500

Please add the note of explanation with a pointer to FC-MI
so the next person who wonders about the absence of Class 1
is presented with a pointer to the answer.  Thanks, --David

> From: Ralph Weber [mailto:[email-masked]]
> Sent: Saturday, November 10, 2001 11:52 AM
> To: IPS Reflector
> Cc: [email-masked]
> 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...
> 
> [email-masked] 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
> > [email-masked]       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
>

---

From: "Elizabeth Rodriguez" <[email-masked]>
Date: Tue, 13 Nov 2001 13:40:06 -0500

Charles, Franco
(and others interested in iFCP)
Murali's statement below does apply to the FCIP draft.
Do you feel the statement also applies to iFCP?

Elizabeth

-----Original Message-----
From: Murali Rajagopal [mailto:[email-masked]]
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: [email-masked] [mailto:[email-masked]]On Behalf Of
Charles Monia
Sent: Monday, November 12, 2001 3:33 PM
To: IPS Reflector
Subject: RE: FCencap: List ALL SOF/EOF codes

> 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
> Sent: Saturday, November 10, 2001 8:52 AM
> To: IPS Reflector
> Cc: [email-masked]

---

From: Robert Snively <[email-masked]>
Date: Tue, 13 Nov 2001 14:45:14 -0800

I vote option 3.

Ralph's reasoning is valid.

---

From: Charles Monia <[email-masked]>
Date: Tue, 13 Nov 2001 14:52:16 -0800

Hi Elizabeth:

The iFCP spec explicitly lists the SOF/EOF codes accepted by the protocol
and the actions to be taken if other codes are received.

Charles
> From: Elizabeth Rodriguez [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 10:40 AM
> To: Murali Rajagopal; Charles Monia; IPS Reflector