Re: FCIP: Comment 120

[Ralph Weber <ralphoweber@compuserve.com>]

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
> >
> >