Re: FCEncap Last Call Comment 39

["Mallikarjun C." <cbm@rose.hp.com>]

Ralph,

Thanks for the clarification, I didn't know about Class F
frames.

Now that I am aware of Class F frames, I am interested in knowing 
if the authors considered barring Unsynchronized operation with the 
exception of Class F frames (or perhaps "in all cases where the R_A_TOV
expectaction is not imposed by FC-FS").

I guess it still bothers me that the wording is not restrictive enough to 
rule out surprise class 2/3 frames that should have long gone....

Responding to Charles:
> My .02:
> 
> The purpose of FCencap is to specify an encapsulation mechanism without
> making assumptions about the nature or constraints of the environment in

FCencap is designed for FC-FS-compliant environments at any rate, and I am
suggesting that FCencap also say what every encapsulating protocol would 
need to do to meet these expectations. 

Each encapsulating protocol, OTOH, could choose to individually state the "except 
Class F" (or something similar) requirement.  IMHO, all encapsulating protocols claiming 
transparency on the FC side must stipulate something along these lines...

> which the encapsulating protocol operates.  For that reason, FCencap ought
> not to be prescribing such policies.
> 

In any case, I would leave it here for others to comment on if they see it an issue...
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Ralph Weber" <ralphoweber@compuserve.com>
To: "IPS Reflector" <ips@ece.cmu.edu>
Sent: Monday, April 01, 2002 1:54 PM
Subject: Re: FCEncap Last Call Comment 39


> Mallikarjun,
> 
> FCIP and FC-BB-2 allow Class F frames to transit
> while in the Unsynchronized state. All other
> Classes of frames cannot transit while in the
> Unsynchronized state.
> 
> I may get corrected by those more versed in Fibre
> Channel, but I believe that Class F frames can
> transit while in the Unsynchronized state because
> they are exchanged only between adjacent switches.
> 
> It is certainly true that Class F frames MUST be
> allowed to transit while in the Unsynchronized
> stated because they are REQUIRED to setup the
> Fiber Channel Time Service, which is a prerequisite
> for time stamping frames.
> 
> Hope this helps.
> 
> Ralph...
> 
> "Mallikarjun C." wrote:
> 
> > Ralph,
> >
> > Thanks for the response.  Query below.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
> > cbm@rose.hp.com
> >
> > > Comment 39 Technical
> > >
> > >    - I think it might be useful to add a statement in this section along
> > >      the lines of - If the encapsulating protocol mandates Synchronized
> > >      operation, the entity MUST NOT accept TCP connections on the well-
> > >      known port(s) unless the entity is in the Synchronized state.
> > >
> > >    Rejected
> > >
> > >    Since encapsulating protocols are allowed to specify operation in
> > >    the Unsynchronized state, specifying this level of detail about how
> > >    Synchronized operation is handled over reaches the bounds of this
> > >    specification.
> >
> > This is a query to FCEncap as much as it is to FCIP and iFCP.
> >
> > I don't claim to be well-versed with the latest FC specs, but my understanding
> > is that the R_A_TOV represents a hard requirement placed on FC fabrics in terms
> > of life expectancy of the FC frames.  If it is indeed so, then could you please
> > explain how Unsynchronized operation with its non-deterministic frame lifetime
> > in the "fabric" could be legal for any encapsulating protocol?
> >
> > I struggled with the same question in my reviewing of FCIP and iFCP as well,
> > and would appreciate a clarification.
>