Subject: FCIP: Comment 120

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 3 May 2002 19:25:51 -0700

Ralph,

> http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-01.pdf
....
> Please review these comments resolutions to ensure that
> the desired changes are described.

Sorry for the delayed review, I have additional comments on wglc-01
for Comment 120.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

>Comment 120
>> 8. The FCIP Special Frame
>......
>> Note: The combination of the Source FC Entity World Wide Name and
>> Source FCIP Entity Identifier fields uniquely identifies every FC
>> Entity FCIP Entity pair in the IP Network.
>....
>- Also I take it that the "FC/FCIP Entity Identifier" is unique only
>within the scope of the given FC Entity's WWN. So, does the model
>allow multiple FCIP Entities to be associated with the FC Fabric
>Entity WWN?
>....
>Response to the second bullet: Yes, the "FC/FCIP Entity Identifier"
>is unique only within the scope of the given FC Entity's WWN. Yes,
>the model allows multiple FCIP Entities to be associated with the FC
>Fabric Entity WWN.
>

If that is so, please add an architectural model diagram (similar to
Figure 3, or perhaps convert Figure 3 into) which clearly shows this 
1-to-n association.

This is the only hint in the document (at least that I found) which
suggests the stated possibility.  Figure 3 with 1-to-1 association almost 
seemed like the architectural model, but on careful reading, is only 
an example.

---

From: Ralph Weber <[email-masked]>
Date: Mon, 06 May 2002 09:35:40 -0500

Mallikarjun,

> >... the "FC/FCIP Entity Identifier" is unique only within the scope 
> >of the given FC Entity's WWN. ... the model allows multiple FCIP 
> >Entities to be associated with the FC Fabric Entity WWN.
>

The fact that the "FC/FCIP Entity Identifier" is unique only within
the scope of a given FC Entity's WWN seems to be clearly stated in the
definition of the field:

  "The Source FC/FCIP Entity Identifier field SHALL contain a unique 
  identifier for the FC Entity FCIP Entity pair that generates (as opposed 
  to echoes) the Special Frame. The value is assigned by the FC Fabric 
  entity whose world wide name appears in the Source FC Fabric Entity World 
  Wide Name field.

  "Note: The combination of the Source FC Entity World Wide Name and Source 
  FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP 
  Entity pair in the IP Network."

The requested figure relies on Fibre Channel concepts and thus appears
in a T11 document, FC-BB-2, ftp://ftp.t11.org/t11/pub/fc/bb-2/02-030v1.pdf.
See Figure 23 on PDF page 87, or Figure 26 on PDF page 94.

Thanks.

.Ralph

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 6 May 2002 10:45:58 -0700

Ralph,

> See Figure 23 on PDF page 87, or Figure 26 on PDF page 94.

Thanks for the reference, but unfortunately it doesn't help make the point 
that there is 1-to-n association between FC Entity and FCIP Entity.

Given that FCIP is an RFC that defines these Entities and their relationships
in its own right, my suggestion would continue to be that the association be depicted 
in an architectural model diagram.  It could be as simple as showing a shadow ASCII
box to the FCIP Entity box.  I will leave it here up to you and Co-Chairs to make
the call.  

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: Ralph Weber <[email-masked]>
Date: Mon, 06 May 2002 15:29:11 -0500

Mallikarjun,

Oops! This mistake is on me.

The Source FC Fabric Entity World Wide Name field DOES NOT contain the
WWN of the FC Entity. Rather, it contains the "Fibre Channel Name_Identifier 
[FC-FS] for the FC Fabric entity associated with the FC Entity FCIP Entity
pair."

Two corrections are needed in the picture that I led you to believe in:

   1) The "FC Fabric entity" IS NOT the FC Entity, it is the FC product
      (switch or whatever) that contains one or more FC Entities; and
   2) There is no 1-to-n relationship between FC Entities and FCIP Entities,
      in fact, they come in 1-to-1 one matched pairs.

Note that these corrections further strengthen the argument that the
1-to-n discussion belongs in FC-BB-2, since the multiplicity relationship
really is farther inside FC constructs than I first suggested.

Hope this helps.

.Ralph

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 6 May 2002 14:48:30 -0700

Ralph,

> Two corrections are needed in the picture that I led you to believe in:

