Re: FCIP: Comment 120

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

Ralph,

Let's look at issues carefully.

>were told that we
> had to stop relying on knowing the exact IP Address and Port to decide
> the end points of the FCIP Links. 

Which was exactly what I pointed out - you're using the "IP Address and Port 
to decide the end points of the FCIP Links" now (the end point is FC/FCIP 
Entity Pair, and which the FSF doesn't identify).

> Furthermore, I repeat what I said originally and you conveniently
> ignored:

I ignored it because it has no merit.  Please tell me a specific problem with 
"SLP, IPsec, IKE, and goodness knows what else".  My experience with iSCSI 
is that it did not have any issues with the concept of multiple iSCSI Nodes within 
one Network Entity sharing the same Portals - conceptually identical to the multiple 
FC/FCIP Entity Pairs within one FC Fabric Entity.  

> conclusion that nothing is stable in an IP Network and SLP doesn't work.

I'm surprised about this claim.

Address volatility is something all networked storage lives with, and O/Ses know
how to live with - this is true at several levels.
    - FC (Nport_ID volatility due to changed fabric ports, fabric merges etc.)
      Solution: use FC WWN (and RSCN) to ensure you're talking to the right entity.
    - iSCSI (IP_address & portal group volatility due to node reconfiguration, changed
      IP addresses etc.)  
      Solution: use iSCSI Node/Port name (and SLP advertisements) to ensure you're 
      talking to the right entity.
    - LUN (changed LU "views", changed authentication credentials etc.)
      Solution: use WWU-device identifiers (and UA "REPORTED LUNS DATA
      HAS CHANGED")  to ensure you're talking to the right LU.

To make my original point very clear, FCIP allows certain architectural possibilities
today and I don't see all the possibilities being completely addressed one way or the
other in details (such as FSF).  If you want to exclude certain possibilities, please
do so explicitly and state why.
--
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@ece.cmu.edu>
Cc: "Mallikarjun C." <cbm@rose.hp.com>
Sent: Wednesday, May 08, 2002 7:46 PM
Subject: Re: FCIP: Comment 120


> Mallikarjun,
> 
> > Besides, I don't see anything in the current document that prohibits multiple
> > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe
> > that is the right architectural approach.
> 
> In the Orange County meeting, the FCIP contributors were told that we
> had to stop relying on knowing the exact IP Address and Port to decide
> the end points of the FCIP Links. We were NOT told that we had to
> allow multiple FC/FCIP Entity Pairs to share a single IP Address/Port.
> In fact, I believe we were told that we could proceed using such
> an assumption.
> 
> We have followed what we were told to do.
> 
> If you are authorized to change the rules on us again, so be it. But 
> for sure, I will need need to hear that FCIP is getting jerked around 
> again by the IETF from a higher authority.
> 
> Furthermore, I repeat what I said originally and you conveniently
> ignored:
> 
> > > The only alternative would be to REQUIRE SLP interrogation before every
> > > TCP connect request, and even then there would be zero assurance that
> > > the IP universe would not shape shift between the SLP activities and
> > > the TCP connect request.
> 
> As far as I can tell, the basis for your argument yields the unmistakable
> conclusion that nothing is stable in an IP Network and SLP doesn't work.
> Frankly, that is beyond belief.
> 
> .Ralph
> 
> "Mallikarjun C." wrote:
> 
> >
> > > I would think that sending a TCP connect request to the same IP Address
> > > and Port as was used in the previous TCP connect request would achieve
> > > the intended result.
> >
> > Not a correct assumption.  You are using names (FC Fabric Entity WWN is
> > a name.  The FC/FCIP Entity Identifier is a name unique within the scope of
> > the FC Fabric Entity.) in FSF only because IP addresses/TCP port associations
> > cannot provide the FCIP-end2end assurance that the right entities are talking.
> >
> > Besides, I don't see anything in the current document that prohibits multiple
> > FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe
> > that is the right architectural approach.
> > --
> > 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@ece.cmu.edu>
> > Cc: "Mallikarjun C." <cbm@rose.hp.com>
> > Sent: Wednesday, May 08, 2002 6:26 AM
> > Subject: Re: FCIP: Comment 120
> >
> > > "Mallikarjun C." wrote:
> > >
> > > > Upon further thought, it appears to me that the "Destination FC/FCIP
> > > > Entity Identifier" should be sent and received in the FSF.  I can not
> > > > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs
> > > > - for ex., how would a sender indicate his intention to add a TCP
> > > > connection to an FC/FCIP Entity Pair that it's already communicating
> > > > with?
> > >
> > > I would think that sending a TCP connect request to the same IP Address
> > > and Port as was used in the previous TCP connect request would achieve
> > > the intended result.
> > >
> > > The only alternative would be to REQUIRE SLP interrogation before every
> > > TCP connect request, and even then there would be zero assurance that
> > > the IP universe would not shape shift between the SLP activities and
> > > the TCP connect request.
> > >
> > > Surely, there is some stability in IP addressing.
> > >
> > > Thanks.
> > >
> > > .Ralph
> > >
> > >
> 
>