Minutes from FCIP concall 1/9/02

["Andy Helland" <andyh@lightsand.com>]

Attendees
Anil Rijhsinghani, Elizabeth Rodriguez, Larry Lamers, Ralph Weber, Neil
Wanamaker, Murali Rajagopal, Jim Nelson, Milan Merhar, Kha Sin Teow, Bill
Krieg, Dave Peterson, Don Fraser, Bob Snively, Raj Bhagwat, Venkat Rangan,
Bret Ketchum, and Andy Helland (designated scribe)

----------------------------

Agenda
agreed to as follows

1) Discussion on FCIP Requirements to FC-BB-2

2) Comment resolution

- Bill
- Murali
- Neil

3)  Other New Business

3)  Next Call Host and Time

---------------------------
FC-BB-2 issues for T11 Huntington Beach that involve FCIP

Ralph will address BB-2 Requirements for Special Frame Security Proposal.

Bret Ketchum will bring a "B_Port" proposal.

--------------------------

Murali's comments

Clarification needed for Section 4, Item 14:

"This specification relies on both TCP and FC error recovery mechanisms to
detect and recover from data loss and corruption within the IP Network."

I think the intent of this item and what is written might have been
different. Perhaps the following will mend this sentence:

"On a given TCP Connection, this specification relies on TCP to detect and
recover from data loss and corruption within the IP Network. This
specification, also describes other mechanisms to detect data corruption
causing loss of synchronization not detected by TCP."

I am not clear why we need to mention the part about FC errory mechanisms in
this context.

Discussion regarding error recovery and the need (or lack of need) for FC
based error recovery in FCIP.

text amended to read:

"14) This specification contains only limited error detection and
recovery mechanisms and relies on both TCP and FC to handle data loss
and corruption within the IP Network."

--------------------------

Murali's comments

Clarification on Section 4, Item 10:

10) Each FCIP Entity is statically or dynamically configured with a
       list of IP addresses and port numbers corresponding to
       participating FCIP Entities. If dynamic discovery of
       participating FCIP Entities is supported, the function SHALL be
       performed using the Service Location Protocol (SLPv2) [24]. It
       is outside the scope of this specification to describe any
       static configuration method for participating FCIP Entity
       discovery. Refer to section 8.1.4 for a detailed description of
       dynamic discovery of participating FCIP Entities using SLPv2.

I am not sure what port numbers we are refering to in the above.


Text amended to explicitly call out "TCP" port numbers

--------------------------
Neil's comments


1. first sentence. FC is no longer limited to gigabit speeds. Suggest
"...gigabit or multi-gigabit..."

3. last sentence. Rather than "..used by the FCIP protocol", perhaps
"...used during FCIP connection establishment and authentication".

5.1 Last sentence. I'd argue that the objective is to transport data between
E_Ports over an IP link. Creation and maintenance of FCIP links does not
sound like a constructive activity.

5.3 second paragraph, last sentence. I don't believe that "loop primitive
signals cannot be encapsulated for transmission over TCP.". Maybe we chose
not to, and there are lots of good reasons not to do it, but cannot??

5.6.1 last sentence on page 15. Change "Word 1 of the Protocol Specific
Field" to "The first word of the Protocol Specific Field".

Table 1 Note 1. Change to "...changes resulting from transmission errors..."

6. Replace the first sentence with "The FC entity SHALL implement the
measurement of Fibre Channel frame transit time as described in section 4 of
FC Frame Encapsulation [26]." The "setup" and "verification" components of
the frame transit time function are not readily identifiable, nor is it
clear what parts of [26] section 4 that are not required.

6. A note as to the reason for sending/accepting frames without timestamps
might be useful here.

Fig 9. The notation for word 3 is confusing. At first reading I took the
fields to represent ranges rather than the contents of separate bytes. Even
3F for -Flags is somewhat unnatural (FC anyone???).

7. last paragraph. The paragraph reads as though the first list of contents,
as well as the "other new connect information" comes from the connection
request; perhaps rather than "for each new incoming TCP connection request
received" say "when an FCIP special frame is received"


Results from discussion:

1)  add reference to higher than Gigabit per second rates

3)  remove Section 3 (Terminology) definition of SF

5.1)  Comment accepted.  Text amended to reflect the real purpose is the
transort data...

5.3)  Not accepted.

5.6.1)  Not accepted.

Table 1, Note 1.  Typo error.  Comment accepted.

6)  Issue #1.  Accepted.  Change SHALL to MUST.

6)  Issue #2.  Not accepted.

9)  Ralph will get out his Dart Board and randomly add some obscure base
notation (perhaps binary is best...).  On a more realistic note, check out
RFC 1483.

7)  Add text "and subsequent special frame".  Ralph will continue
wordsmithing.

------------------------

Murali's comments.

Item 10 is a good summary of the supported "Discovery methods".

I was hoping for a brief summary about what information is learnt from such
a discovery process.
A proposed item that might follow item 10  could be:

 New 11) Before creating a TCP Connection to a peer FCIP Entity, the FCIP
Entity shall statically or dynamically determine the IP address, expected FC
Fabric Entity World Wide Name, TCP Connection Parameters, and Quality of
Service Information.

Or you could combine this with existing Item 10.

One other point of clarification:
 Section 8.1.3 states that a discovering the need for a new TCP connection
for the non-dynamic case. How is need made known?


Comments accepted.

------------------------

Bill Krieg's comments.

While reading through the draft I have the following observations to make:

1. In section 3 the definitions for "FCIP Data Engine" and "FCIP Link
Endpoint" are nearly identical.  I suggest that we clarify the "FCIP Link
Endpoint" definition to state something like:

	FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity that
	contains one or more FCIP_DE's (see section 5.5).

2. In section 3 the definition of "Special Frame" could be extended to help
identify its role.  Suggested text to be added at the end of the definition
is:

	".....during the TCP connection setup phase (see section 7)."

3. just a nit ... I would suggest renaming section 4 to something like "FCIP
Protocol Overview".  "Protocol Summary" doesn't seem to clearly identify the
section.

4. The wording on the left side of Fig. 6 in section 5.6 should be change
from "Fibre Channel" to "FC Entity" if we want to maintain continuity with
Fig. 5.

5. Section 7 Figure 10 and the following text should be updated to include
class 4 (SOF?4) values.

Comments accepted.

------------------------

Reference David Black email to IPS reflector (1/8/02 2:58 PM)

Ralph will add annex to describe race condition.

------------------------

Discussion of "Author Lists growing in size"

Vote taken by Authors.  Unanimous consensus of FCIP authors that all current
authors (as of FCIP r07c) have made substantial contributions to the FCIP
RFC and should remain on list.  Unanimous consensus that Bill Krieg (Lucent)
should be added to author's list.  (Welcome aboard, Bill!)

------------------------------

Ralph will release FCIP r07d on 1/10/02.  Comments from authors MUST be
received by Ralph NLT Friday 1/12/02 12:01 PM CST.

--------------------------------

Next Concall will be Tuesday 1/15/02.  1:00 PM PST.  Duration 1 hour.
Primary Topic: Security (Venkat).  Bill Krieg to make arrangements and take
minutes.


-Andy