iFCP: Minutes authors' confcall Fri November 30th

["Franco Travostino" <travos@nortelnetworks.com>]

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: travos@nortelnetworks.com

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.