Ah, thank you.  It's much easier to visualize the model now.

May I make a couple of recommendations based on this - 

- Please add a definition of the "FC Fabric Entity" to the Terminology 
  section (section 4).

- All the pictures (starting with Figure 3) show the FC Entity directly 
   talking to FC Fabric directly - the containment relationship wrt 
   FC Fabric Entity is not illustrated anywhere.  I'd recommend that
   at least one picture show FC Fabric Entity, and perhaps state that
   the same applies to all pictures even while not explicitly shown.  A
   reasonable alternative would be to refer to the T11 document's
   picture illustrating the containment relationship.  In either case, I 
   suggest the FCIP text state this.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 7 May 2002 10:55:52 -0700

Ralph,

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?

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: Ralph Weber <[email-masked]>
Date: Wed, 08 May 2002 08:26:30 -0500

"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

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 8 May 2002 10:15:30 -0700

> and Port as was used in the previous TCP connect request would achieve

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

---

From: Ralph Weber <[email-masked]>
Date: Wed, 08 May 2002 21:46:16 -0500

Mallikarjun,

> 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

> > the IP universe would not shape shift between the SLP activities and

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

---

From: Ralph Weber <[email-masked]>
Date: Wed, 08 May 2002 22:46:00 -0500

Mallikarjun,

> that is the right architectural approach.

the less I like it.

This seems like a poorly disguised attempt to force FCIP off its
design center, which is a collection of statically (or near statically)
configured FCIP Link endpoints.

Call FCIP hardware-centric if you like, but the idea that an FCIP
Entity controls its connection points through the IP Addresses and
Ports it announces (via SLP or otherwise) is fundamental to the
design and currently specified algorithms.

The idea that one first connects to a IP Address/Port and then
decides which FCIP Entity within it really wants to talk to
flies in the face of SLP usage, and (while Venkat is the security
expert not me) it seems like a potential security hole of the
highest magnitude. I seriously believe that this breaks the
authentication mechanism recently added to FC-BB-2 in support
of multiple TCP Connections in a single FCIP Link.

As I have noted before, the purpose of the Destination FC Fabric 
Entity World Wide Name field is to say, "This is the FC Fabric Entity 
I think I'm talking to; hang up if that is wrong." In other words,
the field serves as a check on the correctness of the IP Address
and Port used to make the TCP Connection.

The purpose of the field as currently designed definitely is not to 
say, "This is the FC Fabric Entity I want to talk to." That would
be using the FSF as an extension of the IP Addressing mechanism,
when all the FSF was ever intended to do is replace IP Address 
as an FCIP Entity identifier.

Surely, such a profound change in the design basis for FCIP 
connection setup, has implications that resonate far beyond
adding a field here or there or changing the usage of some
existing fields.

This path is bogus. It is inconsistent with substantial parts
of the current FCIP draft. If followed, it calls into question
the FCIP usage of SLP, IPsec, IKE, and goodness knows what else.
It is not "the right architectural approach". It is more like
trying to build a pagoda using Roman columns.

.Ralph

---

From: "Murali Rajagopal" <[email-masked]>
Date: Thu, 9 May 2002 10:42:01 -0700

Mallikarjun:

There is some text in FC-BB-2 (Clause 13.2. 3)  that may also add some
calrity to the discussion of sharing IP address:

" The FC-BB-2_IP Reference Model supports one logical IP Interface and
allows sharing a 4-byte IPv4 or 16-byte IPv6 address in the following ways:

a)A single IP address per FC-BB-2_IP device
  - A single IP address shared by all FC/FCIP Entity pairs
b) Multiple IP addresses per FC-BB-2_IP device
- A single IP address per FC/FCIP Entity pair
c) Multiple IP addresses per FC/FCIP Entity pair
- A single IP address per VE_Port/LEP pair

Use of two different IP address schemes at the two ends of an FCIP Link is
not expected to cause inter operability problems."

-Murali

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mallikarjun C.
Sent: Wednesday, May 08, 2002 10:16 AM
To: [email-masked]; [email-masked]
Subject: Re: FCIP: Comment 120

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 9 May 2002 16:15:33 -0700

Ralph,

Let's look at issues carefully.

>were told that we
> 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

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