Subject: iFCP: Minutes authors' confcall Fri November 30th

From: "Franco Travostino" <[email-masked]>
Date: Tue, 04 Dec 2001 10:49:34 -0500

Attendees:

Charles Monia, Nishan Systems
David Robinson, Sun Microsystems
Mark Edwards, Eurologic
Franco Travostino, Nortel Networks

Much of this session was devoted to address David Black's comments. Some of 
his comments have already been addressed in the latest iFCP draft (07.txt) 
submitted to IETF at SLC cutoff date.

1) What's new in 07.txt
CM quickly described the changes that made it in (see trailing list of 
changes for reference). None of these changes were controversial. Security 
and QoS changes were left for later discussion (see 2.4, 2.5).

2) Open issues wrt David Black comments

2.1) CM recalled why the use of an IP address to identify a remote gateway 
needs to be reconsidered. The ensuing discussion reaffirmed CM's motion 
that we need to attach that gateway's TCP port number to the definition of 
N_PORT network address. iSNS supplies port information as part of the query 
response.

2.2) Broadcast support. The existing definition has weaknesses in 
reliability and fragmentation (IP fragmenetation being problematic with 
firewalls and NA(P)T devices more than anything else). CM's motion to move 
(back) to TCP was unanimously agreed upon. Discussion arose regarding the 
nature of TCP connections, static vs. dynamic. DR highlighted the 
scalability merits of a publisher/subscriber approach to the broadcast 
service---e.g., use this flow to send me data whenever there is a 
broadcast). Liveness of the flow may be an issue. TCP_KeepAlive being 
frowned upon for some good reasons, it appears that we are better off using 
a liveness token of our own design (a message structure closely related to 
the current CBIND).

2.3) Stale frame propagation. CM described the consequences of using 
propagation delay estimates that are either too high or too low. FT 
recalled that there exist feasibility proof points based on IntServ or 
DiffServ, wherein an upper bound for IP propagation delays can be 
established with good confidence. Still, we need to define stale-frame 
ground rules that can be applied to the capital-I Internet as well, no 
matter how severe these rules turn out to be when the IP propagation delay 
exceeds the estimated value. In addition to the requirement for discarding 
stale frames, there was consensus for an option to terminate any 
outstanding session upon observing non-conforming propagation delays. ME 
mentioned that MIBs can help with cumulative statistics of mean and maximum 
propagation delays. FT noted that stale frame semantics are germane to FCIP 
too.

2.4) Security. FT described the security changes that made it to 07.txt. 
Those changes were prompted by either the Aboba draft or David's comments. 
Among things, we now endorse David's hard line against DES, thus overriding 
IPsec normative text. In the minimal policy section, text was added to 
indicate that a gateway SHOULD at least authenticate its iSNS server. 
Certificate text is still missing, and, to the best of our knowledge, is 
the only TBS item in the whole security section. FT also noted that the 
Aboba draft is now a standard track document. The Chairs have not yet 
described the bearings of this resolution on the individual encapsulation 
documents, and their security sections (i.e., they stay or not). The 
authors' preference to keep the security sections in the encapsulation 
documents has been brought forward to AD/Chairs in several instances.

2.5) QoS. FT reported that MPLS is now mentioned with an adequate context, 
after clarifying David's review comment. The use of SLA was discouraged, in 
that the A of SLA has undesired connotations (legal ones and such). David 
proposed to use SLS and TCS, DiffServ's new terms for SLA. SLS and TCS 
appear to be DiffServ specific, however, whereas the QoS section in iFCP is 
entirely DiffServ agnostic. For further research.

2.1, 2.2, 2.3, and 2.4 are on the agenda for SLC.

-franco

Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: [email-masked]

Major changes in 07:
Section 11, Security -- Updated to reflect the latest security text
specified in
http://www.ietf.org/internet-drafts/draft-ietf-ips-security-05.txt
Section 12, QoS -- Updated per review comments and subsequent reflector
discussion.

Minor changes in 07:
iSNS -- Added new section 5.3 describing the role of iSNS.
4.4a) -- Added FC Node definition
4.7.1 -- Added description of address assignment for fabric-attached loops.
4.8 -- Added description of class 4 and class 6 transport services.
4.9 -- Added description of FC logins.
Figure 7 -- Changed "IP fabric" to "iFCP fabric."
5.2.1 -- Added description of how supported transport services are
discovered by an N_PORT.
PP 20 -- Corrected specification of requirements for Address-translation and
Address-transparent modes.
5.3.1.1 -- Added material describing use of iSNS for domain I/D assignment
in address-transparent mode.
5.3.1.2, 5.3.2.3 -- "SHALL" added to requirements for rejecting incoming
frames having incorrect address mode.
6.2.2.1 -- Corrected per review comment
6.2.2.2, "Use of TCP Features" -- Revised per review comment
6.2.2.3, "Error Recovery and Cold Start" -- Deleted per review comment
Sections 7 and 8 -- Order reversed per review comment
6.2.3 -- Identified entity being terminated or aborted (iFCP session) per
review comment
6.3 -- Qualified reference to point to appendix B of RFC 1323
7.3 and 7.3.7 (PLOGI) -- Terminology: Augmented ELSs are now referred to as
"Special" ELSs.
7.3.5 -- Fixed description of FARP-REQ.
7.3.8 -- Deleted description of REC ELS.
7.4, table 4 -- Modified table per review comment to delete references to
"y" entry types.
8.1 -- Added Connection Handle reference.
Appendix A -- Summary of Link Services. Deleted Link Services removed from
FC-FS spec.
Appendix B -- Deleted. Spec will be revised to include a reference to
published material.