RE: FCEncap Last Call Comment 39

[Charles Monia <cmonia@NishanSystems.com>]

My .02:

The purpose of FCencap is to specify an encapsulation mechanism without
making assumptions about the nature or constraints of the environment in
which the encapsulating protocol operates.  For that reason, FCencap ought
not to be prescribing such policies.

Charles
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, April 01, 2002 12:42 PM
> To: roweber@acm.org; IPS Reflector
> Subject: FCEncap Last Call Comment 39
> 
> 
> 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.   
>