idnits 2.17.1 draft-ietf-ips-fcip-wglc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 38 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 19 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 348: '...ervices function MAY use TCP/IP qualit...' RFC 2119 keyword, line 367: '...ities is supported, the function SHALL...' RFC 2119 keyword, line 390: '...ing to create the TCP connection SHALL...' RFC 2119 keyword, line 462: '...n FC Fabric through an IP Network MUST...' RFC 2119 keyword, line 560: '... with: "however, REQUIRED TCP/IP funct...' (102 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The FCIP Entity SHALL wait indefinitely for the FC Entity to authenticate source of the TCP connect request and SHALL not use the new TCP Connection for any purpose until the FC Entity completes the authentication. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Change the cited text to: "The FCIP Entity SHALL not use the new TCP Connection for any purpose until the FC Entity authenticates the source of the TCP connect request." -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'E' on line 2956 looks like a reference -- Missing reference section? '27' on line 854 looks like a reference -- Missing reference section? '25' on line 368 looks like a reference -- Missing reference section? 'T' on line 1968 looks like a reference -- Missing reference section? '8' on line 2819 looks like a reference -- Missing reference section? '4' on line 2625 looks like a reference -- Missing reference section? '13' on line 1901 looks like a reference -- Missing reference section? 'SLPv2' on line 1487 looks like a reference -- Missing reference section? 'RFC2608' on line 1487 looks like a reference -- Missing reference section? '2409' on line 1505 looks like a reference -- Missing reference section? '14' on line 1623 looks like a reference -- Missing reference section? '16' on line 1638 looks like a reference -- Missing reference section? '18' on line 1660 looks like a reference -- Missing reference section? '17' on line 1662 looks like a reference -- Missing reference section? '7' on line 1890 looks like a reference -- Missing reference section? '11' on line 1891 looks like a reference -- Missing reference section? '22' on line 1892 looks like a reference -- Missing reference section? '23' on line 1893 looks like a reference -- Missing reference section? '24' on line 1894 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Working Group R. Weber 3 INTERNET-DRAFT 4 5 (Expires November, 2002) 7 FCIP 1st WG Last Call 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as Reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/lid-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 This ips (IP Storage) working group draft contains all the working 32 group last call comments received regarding: 34 draft-ietf-ips-fcovertcpip-09.txt 36 The proposed disposition of each comment also is recorded in this 37 draft. 39 Summary of Comments 41 Technical: 30 Comments, resulting in about 37 Changes 42 Editorial: 112 Comments, resulting in about 84 Changes 43 ------------------------------------------------------- 44 Totals: 142 Comments, resulting in about 121 Changes 46 Table Of Contents 48 1. Comments from David Black . . . . . . . . . . . . . . . . . . . 2 49 2. Comments from Mallikarjun Chadalapaka . . . . . . . . . . . . . 47 50 3. Comments from Don Fraser . . . . . . . . . . . . . . . . . . . 70 51 4. Comments from Murali Rajagopal . . . . . . . . . . . . . . . . 71 52 5. Comments from Bob Snively . . . . . . . . . . . . . . . . . . . 71 53 6. Comments from Ralph Weber . . . . . . . . . . . . . . . . . . . 72 55 1. Comments from David Black 56 ========================= 58 Comment 1 60 ----- Title Page ----- 62 E. Rodriguez, ips Liaison 64 [E] What sort of title is that? This looks like an invitation 65 to IESG approval trouble. 67 Accepted with the following results 69 Change "Liaison" to "Co-chair". 71 Comment 2 73 -- Section 1 - Editors and Contributors 75 [E] A bit wordy, but basically ok. Please take out the 76 Internet-Draft references. 78 Accepted with the following results 80 1) Change "draft-ietf-ips-fcip-slp-___.txt" to "the FCIP SLP 81 internet-draft"; and 82 2) Change "draft-ietf-ips-fcip-mib-___.txt" to "the FCIP MIB 83 internet-draft". 85 Comment 3 87 -- Section 1 - Editors and Contributors 89 Several T11 leaders supported this effort and advised the editors 90 of this specification regarding appropriate interfaces to T11 91 documents. 93 [E] Is "leaders" the right T11 title? Let's make sure the right word 94 is used. 95 Also I think "coordination with T11 documents and projects" might be 96 better phrasing than "appropriate interfaces...". 98 Accepted (Partially) 100 I can think of no better word than "leaders". The only correct 101 replacement I can think of is "chairs, vice-chairs, secretaries, 102 facilitators, and document editors". I will make that change but 103 only if mandated to do so. 105 Change "...regarding appropriate interfaces to T11 documents." to 106 "...regarding coordination with T11 documents and projects." 108 Comment 4 110 -- Section 4 - Terminology 111 (really Section 2 - Purpose, Motivation and Objectives) 113 [E] Some of these [section 4] definitions implicitly exclude FC-AL, 114 or at least the private (i.e., non-fabric) use of FC-AL across 115 FC-IP. Section 2 would be a good place to make this exclusion 116 explicit. 118 Accepted with the following results 120 Add the following new paragraph at the end of section 2: "The 121 objectives of this document do not include using an IP Network as 122 a replacement for the Fibre Channel Arbitrated Loop interconnect. 123 No definition is provided for encapsulating loop primitive signals 124 for transmission over an IP Network. 126 Comment 5 128 -- Section 3.2 - This Specification and Fibre Channel Standards 130 No attempt is being made to define a specific API between an FCIP 131 Entity and an FC Entity at this time because doing so risks 132 compromising the performance and efficacy of the resulting 133 products. Current experience in this area is simply insufficient 134 to guide definition of the interface appropriately. 136 [E] That's a bit negative. Please add some text indicating that the 137 approach is to specify the functional interaction that is required, 138 but allow implementers to choose how this will be realized. 140 Accepted with the following results 142 Replace the cited paragraph with: " No attempt is being made to 143 define a specific API between an FCIP Entity and an FC Entity. The 144 approach is to specify required functional interactions between an 145 FCIP Entity and an FC Entity (both of which are required to forward 146 FC frames across an IP Network), but allow implementers to choose 147 how this will be realized." 149 Comment 6 151 -- Section 3.2 - This Specification and Fibre Channel Standards 153 The objectives and motivations of this specification are not 154 impacted by the decision not to standardize a specific API between 155 FCIP Entities and FC Entities because fully functional and 156 compliant products can be built provided they contain both an FCIP 157 Entity and an FC Entity. The only products that cannot be built 158 are those that contain only one or the other. 160 [E] I don't like the product focus of this language. The basic point 161 here is that in order to realize the full functionality of forwarding 162 frames between FC and IP networks, both an FC Entity and an FCIP 163 Entity are required. If someone wants to build something that only 164 contains one of these, the fact that it won't have this functionality 165 is their problem, not ours. 167 Accepted with the following results 169 This paragraph was intended to be the positive paragraph following 170 on the negative paragraph cited in comment 5. Since the changes 171 undertaken in response to comment 5 make that paragraph positive, 172 the bulk of this paragraph is no longer needed. 174 A few of the critical thoughts from the comment have been added 175 to the revised paragraph in the response to comment 5. With those 176 changes in place, the cited paragraph will be deleted. 178 Comment 7 180 -- Section 4 - Terminology 182 Terms needed to clarify the concepts presented in FCIP are 183 defined here. 185 [E] I don't like the usage of "clarify". How about "Terms used to 186 describe FCIP concepts are defined in this section."? 188 Accepted, make change exactly as proposed. 190 Comment 8 192 -- Section 4 - Terminology 194 FC Entity - The Fibre Channel specific element that combines with 195 an FCIP Entity to form an interface between an FC Fabric and an IP 196 Network (see section 6.3). 198 [E] I think "element" is problematic in this definition, because it 199 implies "fabric element" and leads to the sort of confusion that 200 Mallikarjun got into. How about "functional component"? 202 Accepted, make change exactly as proposed. 204 Comment 9 206 -- Section 4 - Terminology 208 FC Receiver Portal - The access point through which an FC Frame 209 and time stamp enters an FCIP Data Engine from the FC Entity. 211 FC Transmitter Portal - The access point through which a 212 reconstituted FC Frame and time stamp leaves an FCIP Data Engine 213 to the FC Entity. 215 [E] For clarity, shouldn't both of those terms be "FCIP" rather than 216 "FC" to avoid any possible confusion with transmission and reception 217 of FC frames on an FC fabric? 219 Accepted but only in principle 221 Change "FC" to "FC Frame" in these terms throughout the draft. 223 Inspection of the Portal names shows that "FC" is shorthand for "FC 224 Frame", not for "FCIP". 226 Comment 10 228 -- Section 4 - Terminology 230 FCIP Entity - The principal FCIP interface point to the IP Network 231 (see section 6.4). 233 [E] Definition needs to parallel FC Entity definition including 234 "functional component" language (or whatever term/phrase is chosen). 236 Accepted, make change exactly as proposed. 238 Comment 11 240 -- Section 4 - Terminology 242 FCIP Frame - An FC Frame plus the FC Frame Encapsulation [27] 243 header and encoded EOF that contains the FC Frame (see section 244 6.6.1). 246 [E] What about SOF? 248 Accepted 250 Add "encoded SOF" in the right place. 252 Comment 12 254 -- Section 4 - Terminology 256 FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity 257 that contains one or more FCIP_DEs (see section 6.5). 259 [E] Needs to say something about its relationship to FCIP Links. 261 Accepted with the following results 263 Change "...that contains one..." to "...that handles a single FCIP 264 Link and contains one..." 266 Comment 13 268 -- Section 4 - Terminology 270 Special Frame (SF) - A specially formatted FCIP frame containing 271 information used by the FCIP protocol (see section 8). 273 [E] I suggest prefixing FCIP to this term for clarity. 275 Accepted with the following results 277 1) Change "Special Frame (SF)" to "FCIP Special Frame (FSF)" 278 throughout the draft; and 280 2) Limit usage of spelled out FCIP Special Frame to once per section 281 and sections titles. 283 Comment 14 285 -- Section 5 Protocol Summary 287 2) Viewed from the IP Network perspective, FCIP Entities are 288 peers and communicate using TCP/IP. Each FCIP Entity is a 289 TCP endpoint in the IP-based network. 291 [E] TCP endpoint is not the right language, as this implies endpoint 292 of a single TCP connection. Probably needs to be described in terms 293 of TCP ports. 295 Accepted with the following results 297 Change "...is a TCP endpoint..." to "...contains one or more TCP 298 endpoints..." 300 Comment 15 302 -- Section 5 Protocol Summary 304 3) Viewed from the FC Fabric perspective, pairs of FCIP Entities, 305 in combination with their associated FC Entities, serve as an 306 FC Frame transmission component of the FC Fabric. The FC End 307 Nodes are unaware of the existence of the FCIP Link. 309 [E] "FC frame transmission component" is a bit abstract. Can we say 310 that it forwards frames between two FC ports, e.g., E_Ports? Note 311 the use of the e.g., to avoid limiting this to E_Ports. 313 Accepted but only in principle 315 Change "...serve as an FC Frame transmission component of the FC 316 Fabric." to "...forward FC Frames between FC Fabric elements." 318 Since comment 8 states that "element" has a well known meaning, use 319 of that term here should not raise objections. 321 Meticulous effort has gone into avoiding use of E_Port and B_Port 322 in this draft and a very good reason will have to be offered to get 323 either term in. 325 Comment 16 327 -- Section 5 Protocol Summary 329 7) When multiple FCIP_LEPs with multiple FCIP_DEs are in use, 330 selection of which FCIP_DE to use for encapsulating and 331 transmitting a given FC Frame is outside the scope of this 332 document. FCIP Entities do not actively participate in FC Frame 333 routing. 335 [E] Does anything need to be said about requirements for or 336 desirability of preserving the order in which frames are forwarded. 338 Response 340 No. The fact that TCP keeps all the sent on one TCP Connection in 341 order is covered elsewhere here. All other frame ordering concerns 342 are covered in FC-BB-2. 344 Comment 17 346 -- Section 5 Protocol Summary 348 8) The FCIP Control & Services function MAY use TCP/IP quality of 349 service features (see section 11.2) to support Fibre Channel 350 capabilities. 352 [E] This isn't quite right, as it seems to imply that FC has some 353 features that map onto TCP/IP QoS features. Needs some editorial 354 tweaking. 356 Accepted with the following results 358 Delete everything after the section reference. 360 Comment 18 362 -- Section 5 Protocol Summary 364 9) Each FCIP Entity is statically or dynamically configured with 365 a list of IP addresses and TCP port numbers corresponding 366 to participating FCIP Entities. If dynamic discovery of 367 participating FCIP Entities is supported, the function SHALL 368 be performed using the Service Location Protocol (SLPv2) [25]. 369 It is outside the scope of this specification to describe any 370 static configuration method for participating FCIP Entity 371 discovery. Refer to section 9.1.2.2 for a detailed description 372 of dynamic discovery of participating FCIP Entities using 373 SLPv2. 375 [E] There's a requirement lurking in here. One way to express it 376 would be to change the first "is" to "MUST be". 378 Accepted with the following results 380 Replace the first sentence in the cited text with: "It is necessary 381 to statically or dynamically configure each FCIP entity with the IP 382 addresses and TCP port numbers corresponding to FCIP Entities with 383 which it is expected to initiate communication." 385 Comment 19 387 -- Section 5 Protocol Summary 389 10) Before creating a TCP Connection to a peer FCIP Entity, the 390 FCIP Entity attempting to create the TCP connection SHALL 391 statically or dynamically determine the IP address, TCP port, 392 expected FC Fabric Entity World Wide Name, TCP Connection 393 Parameters, and Quality of Service Information. 395 [E] Need to get the "configuration" word in here, as this is 396 describing a requirement on the configuration mechanisms in 9), and 397 consider rephrasing this to make the connection clearer. 399 Rejected 401 Item 9) in the list describes configuration. This item describes 402 what is required in order to make a TCP connection and send the 403 Special Frame. 405 Comment 20 407 -- Section 5 Protocol Summary 409 13) On a given TCP Connection, this specification relies on TCP/IP 410 to deliver a byte stream in the same order that it was sent. 412 [E] "a given" --> "an individual" for clarity. 414 Accepted 416 Comment 21 418 -- Section 5 Protocol Summary 420 14) This specification defines only limited error detection and 421 recovery mechanisms and relies on both TCP and FC to handle 422 data loss and corruption within the IP Network. 424 [E] I'd rephrase this to talk about mechanisms that are complementary 425 to the existing TCP/IP and FC mechanisms, and that this specification 426 assumes the presence and requires the use of those existing 427 mechanisms. 429 Accepted with the following results 431 Replace the cited paragraph with: "14) This specification assumes 432 the presence of and requires the use of TCP and FC data loss and 433 corruption mechanisms. The error detection and recovery features 434 described in this specification complement and support these 435 existing mechanisms." 437 Comment 22 439 -- Section 6.1 - FCIP Protocol Model 441 [E] Need to define every acronym in Figure 1 and make it clear that 442 the FCIP Link is implemented via the IP Network Link. Consider using 443 "Fibre Channel Fabric" instead of "Fibre Channel Environment" for 444 consistency. 446 Accepted (Partially) 448 No changes will be made to "make it clear that the FCIP Link is 449 implemented via the IP Network Link". This is a relatively standard 450 network layering diagram. The notation is consistent already in 451 place is 100% consistent with that concept. 453 Actions to be taken: 455 1) Add a key at the bottom of the figure; and 456 2) Change "Environment" to "Fabric". 458 Comment 23 460 -- Section 6.3 - FC Entity 462 A product that tunnels an FC Fabric through an IP Network MUST 463 combine an FC Entity with an FCIP Entity (see section 6.4) to form 464 a complete interface between the FC Fabric and IP Network as shown 465 in figure 3. 467 [E] Again, I don't like the use of "product". How about 468 "implementation"? 470 Accepted, make change exactly as proposed. 472 Comment 24 474 -- Section 6.3 - FC Entity 476 In general, the combination of an FCIP Link and FC and FCIP 477 Entities is intended to replace a Fibre Channel defined connection 478 between Fibre Channel components. For example, this combination 479 can be used to replace a hard-wire connection between two Fibre 480 Channel switches. There are limitations on the generally intended 481 usage of the combination shown in figure 3. As another example, 482 the combination cannot be used to replace cable connections in a 483 Fibre Channel Arbitrated Loop because loop primitive signals 484 cannot be encapsulated for transmission over TCP. 486 [E] I think "replace" is the wrong verb. For example, if the 487 distance is well over 10km, it's not possible to have an FC 488 connection to replace. I would rewrite this in terms of "function 489 as" rather than "replace". I don't understand the "There are 490 limitations ..." sentence. As noted earlier the absence of support 491 for FC-AL should be stated in Section 2. 493 Accepted with the following results 495 1) Replace the first cited sentence with: "In general, the 496 combination of an FCIP Link and FC/FCIP Entities is intended 497 to provide a non- Fibre Channel backbone transport between 498 Fibre Channel components."; 499 2) In the second cited sentence change "replace" to "function 500 as"; and 501 3) Delete all text from "There are limitations..." to the end of 502 the paragraph. (Note this works because comment 4 puts the FC-AL 503 limitation in section 2.) 505 Comment 25 507 -- Section 6.3 - FC Entity 509 The interface between the FC and FCIP Entities is implementation 510 specific. The minimum requirements placed on an FC Entity by this 511 specification are listed in annex G. 513 [E] Suggest changing "minimal" to "functional". 515 Accepted 517 Comment 26 519 -- Section 6.4 - FCIP Entity 521 [E] In Figure 4, suggest changing "TCP connect request IP address and 522 port" to "TCP port for incoming connections". The implicit need for 523 an IP address should be obvious to the reader, or can be explained in 524 the text. 526 Accepted 528 Comment 27 530 -- Section 6.4 - FCIP Entity 532 The FCIP Entity is the connection interface point for the IP 533 Network and is the owner of the IP Address and Well Known Port used 534 to form TCP Connections. 536 [E] That language isn't quite right. It owns the TCP port at that IP 537 address, but does not need to exclusively own the IP address. 539 Accepted with the following results 541 Change "...is the owner of the IP Address and Well Known Port used 542 to form..." to "...is the owner of the Well Known Port at an IP 543 Address used to form...". 545 Comment 28 Technical 547 -- Section 6.4 - FCIP Entity 549 The interfaces to the IP Network features is implementation 550 specific, however, to maintain interoperability, the notable 551 TCP/IP mechanisms used are specified in this document as follows: 553 [E] I'd rephrase this to talk about "REQUIRED functional support" and 554 remove the "to maintain interoperability" language. 556 Accepted with the following results 558 1) Change "is" to "are"; 559 2) Replace everything from "however" to the end of the cited text 560 with: "however, REQUIRED TCP/IP functional support is specified 561 in this document, including:" 563 Comment 29 565 -- Section 6.5 - FCIP Link Endpoint (FCIP_LEP) 567 An FCIP_LEP MAY communicate with its FC Entity counterpart to 568 coordinate flow control. 570 [E] Insert "local" before "FC Entity" to make it clear that this 571 communication does not occur over the IP network. 573 Accepted 575 Comment 30 577 -- Section 6.6 - FCIP Data Engine (FCIP_DE) 579 Data flows through the FCIP_DE in the following seven steps: 581 [E] The text that follows this actually describes data flow through a 582 pair of FCIP_DEs connected across an IP network - this sentence needs 583 to be revised accordingly. 585 Accepted with the following results 587 Replace "...the FCIP_DE..." with "...a pair of IP Network connected 588 FCIP_DEs..." 590 Comment 31 592 -- Section 6.6 - FCIP Data Engine (FCIP_DE) 594 Table 2 shows the SOF and EOF code values that are legal in FCIP 595 Frames. This list may be a subset of the SOF and EOF codes listed 596 in the FC Frame Encapsulation [27]. 598 [T] This is a problem because these codes are being specified in more 599 than one place. I think the FC Frame Encapsulation document is the 600 right place for the normative specification of these codes (and see 601 my comments against it on the need to get IANA involved). This would 602 be ok as a list of codes that are currently valid, but the 603 specification authority needs to be in one place. 605 Accepted (Partially) with the following results 607 Replace the cited text with: "In FCIP, the Class 2, Class 3, and 608 Class 4 SOF and EOF codes listed in the FC Frame Encapsulation [27] 609 are legal. 611 Note: This change depends on adding the Class column in the FC Frame 612 Encapsulation draft. 614 Comment 32 616 -- Section 6.6.2.1 - TCP Assistance With Error Detection and 617 Recovery 619 TCP [8] requires in order delivery, generation of TCP checksums, 620 and checking of TCP checksums. Thus, the byte stream passed from 621 TCP to the FCIP_LEP will be in order and free of errors detectable 622 by the TCP checksum. If TCP did not perform these functions, the 623 FCIP_LEP would have to. 625 [E] Strengthen the last sentence to indicate that the FCIP_LEP relies 626 upon TCP performing these functions. 628 Accepted with the following results 630 Replace the cited last sentence with: "The FCIP_LEP relies on TCP 631 performing these functions." 633 Comment 33 635 -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP 636 Frames 638 1) Length field validation -- 15 < Length < 545; 640 [E] Explain where the 15 and 545 values come from. 642 Accepted with the following results 644 Add a note following the list that derives the values. 646 Comment 34 Technical 648 -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP 649 Frames 651 In addition to the tests above, the validity and positioning of 652 the following FCIP Frame information SHOULD be used to detect 653 encapsulation errors that may or may not affect synchronization: 655 a) Protocol # field and its ones complement (2 tests); 656 b) Version field and its ones complement (2 tests); 657 [... list continues, snipped ...] 659 [T] I think at least these two are MUSTs. At a minimum, the 660 Protocol# and Version field must be checked against expected values - 661 I might accept the checks against their ones complements being 662 SHOULDs. Same comment applies to the Flags field and SOF. Someone 663 MUST check the FC frame CRC before forwarding the frame, but that 664 responsibility could be assigned to the FC Entity. 666 Accepted (Partially) with the following results 668 1) Add to 6.6.2.2 checking Protocol# and Version#. This addition 669 will have to be in a separate paragraph before the current 1), 670 2), 3) list because it is not a synchronization issue; 671 2) Keep the one's complement tests in the SHOULD a), b), c) list, 672 but reduce the number of tests in that list by 2 (1 in a and 673 1 in b); and 674 3) Change the count of optional tests required from "5 of 18" to 675 "3 of 18". 676 4) Add the following after the tests are described: "Note: The 677 process of selecting an 8b/10b encoding for the SOF by 678 necessity includes some validation of the SOF fields." 680 Responses to other issues raised by comment 682 a) The Flags field is not a MUST test because it provides no 683 certain identification of the protocol beyond that provided by 684 the Protocol# field; and 685 b) Not even the Fibre Channel standards require that the FC CRC 686 be validated by FC Fabric elements. FC Endnode validation of 687 the FC CRC is sufficient. 689 Comment 35 Technical 691 -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP 692 Frames 694 At least 5 of the 18 tests listed above SHALL be performed. 695 Failure of any of the above tests actually performed SHALL 696 indicate an encapsulation error and the frame SHALL NOT be 697 forwarded on to the FC Entity. Further, such errors SHOULD be 698 considered carefully, since some may be synchronization errors. 700 [T] There aren't 18 tests, and I think some of the individual tests 701 (or subsets) are MUSTs (see previous comment). This needs to be gone 702 over carefully - in essence a MUST is only appropriate where failure 703 to apply the test carries a non-negligible risk of forwarding a bad 704 frame to FC. 705 The authors are the experts on this and need to do this analysis. I 706 don't understand the last "SHOULD" - what is the (testable) 707 requirement on an implementation? 709 No changes made 711 There are 18 tests: 2 + 2 + 1 + 2 + 2 + 1 + 4 + 1 + 2 + 1 = 18 713 What tests are MUSTs is covered by comment 34. 715 The authors have gone over the tests carefully and have concluded 716 that no individual test or specific group of tests associates 717 specifically with a non-negligible risk of forwarding a bad frame 718 to FC. The requirement is that a suitable number (at least 5, or 719 12 when the 7 required tests are included) tests is necessary to 720 reduce the risk of forwarding a bad frame to FC to a negligible 721 level. The specific tests selected depends on the implementation, 722 i.e., what test can be performed most efficiently in the 723 implementation hardware. 725 The "SHOULD" statement is intended to guide implementations. 726 Repeated failures of, for example, the CRC equal to zero test may 727 mean that synchronization has been lost. There are no hard and fast 728 rules here. 730 Comment 36 Technical 732 -- Section 6.6.2.3 - Synchronization Failures 734 If the FCIP_DE attempts to recover synchronization, the 735 resynchronization algorithm used SHALL meet the following 736 requirements: 738 [T] One requirement is missing, which may be part of b): 740 b) return to sending valid FC Frames only after synchronization 741 has been verified; and 743 [T] Verification of synchronization MUST exclude any possibility of 744 forwarding an FC frame that was not sent by the transmitting FCIP 745 Entity. This includes the scenario in which a valid encapsulated FCIP 746 frame occurs in the payload of an FC frame that is encapsulated and 747 sent over FCIP; excluding this scenario is necessary but not 748 sufficient to meet the requirement. 750 Accepted with the following results 752 Replace b) with: "return to forwarding FC Frames only after 753 synchronization on the transmitted FCIP Frame stream has been 754 verified; and" 756 Comment 37 Technical 758 -- Section 6.6.2.3 - Synchronization Failures 760 An example algorithm meeting these requirements can be found in 761 annex C. 763 [T] That doesn't meet the missing requirement that my above 764 comment wants to add. The problem is at step 2 of the algorithm 765 description. 767 2) Use multiple strong candidate headers to locate a verified 768 candidate header: 770 The Frame Length in one strong candidate header is used to skip 771 incoming bytes until the expected location of the next strong 772 candidate header is reached. Then the tests described in step 773 1) are applied to see if another strong candidate header has 774 successfully been located. 776 The "skip incoming bytes" step makes it possible that a set of valid 777 FC headers is interlaced in the payloads of FC frames in a fashion 778 that causes all the real headers to be skipped. This is a rather 779 unlikely, but not impossible scenario. This could be dealt with by 780 searching for headers instead of skipping data and aborting if a 781 header is found where data should have been or carrying on and 782 aborting if an interlaced header chain scenario arises. The 783 algorithm in Annex C does address the scenario of FCIP frames 784 occurring in FC frame payloads, but it doesn't meet the "can't be 785 fooled" requirement that I think should be added. 787 Unfortunately, this issue appears to not be resolvable within the WG. 788 I have had heated and lengthy offline discussion with the FCIP 789 Authors in which they have made clear their strong opposition to the 790 "missing requirement" and the need to scan rather than skip data, and 791 have argued that the algorithm in Annex C produces a long enough 792 chain of headers that the odds of having followed a chain that is 793 interlaced through frame payloads is small enough to be ignored. 794 I will have to consult the Area Directors. 796 Accepted with the following comment 798 Modifications to either step 2 or step 3 will achieve the requested 799 results. Because step 3 already includes complex steps such as 800 verifying the FC CRC value, changes in response to the comment will 801 be made in step 3. 803 Actions to be taken 805 1) Change the first paragraph of Annex C step 3 from: 807 "Incoming bytes are skipped and discarded until the next 808 verified candidate header is reached. Each verified candidate 809 header is tested against the full collection of tests listed in 810 section 6.6.2.2 as would normally be the case." 812 to: 814 "Incoming bytes are inspected and discarded until the next 815 verified candidate header is reached. Inspection of the incoming 816 bytes includes testing for other candidate headers using the 817 criteria described in step 1. Each verified candidate header is 818 tested against the tests listed in section 6.6.2.2 as would 819 normally be the case." 821 2) Change the second sentence in the third paragraph of Annex C 822 step 3 from: 824 "If any verified candidate headers are invalid and fail to meet 825 the tests for a strong candidate header, increment the retry 826 counter and return to step 1." 828 to: 830 "If any verified candidate headers are invalid and fail to 831 meet the tests for a strong candidate header or inspection 832 of the bytes between verified candidate headers discovers 833 any candidate headers, increment the retry counter and 834 return to step 1." 836 Comment 38 Technical 838 Section 7 - Checking FC Frame Transit Times in the IP Network 840 The FC Entity MUST implement the measurement of Fibre Channel 841 frame IP Network transit time as described in the FC Frame 842 Encapsulation [27] specification. 844 [E] "MUST implement" --> "MUST implement and use" for clarity. 846 Accepted but not as the comment intended 848 The statement is misleading and needs to be revised. 850 Action to be taken 852 Replace the cited sentence with: "FC-BB-2 [4] defines how the 853 measurement of IP Network transit time is performed, based on 854 the requirements stated in the FC Frame Encapsulation [27] 855 specification. 857 Additional note 859 See comment 40 for a discussion of why IP Network transit time 860 checking is done by the FC Entity. 862 Comment 39 864 Section 7 - Checking FC Frame Transit Times in the IP Network 866 If no synchronized time stamp value is available to accompany 867 the entering FC Frame a value of zero SHALL be supplied. 869 [E] "supplied" --> "used" for clarity. 871 Accepted 873 Comment 40 Technical 875 Section 7 - Checking FC Frame Transit Times in the IP Network 877 The FC Entity SHALL use suitable internal clocks and either Fibre 878 Channel services or an SNTP Version 4 server [13] to establish and 879 maintain the required synchronized time value. The FC Entity SHALL 880 verify that the FC Entity it is communicating with on an FCIP Link 881 is using the same synchronized time source as it is, either Fibre 882 Channel services or SNTP server. 884 [T] I don't believe that this paragraph meets the requirements in the 885 FC Frame Encapsulation specification for processing transit time 886 information. Punting this up to the FC Entity is problematic - 887 the minimum functional requirements on the FC Entity to meet the 888 FC Frame Encapsulation requirements will need to be spelled out here 889 in detail (i.e., a single sentence saying "must meet requirements in 890 Section 4 of the FC Frame Encapsulation document" is probably not 891 going to fly). Mallikarjun caught some issues in this area also. 893 Rejected 895 The decision to move time validation from FCIP to FC-BB-2 was made 896 for sound technical reasons: 898 1) Having the FC Entity verify transit time makes the test more 899 end-to-end; 900 2) Class F frames need not have their transit time verified. That 901 decision is allowed by the FC Frame Encapsulation. Encoding that 902 test in FCIP would necessitate a substantial increase in the 903 FCIP reliance on FC specific knowledge, including but not limited 904 to cracking FC Frames; 905 3) Allowing Class F frames to transit without transit time 906 verification is required to allow the FC Time Service to be 907 used as a source of synchronized time, a critical feature for 908 the success of FCIP; and 910 4) The description of the interactions between the FC Entity and 911 FCIP Entity for the purpose of maintaining a synchronized time 912 based on the FC Time Service were getting impossible to verify 913 for correctness when the requirements were stated in FCIP. 915 Having the FCIP Entity perform transit time tests was in the FCIP 916 draft as recently as draft-ietf-ips-fcovertcpip-05.txt. The 917 requested organization was tried and proved to be unworkable. 919 Comment 41 921 -- Section 8 - The FCIP Special Frame 923 [T] How is the FCIP Special Frame payload protected? I don't see the 924 equivalent of an FC Frame CRC. 926 Inquiry 928 The Special Frame is protected by requiring that the connection be 929 closed if the echoed SF differs from the transmitted SF. This is 930 deemed to be a more rigorous test than any CRC. 932 Comment 42 934 -- Section 8 - The FCIP Special Frame 936 |------------------------------Bit------------------------------| 937 | | 938 | 31 30 29 28 27 26 25 24 | 939 +-------+-------+-------+-------+-------------------------------+ 940 | SOFf | SOF?2 | SOF?3 | SOF?4 | Reserved | 941 +-------+-------+-------+-------+-------------------------------+ 943 Fig. 10 Connection Usage Flags Field Format 945 [E] I don't think the "?"s were intended and suspect that MS Word or 946 some other tool has been a little too helpful :-). 948 Inquiry 950 The question marks were intended to have the classic meaning of 951 question mark in a file specification. SOF?2 == SOFi2 or SOFn2. 953 Comment 43 Technical 955 -- Section 8 - The FCIP Special Frame 957 The Connection Usage Code field contains Fibre Channel defined 958 information regarding the intended usage of the connection as 959 specified in FC-BB-2 [4]. 961 [T] The authors need to talk to me about this, so that I can 962 understand what's going on here, and whether we need another IANA 963 registry, as is the case for the SOF and EOF values. 965 No changes made 967 The Connection Usage Code field allows pairs of FC Entities to 968 communicate 16-bits of connection setup information in the Special 969 Frame. It represents a request that the FC-BB-2 side of the house 970 made on the FCIP side. Given that FC-BB-2 is defining a whole new 971 SW_ILS to support a request made in the reverse direction, it is 972 difficult to see why the presence of the Connection Usage Code 973 field is an issue. 975 Comment 44 Technical 977 -- Section 8 - The FCIP Special Frame 979 [T] This section needs to describe the usage of the FCIP Special 980 Frame, including the structure of the interaction between the two FCIP 981 Entities, and how that establishes the security and connection usage 982 properties that are desired. The descriptions in Section 9 contain a 983 great deal of detail that mixes several mechanisms together - a high 984 level guide to what's going on is necessary to understand them. 986 Accepted with the following results 988 It is considered desirable to leave the Special Frame open to 989 additional uses in future versions of FCIP. This is why Section 8 990 lacks the requested overview. 992 Actions to be taken 994 1) Put the current Section 8 text in 8.1 "Special Frame Format"; 995 2) Add 8.2 "Overview of Special Frame Usage in Connection 996 Establishment"; and 997 3) Be sure to discuss the issues raised in comment 52, 998 comment 53, and comment 109 in the new section. 1000 The text for the new section is proposed to be the following: 1002 8.2 Overview of FSF Usage in Connection Establishment 1004 When a new TCP Connection is established, an FCIP Special Frame 1005 makes one round trip from the FCIP Entity initiating the TCP connect 1006 operation to the FCIP Entity receiving the TCP connect request and 1007 back. This FSF usage serves three functions: 1009 - Identification of the FCIP Link endpoints 1010 - Conveyance of a few critical parameters shared by the FC/FCIP 1011 Entity pairs involved in the FCIP Link 1012 - Configuration discovery (used in place of SLP only when 1013 allowed by site security policies) 1015 The specific requirements for this usage of the FSF are found in 1016 section 9.1. This section provides an overview of the FSF usage 1017 without stating requirements. 1019 Because FCIP is only a tunnel for a Fibre Channel Fabric and because 1020 the Fabric has its own complex link setup algorithm that can be 1021 employed for many FCIP link setup needs, it is desirable to minimize 1022 the complexity of the FSF usage during TCP Connection setup. With 1023 this in mind, this FSF usage is not a login or parameter negotiation 1024 mechanism. A single FSF transits each newly established TCP 1025 connection as the first bytes sent in each direction. 1027 Note: This usage of the FSF cannot be eliminated entirely because a 1028 newly created TCP Connection must be associated with the correct 1029 FCIP Link before FC Fabric initialization of the connection can 1030 commence. 1032 The first bytes sent from the TCP connect request initiator to the 1033 receiver are an FSF identifying both the sender and who the sender 1034 thinks is the receiver. If the contents of this FSF are correct and 1035 acceptable to the receiver, the unchanged FSF is echoed back to the 1036 sender. This send/echo process is the only set of actions that 1037 allows the TCP Connection to be used to carry FC Fabric traffic. If 1038 the send and unchanged echo process does not occur, the algorithm 1039 followed at one or both ends of the TCP Connection results in the 1040 closure of the TCP Connection (see section 9.1 for specific 1041 algorithm requirements). 1043 Note: Owing to the limited manner in which the FSF is used and the 1044 requirement that the FSF be echoed without changes before a TCP 1045 Connection is allowed to carry user data, no error checking beyond 1046 that provided by TCP is deemed necessary. 1048 As described above, the primary purpose of the FSF usage during TCP 1049 Connection setup is identifying the FCIP Link to which the new TCP 1050 Connection belongs. From these beginnings, it is only a small 1051 stretch to envision using the FSF as a simplified configuration 1052 discovery tool, and the mechanics of such a usage are described in 1053 section 9.1. 1055 However, use of the FSF for configuration discovery lacks the broad 1056 range of capabilities provided by SLP v2 and most particularly lacks 1057 the security capabilities of SLP v2. For these reasons, using the 1058 FSF for configuration discovery is not appropriate for all 1059 environments. Thus the choice to use the FSF for discovery purposes 1060 is a policy choice to be included in the TCP Connection 1061 Establishment "shared" database described in section 9.1.1. 1063 When FSF-based configuration discovery is enabled, the normal TCP 1064 Connection setup rules outlined above are modified as follows. 1066 Normally, the algorithm executed by an FCIP Entity receiving an FSF 1067 includes verifying that its own identification information in the 1068 arriving FSF is correct and closing the TCP Connection if it is not. 1069 This can be viewed as requiring the initiator of a TCP connect 1070 request to know in advance the identity of the FCIP Entity that is 1071 the target of that request (using SLP, for example), and through the 1072 FSF effectively saying, "I think I'm talking to X." If the party at 1073 the other end of the TCP connect request is really Y, then it simply 1074 hangs up. 1076 FSF-based discovery allows the "I think I'm talking to X" to be 1077 replaced with "Please tell me who I am talking to?", which is 1078 accomplished by replacing an explicit value in the Destination FC 1079 Fabric Entity World Wide Name field with zero. 1081 If the policy at the receiving FCIP Entity allows FSF-based 1082 discovery, the zero is replaced with the correct Destination FC 1083 Fabric Entity World Wide Name value in the echoed FSF. This is still 1084 subject to the rules of sending with unchanged echo, and so closure 1085 of TCP Connection occurs after the echoed FSF is received by the TCP 1086 connect initiator. 1088 Despite the TCP Connection closure, however, the TCP connect 1089 initiator now knows the correct Destination FC Fabric Entity World 1090 Wide Name identity of the FCIP Entity at a given IP Address and a 1091 subsequent TCP Connection setup sequence probably will be successful. 1093 The Ch bit in the pFlags field (see section 6.6.1) allows for 1094 differentiation between changes in the FSF resulting from 1095 transmission errors and changes resulting from intentional acts by 1096 the FSF recipient. 1098 Comment 45 1100 -- Section 9.1.1 - Connection Establishment Model 1102 What is important is the fact that the FCIP Entity MAY consult the 1103 database at anytime to determine its actions relative to TCP 1104 Connection establishment. 1106 [E] "anytime" --> "any time" 1108 Accepted 1110 Comment 46 Technical 1112 -- Section 9.1.2.1 - Non-Dynamic Creation of New TCP Connections 1114 If the TCP connect request is rejected, the FCIP Entity SHALL act 1115 to limit unnecessary repetition of attempts to establish similar 1116 connections. 1118 [T] That's a little vague. How about specifying a minimum time 1119 period that MUST elapse before retry? 1121 Accepted with the following results 1123 Add new sentence following cited text: "For example, the FCIP 1124 Entity might wait 60 seconds before trying to re-establish the 1125 connection." 1127 Comment 47 1129 -- Section 9.1.2.1 - Non-Dynamic Creation of New TCP Connections 1131 It is recommended that an FCIP Entity not initiate TCP connect 1132 requests to another FCIP Entity if incoming TCP connect requests 1133 from that FCIP Entity have already been accepted. 1135 [T] Needs an upper case "SHOULD" or "RECOMMENDED". This also needs 1136 a MUST or SHOULD on the configuration mechanism to indicate in which 1137 direction connections are to be established between a pair of FCIP 1138 Entities in order to deal with a problem that turns up near the end 1139 of Section 9.1.3. This is related to Mallikarjun's issue about 1140 handling of simultaneous opens. 1142 Accepted (Partially) 1144 Change "recommended" to "RECOMMENDED". See comment 124 for a 1145 discussion of the other issues cited here. 1147 Comment 48 1149 -- Section 9.1.2.2 - Dynamic Creation of New TCP Connections 1151 [E] The information on connection establishment is basically common to 1152 this and Section 9.1.2.1. Consider reducing this section to focus on 1153 use of SLP, and referring to Section 9.1.2.1 for what to do after the 1154 configuration info is discovered via SLP. Also consider whether the 1155 SLP description should come before the connection establishment 1156 description. 1158 Rejected 1160 The information on connection establishment is indeed common to 1161 section 9.1.2.1, but its relationship to SLP is not. Section 9.1.2.2 1162 already is less than one page long, that and a desire to have some 1163 amount of readable flow (as opposed to "do this, then do what it 1164 says to do over there, then do that, then do this other thing that 1165 is talked about in another section") seems like ample motivation 1166 for the current organization. 1168 Comment 49 1170 -- Section 9.1.2.3 - Connection Setup After a Successful TCP Connect 1171 Request 1173 [T] This dives into the details of FCIP Special Frame handling without 1174 explaining the overall structure and goals of the use, and is unclear 1175 as a result. For example, For example, on p. 29, after constructing 1176 the FCIP Special Frame, the text says: 1178 After the FCIP Special Frame bytes are sent on the newly formed 1179 connection, the FCIP Entity SHALL wait for the FCIP Special Frame 1180 to be echoed as the first bytes received on the newly formed 1181 connection. 1183 But one has to wade all the way down to p.33 towards the end of 1184 Section 9.1.3 to discover that the other FCIP Entity is expected to 1185 perform validation actions before echoing the frame. The structural 1186 outline of the usage of the FCIP Special Frame (without the blow by 1187 blow details) needs to be described in Section 8. 1189 Duplicate comment, see response to comment 44. 1191 Comment 50 1193 -- Section 9.1.2.3 - Connection Setup After a Successful TCP Connect 1194 Request 1196 The remaining steps in this section SHALL be performed only if the 1197 echoed FCIP Special Frame bytes exactly match the FCIP Special 1198 Frame bytes sent (words 7 through 17 inclusive). 1200 [E] There is a great deal of common text in the two descriptions that 1201 follow the above text. They should be combined into a single 1202 description, with the creation of the FCIP_LEP at step 2 being done 1203 only if necessary. 1205 Accepted (Conditionally) 1207 An attempt will be made to do this. If the cure is worse than the 1208 disease, the original text will be used. 1210 Comment 51 1212 -- Section 9.1.3 - Processing Incoming TCP Connect Requests 1214 If the requested connection is allowed, the FC Entity SHALL ensure 1215 that required IP security features are enabled and accept the TCP 1216 connect request. 1218 [T] As written, this appears to require a dynamic interrogation of 1219 the IPsec Security Association Database, and possibly the IPsec 1220 Security Policy Database. I suspect that this is in excess of what 1221 was intended, and suspect a longer description is needed. 1223 Accepted with the following result 1225 Change "If the connection is allowed,..." to "If the connection is 1226 allowed by the "shared" database (see 9.1.1),..." 1228 Comment 52 Technical 1230 -- Section 9.1.3 - Processing Incoming TCP Connect Requests 1232 If the Destination FC Fabric Entity World Wide Name contains 0, 1233 the FCIP Entity SHALL take one of the following three actions: 1235 1) Leave the Destination FC Fabric Entity World Wide Name field 1236 and Ch bit both 0; 1237 2) Change the Destination FC Fabric Entity World Wide Name field 1238 to match FC Fabric Entity World Wide Name associated with the 1239 FCIP Entity that received the TCP connect request and change 1240 the Ch bit to 1; or 1241 3) Close the TCP Connection without sending any response. 1243 The choice between the above actions depends on the anticipated 1244 usage of the FCIP Entity and is outside the scope of this 1245 specification. The FCIP Entity may consult the "shared" database 1246 when choosing between the above actions. 1248 [T] I'm not buying the "outside the scope" disclaimer. Some more 1249 description of why the three choices are available is in order even 1250 if the normative criteria for choosing among them are specified in 1251 FC-BB-2. If my assumption about FC-BB-2 is correct, the last 1252 sentence is almost certainly too weak - it needs to refer to 1253 consulting the FC Entity to determine what to do. 1255 Accepted but not as the comment intended 1257 Delete "... and is outside the scope of this specification" 1258 Other actions to be taken 1260 Note: Some non SLP implementations wish to use the SF as a 1261 configuration determination mechanism. The choice exists to allow 1262 that option. 1264 Describe this in the new section added in response to comment 44. 1266 Comment 53 Technical 1268 -- Section 9.1.3 - Processing Incoming TCP Connect Requests 1270 If: 1271 a) The Destination FC Fabric Entity World Wide Name contains a 1272 non-zero value that does not match the FC Fabric Entity World 1273 Wide Name associated with the FCIP Entity that received the TCP 1274 connect request, or 1275 b) The contents of the Connection Usage Flags, and Connection 1276 Usage Code fields is not acceptable to the FCIP Entity that 1277 received the TCP connect request, 1278 then the FCIP Entity SHALL take one of the following two actions: 1279 1) Change the contents of the unacceptable fields to correct/ 1280 acceptable values and set the Ch bit to 1; or 1281 2) Close the TCP Connection without sending any response. 1283 [T] 1) looks like a security hole that discloses information an 1284 attacker may find useful in establishing an undesired connection to 1285 FCIP. 1286 What's the motivation/purpose for this? 1288 No changes made 1290 The motivation is to allow the SF to be used as a poor-man's SLP. 1292 Option 1) is a security policy that is not a security hole because 1293 either IPsec or option 2) or both are available as security policy 1294 choices. 1296 Comment 54 Technical 1298 -- Section 9.1.3 - Processing Incoming TCP Connect Requests 1300 If the Source FC Fabric Entity World Wide Name and Source FC/FCIP 1301 Entity Identifier field values in the FCIP Special Frame match the 1302 Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity 1303 Identifier associated with an existing FCIP_LEP, the FCIP Entity 1304 SHALL: 1306 1) Request that the FC Entity authenticate the source of TCP 1307 connect request, providing the following information to the FC 1308 Entity for authentication purposes: 1310 [T] Need to say more about what the FC Entity MUST do to 1311 "authenticate the source". I realize that the details are specified 1312 in FC-BB-2, but the functional requirements on the FC Entity can be 1313 specified here. 1315 Accept but only to a limited degree 1317 Requiring the FC Entity to do a specific thing in response to 1318 the request to authenticate goes substantially beyond the security 1319 policies that the IETF applies to itself (i.e., this would be 1320 MANDATORY to implement and MANDATORY to use). 1322 Action to be taken 1324 Replace the "warning" paragraph cited in comment 56 with: "The 1325 definition of the FC Entity SHALL include a mechanism for use in 1326 response to a TCP connect request source that communicates with the 1327 partner FC Entity on the FCIP Link using a previously authenticated 1328 TCP Connection to verify that the Connection Nonce has been sent in 1329 a yet to be completed TCP Connection setup. Failure of the partner 1330 FC Entity to verify the Connection Nonce SHALL be treated as an 1331 authentication failure." 1333 Comment 55 Technical 1335 -- Section 9.1.3 - Processing Incoming TCP Connect Requests 1337 The FCIP Entity SHALL wait indefinitely for the FC Entity to 1338 authenticate source of the TCP connect request and SHALL not 1339 use the new TCP Connection for any purpose until the FC Entity 1340 completes the authentication. 1342 [T] "wait indefinitely" creates an obvious denial of service attack 1343 vulnerability. Try again. 1345 Accepted with the following results 1347 Change the cited text to: "The FCIP Entity SHALL not use the new TCP 1348 Connection for any purpose until the FC Entity authenticates the 1349 source of the TCP connect request." 1351 Comment 56 1353 -- Section 9.1.3 - Processing Incoming TCP Connect Requests 1355 Warning: The authentication mechanism described here and in 1356 FC-BB-2 [4] is not designed to thwart sophisticated security 1357 threats. The IP security mechanisms described in section 10 1358 should be enabled in environments where security threats are 1359 suspected. 1361 [E] Unfortunately, that's almost content-free. I suggest replacing 1362 this with a forward pointer to a more specific discussion of the 1363 threats involved in the Security Considerations section. 1365 Accepted with the following results 1367 1) Embed said pointer in the first paragraph of the step 1) 1368 text describing the process; and 1369 2) Remove this paragraph entirely. 1371 Comment 57 Technical 1373 -- Section 9.1.3 - Processing Incoming TCP Connect Requests 1375 Note that the originator of TCP connect requests uses IP Address 1376 and TCP Port to identify which TCP Connections belong to which 1377 FCIP_LEPs while the recipient of TCP connect requests uses the 1378 Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity 1379 Identifier fields from the FCIP Special Frame to identify which TCP 1380 Connection belong to which FCIP_LEPs. For this reason, an FCIP 1381 Entity that both originates and receives TCP connect requests is 1382 unable to match the FCIP_LEPs associated with originated TCP 1383 connect requests to the FCIP_LEPs associated with received TCP 1384 connect requests. 1386 [T] That's a problem. See comment against Section 9.1.2.1 for 1387 one suggestion for how to fix this, but some sort of fix appears 1388 necessary to me. 1390 Accepted with the following results 1392 Add a new section 9.1.4 titled "Simultaneous Connection 1393 Establishment" containing the following text. 1395 "If two FCIP Entities perform simultaneous open operations, then 1396 two TCP Connections are formed and the SF originates at one end 1397 on one connection and at the other end on the other. Connection 1398 setup proceeds as described above on both connections, and the 1399 steps described above properly result in the formation of two 1400 FCIP Links between the same FCIP Entities. 1402 "This is not an error. Fibre Channel is perfectly capable of 1403 handling to approximately equal connections between FC Fabric 1404 elements. 1406 "The decision to setup pairs of FCIP Links in this manner is 1407 considered to be a site policy decision that can be covered in 1408 the "shared" database described in section 9.1.1." 1410 Comment 58 1412 -- Section 9.3 - TCP Connection Parameters 1414 In order to provide efficient management of FCIP_LEP resources as 1415 well as FCIP Link resources, consideration of certain TCP 1416 Connection parameters is RECOMMENDED. 1418 [E] As written, "RECOMMENDED" should be lower case, as it does not 1419 convey a requirement related to interoperability or good use of the 1420 network. 1422 Accepted 1424 Comment 59 1426 -- Sections 9.3.2, 9.3.3, and 9.3.4 1428 [E] Sections 9.3.2, 9.3.3, and 9.3.4 need references to the 1429 specifications of the TCP options being discussed. 1431 Accepted 1433 Good! We are being asked later to prune the normative references. 1434 This will allow them to be bulked up again. 1436 Comment 60 Technical 1438 -- Section 9.3.4 TCP_NODELAY Option 1440 FCIP Entities SHALL set the TCP_NODELAY option to one. This will 1441 disable the Nagle Algorithm that is designed for usage in a telnet 1442 environment. 1444 [T] I believe that "SHALL" should be a lower case "should". This is 1445 a local performance optimization that has no other effects. 1447 Accepted 1449 Comment 61 Technical 1451 -- Section 9.5 - Flow Control Mapping between TCP and FC 1453 Coordination of these flow control mechanisms one of which is 1454 credit based and the other of which is window based depends on 1455 painstaking design that is outside the scope of this 1456 specification. 1458 [T] This is content-free. At least warn about some of the things 1459 that can go wrong, in particular BB-credit starvation and the 1460 potential to really screw up a Fibre Channel fabric if this is 1461 long-lived. 1463 Rejected 1465 This text was written in specific response to the decision of Orange 1466 County interim meeting that "The only statement that should appear 1467 in FCIP on the subject is, 'There be dragons here.'" 1469 Comment 62 Technical 1471 -- Section 10 Security 1473 [T] Need to get this whole section aligned with the latest (currently 1474 -11) version of the IPS Security draft. 1476 Accepted with the following results 1478 Section 10 will be aligned with IPS Security Draft version 12. 1479 This will require a substantial number of changes, as detailed 1480 below. It would be desirable to avoid a "hairball" between FCIP 1481 and the IPS Security Draft. With this in mind, it is believed that 1482 changes in the IPS Security Draft will concern areas that do not 1483 directly impact FCIP. Of course, there are no guarantees. 1485 In Section 10.1, add the following to the Threat Models: "8) An 1486 adversary may launch a variety of attacks against the discovery 1487 process [SLPv2, RFC2608]." 1489 Note: This addition is placed in the list in such a way as to keep 1490 the FCIP-specific attack (the attack related to the Special Frame) 1491 last in the list. 1493 Section 10.3.1, add the following to the end of the first paragraph: 1494 "When ESP is utilized, per-packet data origin authentication, 1495 integrity and replay protection must be used." 1496 In addition to the changes in Section 10.3.2 (Key Management) 1497 described in comment 69, comment 70, comment 71, comment 72, and 1498 comment 73, make the following changes: 1500 1) Add the following to the end of Paragraph 1: 1502 "Conformant FCIP implementations MUST support peer authentication 1503 using pre-shared key and MAY support peer authentication using 1504 digital certificates. Peer authentication using public key 1505 encryption methods outlined in IKE [2409] Section 5.2 and 5.3 1506 SHOULD NOT be used." 1508 2) Change the last sentence of Paragraph 2 from: 1510 "FCIP Entities MUST support "Main Mode" operation in Phase 1 and 1511 MAY support "Aggressive Mode" if identity protection is not 1512 required." 1514 to: 1516 "FCIP implementations MUST support IKE Main Mode and SHOULD 1517 support Aggressive Mode." 1519 3) Add the following at the end of paragraph 3: "The Phase 2 Quick 1520 Mode exchanges MUST explicitly carry the Identity Payload fields 1521 (IDci and IDcr). Each Phase 2 payload SHOULD carry a single IP 1522 Address and a single non-zero port number and SHOULD NOT use the 1523 IP Subnet or IP Address Range formats. Other ID payload formats 1524 MUST NOT be used." 1526 4) Add the following new paragraph after paragraph 3: "Since the 1527 number of Phase 2 SAs may be limited, Phase 2 delete messages may 1528 be sent for idle SAs. The receipt of a Phase 2 delete message 1529 SHOULD NOT be interpreted as a reason for tearing down an FCIP 1530 Link or any of its TCP connections. When there is new activity on 1531 that idle link, a new Phase 2 SA MUST be re-established." 1533 5) In the paragraph that starts with "For the purposes of...", 1534 change the last sentence from: 1536 "For the purposes of establishing IKE Phase 1 SA, static IP 1537 Addresses are typically used for identification." 1539 to: 1541 "Within IKE Phase 1, FCIP implementations must support the 1542 ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) 1543 and ID_FQDN Identity Payloads. If FCIP Endpoint addresses are 1544 dynamically assigned, it may be beneficial to use ID_FQDN, and 1545 for this reason, IP_FQDN Identity Payload MUST be supported. 1546 Other identity payloads (ID_USER_FQDN, ID_DER_ASN1_GN, ID_KEY_ID) 1547 SHOULD NOT be used. 1549 Comment 63 1551 -- Section 10.1 Threat Models 1553 Using a general purpose, wide-area network such as an IP Network as 1554 a substitute for physical cabling introduces some security problems 1555 not normally encountered in Fibre Channel Fabrics. FC interconnect 1556 cabling typically is protected physically from outside access. 1557 Public IP Networks allow hostile parties to impact the security of 1558 the transport infrastructure. 1560 [E] The intent is fine, but the "substitute" word has the same 1561 problems as the use of "replace" in Section 6.3. This is about 1562 "implementation of functionality that was originally specified only 1563 to use dedicated physical cabling" or something like that, as 1564 indicated in the latter two sentences. 1566 Accepted with the following result 1568 Replace "substitute" with "functional replacement". 1570 Comment 64 1572 -- Section 10.1 Threat Models 1574 The general effect is that the security of the entire FC Fabric 1575 is only as good as the security of the entire IP Network through 1576 which it tunnels. 1578 [E] "the entire" --> "any". This may be the first occurrence of 1579 "tunnel" in the document - that might be better rephrased to talk 1580 about "any IP Network" carrying FCIP links that are part of the 1581 fabric". 1583 Accepted with the following result 1585 Replace the cited text with: "The general effect is that the 1586 security of an FC Fabric is only as good as the security of the 1587 entire IP Network that carries the FCIP Links used by that FC Fabric. 1589 Comment 65 1591 -- Section 10.1 Threat Models 1593 2) Unauthorized agents can monitor and manipulate Fibre Channel 1594 traffic flowing over physical media used by the IP Network and 1595 under control of the agent. 1597 [E] "under control of" is too strong. "accessible to" would be 1598 better, especially for monitoring. 1600 Accepted 1602 Comment 66 1604 -- Section 10.1 Threat Models 1606 5) The payload of an FCIP Encapsulated frame may be altered or 1607 transformed in such a way that it preserves the TCP Checksum 1608 transform while altering content. 1610 [E] Put a period after "transformed" and rephrase the rest to say 1611 that the TCP checksum, FCIP ones complement checks and FC frame CRC 1612 do not protect against this, as all of them can be modified or 1613 regenerated by a malicious and determined adversary. 1615 Accepted 1617 Comment 67 1619 -- Section 10.3 - FCIP Security Components 1621 FCIP Security compliant implementations MUST implement IPSec 1622 Protocol Suite based cryptographic authentication and data 1623 integrity [14], as well as confidentiality using algorithms and 1624 transforms as described in this section. 1626 [E] Please insert the ESP acronym into this sentence. 1627 [E] The official capitalization is "IPsec", not "IPSec". 1629 Accepted with the following results 1631 1) Replace "IPSec" with "ESP and IPsec"; and 1632 2) Verify correct IPsec usage throughout. 1634 Comment 68 Technical 1636 -- Section 10.3.1 - IPSec ESP Authentication and Confidentiality 1638 FCIP Entities MUST implement IPSec ESP [16] in Tunnel Mode for 1639 providing Data Integrity and Confidentiality. FCIP Entities MAY 1640 implement IPSec ESP in Transport Mode, if deployment considerations 1641 require use of Transport Mode. 1643 [T] Those deployment considerations include RFC 2401 requirement for 1644 Transport mode because the IPsec implementation is a host 1645 implementation rather than a security gateway. I thought this was 1646 understood by the FCIP authors, and it needs to be explicit here 1647 including an appropriate reference to RFC 2401. I expect to be able 1648 to double-check this requirement with the IETF Security Area in the 1649 next few days. 1651 Rejected 1653 As per the consensus taken at the March 2002 IETF meeting, Transport 1654 Mode implementation is a MAY. 1656 Comment 69 1658 -- Section 10.3.2 - Key Management 1660 FCIP Entities MUST support IKE [18] for peer authentication, 1661 negotiation of Security Associations (SA) and Key Management using 1662 the IPSec DOI [17]. Manual keying for establishing SA is not 1663 permitted since it does not provide the necessary elements for 1664 rekeying (see section 10.3.3). 1666 [E] Reword last sentence to include "MUST NOT use", "SHALL NOT use" 1667 or equivalent. 1669 Accepted 1671 Comment 70 1673 -- Section 10.3.2 - Key Management 1675 Repeated rekeying using "Quick Mode" on the same shared secret will 1676 over time, reduce the cryptographic properties of that secret. To 1677 overcome this, Phase 1 MAY be invoked periodically to create a new 1678 set of IKE shared secrets and related security parameters. 1680 [E] "MAY" --> "SHOULD" (I believe this captures the intention). 1682 Accepted 1684 Comment 71 Technical 1686 -- Section 10.3.2 - Key Management 1688 When pre-shared keys are used, IKE Aggressive Mode SHOULD be used 1689 and Main Mode SHOULD NOT be used. 1691 [T] I think this is too strong and will cause problems. Pre-Shared 1692 keys are a "MUST", Aggressive Mode is a "MAY", so this "SHOULD" is 1693 inconsistent. The issue with Main Mode arises when dynamically 1694 assigned IP addresses are used (and hence Main Mode can't figure out 1695 which pre-shared key to use). The escape from this box appears to be 1696 that Aggressive Mode is a MUST (SHOULD?) when dynamic assignment of 1697 IP addresses to FCIP implementations is used, but support for dynamic 1698 assignment of IP addresses is NOT REQUIRED. 1700 The problem with this approach is that one gets into trouble on one 1701 end of an FCIP Link when the *other* end has its IP address 1702 dynamically assigned. The obvious solutions to this issue are to 1703 forbid (MUST NOT) dynamic IP address assignment (which has no chance 1704 of making it through the IESG) or to REQUIRE Aggressive Mode (as iFCP 1705 does). In addition, the IPS Security draft appears to need some 1706 editing to allow Aggressive Mode to be a "MAY" for FCIP (and iFCP). 1707 Darn - I thought we had this issue closed in Huntington Beach - did I 1708 miss something? 1710 Accepted with the following results 1712 Replace the cited text with: 1714 "When pre-shared keys are used, IKE Main Mode is usable only when 1715 both peers of an FCIP Link use statically assigned IP addresses. 1716 When support for dynamically assigned IP Addresses is attempted in 1717 conjunction with Main Mode, use of group pre-shared keys would be 1718 forced, and the use of group pre-shared keys in combination with 1719 Main Mode is not recommended as it exposes the deployed environment 1720 for man-in-the-middle attacks. Therefore, if either peer of an FCIP 1721 Link uses dynamically assigned address, Aggressive Mode SHOULD be 1722 used and Main Mode SHOULD NOT be used." 1724 Comment 72 1726 -- Section 10.3.2 - Key Management 1728 Support for IKE Oakley Groups is not required. 1730 [T] What does this refer to? At a minimum, it needs a reference. 1732 Accepted 1734 The reference for IKE Oakley Groups is RFC 2412. A suitable 1735 informational reference will be added. 1737 Comment 73 1739 -- Section 10.3.2 - Key Management 1741 For the purposes of establishing a secure FCIP Link, the two 1742 participating FCIP Entities consult a Security Policy Database 1743 (SPD). 1745 [E] For this and the SAD, please add RFC 2401 references. 1747 Accepted with the following results 1749 1) Add a new normative reference for SPD to section 4.4.1 of 1750 RFC 2401; and 1751 2) Add a new normative reference for SAD to section 4.4.3 of 1752 RFC 2401. 1754 Comment 74 Technical 1756 -- Section 10.4.2 - TCP Connection Security Associations (SAs) 1758 For a TCP Connection establishment, IKE Phase 2 is employed, 1759 resulting in an SA, identified by an SPI. All IP datagrams of the 1760 TCP Connection MUST carry an ESP header with a valid SPI and 1761 Sequence Number to be accepted as valid by the receiving peer. 1763 [T] The requirement for a phase 2 SA per TCP connection has been 1764 removed. This text (and possibly the rest of this section) need some 1765 editing to reflect that. 1767 Accepted with the following results 1769 1) Replace the cited text with: "Each TCP connection MUST be 1770 protected by an IKE Phase 2 SA. Traffic from one or more than 1771 one TCP connection may flow within each IPsec Phase 2 SA. While 1772 it is possible for a IKE Phase 2 SA to protect multiple TCP 1773 connections, all packets of a TCP connection is protected using 1774 only one IKE Phase 2 SA. FCIP implementations need not verify 1775 that the IP addresses and port numbers in the packet match any 1776 locally stored per-connection values, leaving this check to be 1777 performed by the IPsec layer." 1779 2) Delete the last paragraph of the section, which currently reads: 1780 "When a TCP Connection is terminated or closed, all SAs 1781 associated with it MUST be removed from the local SAD." 1783 Comment 75 1785 -- Section 10.4.3 - Handling data integrity and confidentiality 1786 violations 1788 An implementation MAY audit such events as a diagnostic aid. 1790 [E] Almost but not quite. Auditing is about a lot more than 1791 "diagnostic aid". See Section 7 of RFC 2401, make sure the text is 1792 consistent with it, and refer to it. 1794 Accepted with the following results 1796 Replace the cited text with: "An implementation SHOULD follow 1797 guidelines for auditing all auditable ESP events per Section 7 1798 of RFC2401." 1800 Comment 76 Technical 1802 -- Section 10.4.3 - Handling data integrity and confidentiality 1803 violations 1805 Confidentiality checks MUST be performed if Confidentiality is 1806 enabled. 1808 [T] And what would those be, please? Replace this with a prohibition 1809 on use of Confidentiality without Integrity. 1811 Accepted with the following results 1813 Replace the first "Confidentiality" with "Integrity". 1815 Comment 77 Technical 1817 -- Section 10.4.4 - Handling SA parameter mismatches 1819 When SA parameters do not match, the TCP Connection may reach a 1820 point where no traffic moves, or there are excessive TCP 1821 retransmissions. In such a case, either side MAY take one of the 1822 following actions: 1823 a) Reestablish another set of SA parameters; or 1824 b) Close the TCP Connection and notify the FC Entity with the 1825 reason for the closure. 1827 [T/E] Needs some more explanation, including an example of the 1828 sort of mismatch that could cause this problem. Recall that IKE 1829 negotiates SA parameters, and this fact needs to be included in the 1830 explanation and example. 1832 Accepted but perhaps not as intended 1834 The handling of SA parameter mismatches belongs in a security draft, 1835 not in FCIP. Therefore, section 10.4.4 will be removed. 1837 Comment 78 1839 -- Section 11.1 - Performance Considerations 1841 Traditionally, the links between FC Fabric components have been 1842 characterized by low latency and high throughput. The purpose of 1843 FCIP is to replace some of these links with an IP Network, 1845 [E] There's the "replace" work again. See comment against Section 1846 6.3. 1848 Accepted with the following result 1850 Replace "...to replace some of these links with..." with "...to 1851 provide functionality equivalent to these links using..." 1853 Comment 79 1855 -- Section 11.2 - IP Quality of Service (QoS) Support 1857 It is RECOMMENDED that some form of preferential QoS be used 1858 for FCIP traffic to minimize latency and drop precedence. No 1859 particular form of QoS is recommended. 1861 [E] "drop precedence" --> "packet drops" 1863 Accepted 1865 Comment 80 1867 -- Section 11.2 - IP Quality of Service (QoS) Support 1869 If diffserv/PHB QoS is NOT implemented, the DSCP field for all IP 1870 packets SHALL be set to '000000'. 1872 [T] Sorry, wrong answer. That's not consistent with RFC 2474. 1873 Best bet is to drop this sentence, but if the authors want to say 1874 something here, they should contact me directly to discuss/vet 1875 appropriate text. 1877 Accepted with the following results 1879 Replace the cited text with: "If no form of preferential QoS is 1880 implemented, the DSCP field SHOULD be set to '000000' to avoid 1881 negative impacts on other network components and services that 1882 may be caused by uncontrolled usage of non-zero values of the 1883 DSCP field." 1885 Comment 81 1887 -- Section 12 - Normative References 1889 [E] This needs to be carefully checked to minimize normative 1890 references. [7] is definitely non-normative. Most of the QoS 1891 references are or can be non-normative, specifically [11], [22], 1892 [23], [24]). [22] is an Informational RFC and hence has to be 1893 referenced in a non-normative fashion, and I really want to see [23] 1894 and [24] be non-normative (else any FCIP implementation will have to 1895 implement both EF and AF, which is surely not what was intended). 1896 Need to add a non-normative MPLS reference. 1898 Accepted with the following results 1900 1) Remove reference 7 entirely; 1901 2) Make the SNTP reference [13] informative; 1902 3) Make all references from section 11 (Performance/QoS) 1903 informative (note: this covers all the other cited 1904 references); and 1905 4) Add an informative reference to RFC 3031 for MPLS. 1907 All other references appear to be necessary. 1909 Comment 82 1911 -- Section 14 - Acknowledgments 1913 [E] This is a good place to thank everyone who's reviewed the 1914 document, commented on ideas in it, or helped in other ways. 1916 Accepted 1918 Acknowledge Mallikarjun Chadalapaka and David Black. 1920 Comment 83 1922 -- Section 15 - Contributors' Addresses 1924 We'll try this structure of not separating the folks listed on p.1 1925 from the other contributors and see if there are any procedural 1926 objections. It's unusual to say the least. 1928 Unusual demands beget unusual responses. 1930 Comment 84 Technical 1932 -- Annex A - IANA Considerations 1934 [T] Instruct IANA to change the authority for those port allocations 1935 to reference this RFC when it is approved. Add a sentence forbidding 1936 the use of UDP with FCIP even though IANA has allocated a port. 1938 Accepted 1940 Comment 85 1942 -- Annex A - IANA Considerations 1944 [T] Will need to reference the SOF/EOF registry that the FC Frame 1945 Encapsulation Draft will need to set up. Point to the Protocol# 1946 allocation done by that draft also. If a connection usage registry 1947 is needed (see comment against Section 8, details of that will have 1948 to go here). 1950 Accepted (Partially) 1952 Add discussion of Protocol# allocation. 1954 The SOF/EOF registry will not happen. 1956 Comment 86 1958 -- Annex A - IANA Considerations 1960 [E] Should the ANNEXes be APPENDIXes instead? 1962 Accepted, make exactly the proposed change 1964 Comment 87 1966 -- Annex C - Example of synchronization recovery algorithm 1968 [T] See comment on this Annex under Section 6.6.2.3 above. 1970 See response to comment 37. 1972 2. Comments from Mallikarjun Chadalapaka 1973 ===================================== 1975 Comment 88 1977 > 2. Purpose, Motivation and Objectives 1978 ...... 1979 > Network. Since Fibre Channel and IP Networking technologies are 1980 > compatible, 1982 I am not sure what's implied by this sentence.... 1984 Generally, I would think that the motivation to extend an FC SAN 1985 using IP networks is based on the ubiquity of the IP networks. 1987 No changes made 1989 The cited phrase says that it is technologically possible to use 1990 IP Networks to extend FC SANs. That is, IP Networks are NOT tin 1991 cans and strings, but are in fact electromechanical signaling 1992 systems that are similar enough to FC to be useful in FC SANs. 1994 Comment 89 1996 > 2. Purpose, Motivation and Objectives 1997 ...... 1998 > The fundamental assumption made in this specification is that the 1999 > Fibre Channel traffic is carried over the IP Network in such a 2000 > manner that the Fibre Channel Fabric and all Fibre Channel 2001 > devices on the Fabric are unaware of the presence of the IP 2002 > Network. 2004 Can someone please comment on the protocol interactions that result 2005 in the failure to set up an FCIP Link if this latency expectation is 2006 not met? 2008 Inquiry 2010 All data frames will fail their transit time test and will be 2011 discarded. No data will move from application to application and 2012 the end users will riot. 2014 Comment 90 2016 > 2. Purpose, Motivation and Objectives 2017 ...... 2018 > 2) apply the mechanism described in 1) to an FC Fabric using an 2019 > IP network as an interconnect for two or more islands in an 2020 > FC Fabric. 2022 S/b "an" w/ "the"; S/b "for" w/ "between" 2024 Accepted (Partially) 2026 Change "for ... islands" to "between ... islands". 2027 Do not change "an IP Network" to "the IP Network" because 2028 this specification assumes that there can be more than one 2029 IP Network. 2031 Comment 91 2033 > 3. Relationship to Fibre Channel Standards 2034 ...... 2035 > FC is standardized under American National Standard for 2036 > Information Systems of the National Committee for Information 2037 > Technology Standards (ANSI-NCITS) in its T11 technical committee. 2039 I believe ANSI stands for American National Standards Institute. 2040 Also, NCITS had been changed to INCITS last year. 2042 Accepted with the following result 2044 Replace the cited text with: "FC is standardized as a family of 2045 American National Standards developed by the T11 technical committee 2046 of INCITS (InterNational Committee for Information Technology 2047 Standards). 2049 Comment 92 2051 > 3. Relationship to Fibre Channel Standards 2052 ...... 2053 > FC-BB and FC-BB-2 describe the relationship between an FC Fabrics 2054 > and interconnect technologies not defined in by Fibre Channel 2055 > standards (e.g., ATM and SONET). FC-BB-2 is the natural Fibre 2056 > Channel home for describing relationships to TCP/IP and FCIP. 2058 This is the first instance of FCIP's usage as a *protocol*. It would 2059 be best preceded by a definition of what FCIP means as a protocol. 2060 The previous text only describes the objectives of the document, but 2061 not the protocol. 2063 Accepted but not as intended 2065 The section in which the cited text appears is attempting to 2066 describe the relationship between standards documents. The second 2067 sentence in the cited text fails to maintain the purpose of the 2068 section. 2070 Actions to be taken 2072 Replace the second cited sentence with: "FC-BB-2 is the Fibre 2073 Channel document describing the relationships between FC and 2074 TCP/IP, including the FC use of FCIP. 2076 Comment 93 2078 > 3.2 This Specification and Fibre Channel Standards 2079 ...... 2080 > No attempt is being made to define a specific API between an FCIP 2081 > Entity and an FC Entity at this time because doing so risks 2082 > compromising the performance and efficacy of the resulting 2083 > products. 2085 I am somewhat concerned that the names are implying an incorrect 2086 distribution of functionality between "FC Entity" and "FCIP 2087 Entity".... 2089 From the name, I had assumed that FC Entity is simply a standard FC 2090 fabric element with no FCIP-isms. But further reading of the document 2091 made me realize that it in fact knows about the TCP connections and 2092 even actively participates in QoS and authentication decisions. 2094 As a first time reader, it appears to me that retaining only the FC 2095 E_Port functionality perhaps additionally providing timestamp and flow 2096 control services to the FCIP Entity (and dropping everything else into 2097 the FCIP Entity) may be a lot cleaner distribution of functionality. 2098 At any rate, I would like to understand the current distribution 2099 rationale. 2101 BTW, can someone please clarify if the expected "role" of the FC 2102 Entity on the FC side is indeed an E_Port? It appears so from the 2103 requirement that FCIP be totally transparent to the FC fabric, but I 2104 don't see it called out in Annex G. 2106 Inquiry 2108 The process of developing FCIP has shown repeatedly that FCIP 2109 should contain only the Fibre Channel knowledge required to 2110 interact with TCP/IP. Attempting to include FC concepts such 2111 as R_A_TOV only leads to confusion in the IP Network community 2112 that in turn leads to proposals for changes in FCIP that are, 2113 in fact, proposals to change the definition of R_A_TOV in ways 2114 that are unacceptable to T11. 2116 The dividing line between an FC Entity and an FCIP Entity 2117 is drawn along political not technological lines. 2119 To understand the function of an FC Entity, you must read 2120 FC-BB-2, http://www.t11.org/t11/docreg.nsf/ldl/fc-bb-2. 2122 Comment 94 2124 > 3.2 This Specification and Fibre Channel Standards 2125 ...... 2126 >....fully functional and compliant 2127 > products can be built provided they contain both an FCIP Entity 2128 > and an FC Entity. The only products that cannot be built are 2129 > those that contain only one or the other. 2131 The last sentence seems to stress the obvious at first glance, but I 2132 would think that products with just the FC Entity should be able to be 2133 built (not that one would...) to act as regular fabric elements with 2134 no FCIP features? 2136 Also, I take it that products with two FC Entities and one FCIP Entity 2137 for ex. are disallowed - but the last sentence seems to imply 2138 otherwise. 2140 No changes made 2142 This section and the cited paragraph are about the compliance 2143 relationship between FCIP and FC-BB-2. The Model section is 2144 where the numbers of FC Entities and FCIP Entities are discussed. 2146 Comment 95 2148 > 4. Terminology 2149 .... 2150 > FCIP Entity - The principal FCIP interface point to the IP 2151 > Network (see section 6.4). 2153 This doesn't sound right to me....this definition is more appropriate 2154 for FCIP_LEP. This can perhaps be described as "the entity responsible 2155 for the FCIP protocol exchanges on the IP Network and which 2156 encompasses FCIP_LEP(s) and FCIP Control & Services module". 2158 Accepted 2160 Comment 96 2162 > 5. Protocol Summary 2163 ... 2164 > 2) Viewed from the IP Network perspective, FCIP Entities are 2165 > peers and communicate using TCP/IP. Each FCIP Entity is a TCP 2166 > endpoint in the IP-based network. 2168 The second sentence seems a little context-sensitive, since each FCIP 2169 Entity can be the TCP endpoint for several TCP connections. 2171 Changed as described in the response to comment 14. 2173 Comment 97 2175 > 5. Protocol Summary 2176 ... 2177 > 3) Viewed from the FC Fabric perspective, pairs of FCIP 2178 > Entities, in combination with their associated FC Entities, 2179 > serve as an FC Frame transmission component of the FC Fabric. 2180 > The FC End Nodes are unaware of the existence of the FCIP 2181 > Link. 2183 Can a "FC Frame transmission component" be something other than an 2184 E_Port? 2186 Inquiry 2188 An FC Frame transmission component can also be a B_Port. 2190 Comment 98 2192 > 5. Protocol Summary 2193 ... 2194 > 6) An FCIP Entity MAY contain multiple FCIP Link Endpoints, 2195 > but... 2197 I would add "each of which MAY service multiple TCP connections, " 2198 here... 2200 Rejected 2202 Such a change would detract from the focus on the point to be made. 2204 Comment 99 2206 > 5. Protocol Summary 2207 ... 2208 > 7) When multiple FCIP_LEPs with multiple FCIP_DEs are in use, 2209 > selection of which FCIP_DE to use for encapsulating and 2210 > transmitting a given FC Frame is outside the scope of this 2211 > document. FCIP Entities do not actively participate in FC 2212 > Frame routing. 2214 Couple of comments on this bullet (7) - 2216 Let's consider the case of multiple FCIP_DEs in one FCIP_LEP. This 2217 draft does not specify how each inbound FC frame from the FC fabric 2218 is distributed onto one of these FCIP_DEs (TCP connections). Where is 2219 it specified in wrt routing on TCP connections? I take it that the 2220 regular FC fabric routing rules aren't quite applicable in this case. 2222 To stress the obvious, I think we should have some standard covering 2223 this case - else we will end up with frames destined to the same D_ID 2224 being striped on multiple TCP connections, and thus ending up OOO. 2226 Accepted in principle 2228 The standard covering the questions raised by this comment is 2229 FC-BB-2. 2231 Action to be taken 2233 Replace "...is outside the scope of this document." with "...is 2234 covered in FC-BB-2 [4]." 2236 Comment 100 2238 > 5. Protocol Summary 2239 ... 2240 > 13) On a given TCP Connection, this specification relies on 2241 > TCP/IP to deliver a byte stream in the same order that it was 2242 > sent. 2244 Perhaps we should add - ", but allows confirmation of the same for 2245 each frame by checking the FCIP and FC CRCs.".... 2247 Rejected 2249 1) FCIP has no CRC to check. 2) It is difficult to see how checking 2250 the FC CRC would confirm in order delivery. 2252 Comment 101 2254 > 6.3 FC Entity 2255 .... 2256 > the combination shown in figure 3. As another example, the 2257 > combination cannot be used to replace cable connections in a 2258 > Fibre Channel Arbitrated Loop because loop primitive signals 2259 > cannot be encapsulated for transmission over TCP. 2261 I am not sure the last sentence is needed since figure 3 is explicit 2262 about the usage of fabrics. 2264 Changed as described in the response to comment 24. 2266 Comment 102 2268 > 6.4 FCIP Entity 2269 ...... 2270 > The FCIP Entity is the connection interface point for the IP 2271 > Network 2273 As commented earlier, the "connection interface point" doesn't sound 2274 totally correct - I would suggest "interfacing element" instead. 2276 Accepted 2278 Comment 103 2280 > 6.4 FCIP Entity 2281 ...... 2282 > and is the owner of the IP Address and Well Known Port used to 2283 > form TCP Connections. An FC Fabric to IP Network interface 2284 > product SHALL provide each FC Entity FCIP Entity pair contained 2285 > in the product 2287 May I suggest a new term "FC-FCIP Pair" in place of "FC Entity FCIP 2288 Entity pair ". 2289 I think it improves the general readability. 2291 Accepted with the following results 2293 Change all occurrences of "FC Entity FCIP Entity pair" to 2294 "FC/FCIP Entity pair" to match the terminology used in FC-BB-2. 2296 Also add the following to section 4: 2298 FC/FCIP Entity pair - The combination of one FC Entity and one FCIP 2299 entity. 2301 Comment 104 2303 > 6.4 FCIP Entity 2304 ...... 2305 > FC Entity with an interface to key IP Network features. The 2306 > interfaces to the IP Network features is implementation specific, 2307 > however, to maintain interoperability, the notable TCP/IP 2308 > mechanisms used are specified in this document as follows: 2310 I think the last sentence is incorrectly implying interoperability 2311 issues around the (private) FC Entity-FCIP Entity interface. 2313 I would suggest a rewrite for the last sentence as something like - 2315 "The interfaces to the IP Network features are implementation- 2316 specific. To aid interoperability, this document specifies the 2317 notable TCP/IP Network features that are typically used." 2319 Changed as described in the response to comment 28. 2321 Comment 105 2323 > 6.5 FCIP Link Endpoint (FCIP_LEP) 2324 .... 2325 > An FCIP_LEP 2326 > MAY communicate with its FC Entity counterpart to coordinate 2327 > flow control. 2329 Suggest adding the phrase "across the domains". 2331 Rejected 2333 Without a definition of "domains" such a change adds confusion, 2334 not reduced it. 2336 Comment 106 2338 > 6.6 FCIP Data Engine (FCIP_DE) 2339 ...... 2340 > 7) In the absence of errors, the de-encapsulated FC Frame and 2341 > time stamp SHALL be passed to the FC Transmitter Portal for 2342 > delivery to the FC Entity. 2344 It is nice to add a sentence about the handling in the presence of 2345 errors. At a minimum, this should provide a cross-reference to the 2346 error detection section. 2348 Accepted with the following results 2350 Add the following at the end of the paragraph: "Error handling is 2351 discussed in section 6.6.2.2." 2353 Comment 107 2355 > 6.6.1 FCIP Encapsulation of FC Frames 2356 .... 2357 > The FCIP Special Frame SHALL only be sent as the first bytes 2358 > transmitted in each direction on a newly formed TCP Connection 2359 > and only one FCIP Special Frame SHALL be transmitted in each 2360 > direction at that time (see section 9.1). After that all FCIP 2361 > Frames SHALL have the SF bit set to 0. 2363 This para seems slightly out of context here, and perhaps should be 2364 moved to section 9.1. This usage semantics should ideally be preceded 2365 by what *is* a Special Frame and its purpose - though I could gather 2366 that from the usage and format descriptions in the entire document, I 2367 don't really find a place where its purpose is defined... 2369 Accepted, see response to comment 44 2371 Comment 108 2373 > 6.6.1 FCIP Encapsulation of FC Frames 2374 .... 2375 > Table 1 summarizes the usage of the pFlags SF and Ch bits. 2377 - It may be useful to add a protocol-specific bit to distinguish 2378 originated vs echoed SF, so the parsing and validation can be self- 2379 contained. 2381 - Also, I think a sentence should be added which says that the - 2382 pFlags field SHALL contain the ones-complement of the pFlags field. 2384 Accepted 2386 Comment 109 Technical 2388 > 6.6.1 FCIP Encapsulation of FC Frames 2389 .... 2390 > The CRCV (CRC Valid) Flag SHALL be set to 0. 2391 > 2392 > The CRC field SHALL be set to 0. 2394 I am surprised that the FCIP encapsulated header is never protected 2395 by a CRC. The error detection section clearly acknowledges the 2396 possibility that TCP checksum could be inadequate for certain 2397 deployments - and even suggests checking the FC frame CRC (sort 2398 of like a data digest) on reception at the Encapsulated Frame 2399 Receiver Portal. 2401 My recommendation is to require an FCIP Entity to employ the header 2402 CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's 2403 approach. So, I guess I am also advocating a new bit in the pFlags 2404 field to announce this. When this CRC expectation is announced, the 2405 FC CRC checking test in 6.6.2.2 should also be a mandatory test - 2406 from the "semi-optional" list it is currently in. 2408 Accepted with the following result 2410 Add the following to the new section created in response to comment 2411 44: "Note: Owing to the limited manner in which the FSF is used and 2412 the requirement that the FSF be echoed without changes before a TCP 2413 connection is allowed to carry user data, no error checking beyond 2414 that provided by TCP is deemed necessary." 2416 Comment 110 2418 > 6.6.2 FCIP Data Engine Error Detection and Recover 2420 The last word in the above should be "Recovery". 2422 Accepted 2424 Comment 111 2426 > 6.6.2.1 TCP Assistance With Error Detection and Recovery 2427 ...... 2428 > Thus, the byte stream passed from TCP to 2429 > the FCIP_LEP will be in order and free of errors detectable by 2430 > the TCP checksum. If TCP did not perform these functions, the 2431 > FCIP_LEP would have to. 2433 Suggest rewording the last sentence (TCP always performs these 2434 functions to *its* satisfaction, the question is if FCIP feels the 2435 same; secondly, FCIP_LEP's error mgmt behavior is not dynamically 2436 contingent upon TCP's behavior as this sentence implies) - 2438 "To address the possibility that TCP did not perform these functions 2439 adequately in a given FCIP deployment context, the FCIP_LEP verifies 2440 if these expectations are met." 2442 Changed as described in the response to comment 32. 2444 Comment 112 2446 > 6.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames 2447 ...... 2448 > Further, some errors in the encapsulation will result in the 2449 > FCIP_DE losing synchronization with the FCIP frames in the byte 2450 > stream 2452 I don't see "frames" here with the uppercase "F" used everywhere 2453 else. 2455 Also, one observation is that FCEncap document uses "frames" 2456 consistently throughout, whereas this document chooses to use 2457 uppercase "F" (mostly). 2459 Accepted with notes 2461 "FCIP frame" s/b "FCIP Frame". That is a specific named 2462 construct that is defined and used in FCIP. 2464 FC Frame Encapsulation uses "frame" (lowercase) when referring 2465 to a Fibre Channel frame because lowercase frame is the Fibre 2466 Channel term. 2468 Comment 113 2470 > 6.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames 2471 ...... 2472 > 1) Length field validation -- 15 < Length < 545; 2474 I assume "Frame Length" is meant by "Length" above. 2476 Accepted with the following results 2478 Change "Length" to "Frame Length". 2480 Comment 114 2482 > 6.6.2.3 Synchronization Failures 2483 ...... 2484 > If an FCIP_DE determines that it cannot find the next FCIP Frame 2485 > header in the byte stream entering through the Encapsulated 2486 > Frame Receiver Portal, the FCIP_DE SHALL either: 2488 S/b "either" w/ "do one of the following". 2490 Accepted 2492 Comment 115 2494 > 6.6.2.3 Synchronization Failures 2495 ...... 2496 > b) recover synchronization by searching the bytes delivered by 2497 > the Encapsulated Frame Receiver Portal for a valid FCIP Frame 2498 > header having the correct properties 2500 Useful to refer to 6.6.2.2 here for "correct properties". 2502 Accepted 2504 Comment 116 2506 > 7. Checking FC Frame Transit Times in the IP Network 2507 .... 2508 > requirement in the FC Entity is based on a desire to include 2509 > the Frame. 2511 S/b "in" w/ "on" 2513 Accepted 2515 Comment 117 Technical 2517 > 7. Checking FC Frame Transit Times in the IP Network 2518 .... 2519 > ... If no synchronized time stamp value is available to 2520 > accompany the entering FC Frame a value of zero SHALL be 2521 > supplied. 2523 From this, it isn't clear to me if FCIP *requires* only Synchronized 2524 operation. If so, the draft should also specify how implementations 2525 are expected to deal with "benign" transitions into and out of the 2526 Unsynchronized state (i.e. transitions happening when no Encapsulated 2527 Frames are being received). 2529 Rejected 2531 Class F frames can be transmitted and forwarded in the 2532 Unsynchronized state. 2534 The requirements for transit time determinations are in FC-BB-2 2535 for all the reasons described in the response to comment 40. 2537 Comment 118 2539 > 7. Checking FC Frame Transit Times in the IP Network 2540 .... 2541 > The FC Entity SHALL 2542 > verify that the FC Entity it is communicating with on an FCIP 2543 > Link is using the same synchronized time source as it is, either 2544 > Fibre Channel services or SNTP server. 2546 I see a chicken-and-egg problem for some implementations: Since Fibre 2547 Channel time services are not available until the FCIP Link is 2548 successfully set up and since timestamp is to be carried on every FC 2549 Frame (including those Fibre Channel time service exchanges) once the 2550 Link is set up, the only decent option for an implementation (assuming 2551 it supports only Synchronized operation) is to rely on SNTP server. 2552 Is this correct? 2554 If Unsynchronized operation is intended to be disallowed (my earlier 2555 question), then it seems to me that SNTP is the only option. 2557 Inquiry 2559 Yes but Unsynchronized operation is allowed precisely so that 2560 Class F frames can be processed to setup the FC Time Services Time 2561 for use by the FC Entity in computing transit times. 2563 Comment 119 2565 > 8. The FCIP Special Frame 2566 ...... 2567 > The FCIP Special Frame SHALL only be sent as the first bytes 2568 > transmitted in each direction on a newly formed TCP Connection 2569 > and only one FCIP Special Frame SHALL be transmitted in each 2570 > direction. 2572 A general comment on this wording (and others similar to this). I 2573 would suggest rewording (to be much stronger) to: 2575 The FCIP Special Frame SHALL be the first application data exchanged 2576 on each newly formed TCP connection, and only one FCIP Special Frame 2577 SHALL be transmitted in each direction. 2579 Rejected 2581 The use of "application data" could cause confusion with 2582 application data generated by FC Endnodes. 2584 See also comment 44 for more information on the SF and how it will 2585 be described in the next FCIP revision. 2587 Comment 120 2589 > 8. The FCIP Special Frame 2590 ...... 2591 > Note: The combination of the Source FC Entity World Wide Name and 2592 > Source FCIP Entity Identifier fields uniquely identifies every FC 2593 > Entity FCIP Entity pair in the IP Network. 2595 - S/b "Source FCIP Entity Identifier" w/ "Source FC/FCIP Entity 2596 Identifier" 2598 - Also I take it that the "FC/FCIP Entity Identifier" is unique only 2599 within the scope of the given FC Entity's WWN. So, does the model 2600 allow multiple FCIP Entities to be associated with the FC Fabric 2601 Entity WWN? 2603 - From this statement, it implies to me that the Destination FC/FCIP 2604 Entity Identifier must be present in the special frame to ensure 2605 that the TCP connection is indeed established to the right "FC/FCIP 2606 Entity" under the scope of the given Destination FC Fabric Entity 2607 WWN. What am I missing? 2609 Accepted (Partially) as follows 2611 Make the change described in the first bullet. 2613 Response to the second bullet: Yes, the "FC/FCIP Entity Identifier" 2614 is unique only within the scope of the given FC Entity's WWN. Yes, 2615 the model allows multiple FCIP Entities to be associated with the FC 2616 Fabric Entity WWN. 2618 The following changes will be made to clarify this and other issues 2619 raised during the discussion of this comment on the ips list. 2621 Add the following to section 4: 2623 FC Fabric Entity - A Fibre Channel specific element containing 2624 one or more Interconnect_Ports (see [FC-SW-2 ref 5]) and one or 2625 more FC/FCIP Entity pairs. See FC-BB-2 [4] for a details about 2626 FC Fabric Entities. 2628 Change the title of figure 3: 2630 from: FC Entity and FCIP Entity Model 2631 to: Model for Two Connected FC/FCIP Entity Pairs 2633 Add the following sentence at the end of the paragraph preceding 2634 figure 3: 2636 An FC Fabric Entity may contain multiple instances of the FC/ 2637 FCIP Entity pair shown on either the right-hand or left-hand 2638 side of figure 3. 2640 Change the first sentence following figure 4: 2642 from: 2644 The FCIP Entity is the connection interface point for the IP 2645 Network and is the owner of the IP Address and Well Known Port 2646 used to form TCP Connections. 2648 to: 2650 The FCIP Entity receives TCP connect requests on behalf of the 2651 FCIP_LEPs that it manages. In support of this, the FCIP Entity 2652 is the sole owner of at least one TCP port/IP Address 2653 combination used to form TCP Connections. The TCP port may be 2654 the FCIP well known port at a given IP Address. 2656 Response to the third bullet: The motivation for permitting the 2657 "Destination FC Fabric Entity WWN" to be zero is to allow the 2658 SF to be used as a poor-man's SLP (a configuration discovery 2659 mechanism). This usage is described in the new section added in 2660 response to comment 44. 2662 Comment 121 2664 > 8. The FCIP Special Frame 2665 ...... 2666 > The Destination FC Fabric Entity World Wide Name field MAY 2667 > contain 2669 Why isn't the above requirement a SHALL? 2671 Inquiry - see the response to comment 120. 2673 Comment 122 2675 > 9.1.2.2 Dynamic Creation of New TCP Connections 2676 ... 2678 > - The expected Destination FC Fabric Entity World Wide Name of 2679 > the FC Entity FCIP Entity pair to which the TCP Connection is 2680 > being made 2681 > - TCP Connection Parameters (see section 9.3) 2682 > - Quality of Service Information (see section 11) 2683 > 2684 > Based on this information, the FCIP Entity SHALL generate a TCP 2685 > connect request [8] to the FCIP Well-Known Port of 3225 (or other 2686 > configuration specific port number) at the IP Address specified 2687 > by the service advertisement. If the TCP connect request is 2688 > rejected, act to limit unnecessary repetition of attempts to 2689 > establish similar connections. If the TCP connect request is 2690 > accepted, the FCIP Entity SHALL follow the steps described in 2691 > section 9.1.2.3 to complete the establishment of a new FCIP_DE. 2692 > 2693 > It is recommended that an FCIP Entity not initiate TCP connect 2694 > requests to another FCIP Entity if incoming TCP connect requests 2695 > from that FCIP Entity have already been accepted. 2697 This entire text is duplicated from previous section 9.1.2.1. Seems 2698 like we could do with one instance (possibly in a new subsection). 2700 Rejected 2702 The information on connection establishment is indeed common to 2703 section 9.1.2.1, but its relationship to SLP is not. Section 9.1.2.2 2704 already is less than one page long, that and a desire to have some 2705 amount of readable flow (as opposed to "do this, then do what it 2706 says to do over there, then do that, then do this other thing that 2707 is talked about in another section") seems like ample motivation for 2708 the current organization. 2710 Comment 123 2712 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2713 ...... 2714 > All fields in the FCIP Special 2715 > Frame SHALL be filled in as described in section 8, particularly: 2717 While the sentence above is unequivocally clear, I don't understand 2718 the need for all the text that follows "particularly".... It is 2719 confusingly repetitive since as far as I can tell, all these are 2720 covered in more or less the same language in section 8. 2722 No changes made 2724 The draft is structured so that the Special Frame can be used 2725 for more features than just initial connection setup. As of yet, 2726 additional uses have not been defined, but it seems prudent to 2727 simplify such enhancements to ensure that future versions remain 2728 correct with minimal editorial effort. 2730 In keeping with this, section 8 describes the overall SF format 2731 and section 9.1... defines SF usage during connection setup. 2733 Comment 124 2735 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2736 ...... 2737 > After the FCIP Special Frame bytes are sent on the newly formed 2738 > connection, the FCIP Entity SHALL wait for the FCIP Special Frame 2739 > to be echoed as the first bytes received on the newly formed 2740 > connection. 2742 - S/b "bytes are" w/ "is" 2743 - S/b "first bytes" w/ "first TCP segment data" 2744 - I take it that the onus is on the FCIP Entity that did the TCP 2745 active open to send the SF. That leads me to: What if there's a TCP 2746 simultaneous open? 2747 Would not each end up sending the SF and waiting for the echo? 2748 Also, would not the earlier rule on only one frame being transferred 2749 in each direction be violated then? 2751 Accepted (Partially) as follows 2753 Make the change described in the first bullet. 2755 Do not make the change described in the second bullet because it 2756 requires more knowledge of TCP than FCIP should have. 2758 The last issue is resolved as per the response to comment 57. 2760 Comment 125 2762 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2763 ...... 2764 > If the echoed FCIP Special Frame bytes do not exactly match the 2765 > FCIP Special Frame bytes sent (words 7 through 17 inclusive), the 2766 > FCIP Entity SHALL close the TCP Connection and notify the FC 2767 > Entity with the reason for the closure. 2769 Seems like all the 11 words are required to be compared. If so, what 2770 is the Ch bit being used for? IOW, why SHALL it be set by the 2771 responder? 2773 Inquiry 2775 The Ch bit serves to identify the difference between changes 2776 made intentionally by the echoing FCIP Entity and changes that 2777 result from transmission errors. 2779 Comment 126 2781 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2782 ...... 2783 > The FCIP Entity SHALL listen for new TCP Connection requests [8] 2784 > on the FCIP Well-Known Port (3225). An FCIP Entity MAY also 2785 > accept and establish TCP Connections to a TCP port number other 2786 > than the FCIP Well-Known Port, as configured by the network 2787 > administrator. 2789 It may be useful to add that this usage is outside the scope of this 2790 document. 2792 Accepted with the following results 2794 Add "... in a manner outside the scope of this specification." at 2795 the end of the last cited sentence. 2797 Comment 127 2799 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2800 ...... 2801 > The FCIP Entity SHALL determine the following information about 2802 > the requested connection: 2803 > 2804 > - Whether the requested connection is allowed 2806 I take it that by means not specified in this spec? If so, it's 2807 useful to call it out. 2809 Accepted with the following results 2811 1) Change "Whether the requested connection is allowed" to "Whether 2812 the "shared" database (see section 9.1.1) allows the requested 2813 connection"; and 2814 2) Ensure that this change is applied wherever it is needed. 2816 Comment 128 Technical 2818 > 9.1.3 Processing Incoming TCP Connect Requests...... 2819 > abort the TCP connect request [8]. If the requested connection is 2821 I was told that "abort" isn't available on all implementations - 2822 perhaps "abort/close" would be better.... 2824 Accepted with the following results 2826 Change "abort the TCP connect request [8]" to "reject the connect 2827 request using appropriate TCP means" 2829 Comment 129 2831 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2832 ...... 2833 > The FCIP Entity MAY apply a timeout of not less than 90 seconds 2834 > to the waiting for the FCIP Special Frame bytes and if the 2835 > timeout expires the FCIP Entity SHALL close the TCP Connection 2836 > and notify the FC Entity with the reason for the closure. 2838 I am not clear why this notification is required, since the local FC 2839 Entity did not motivate the TCP connection establishment. If it is 2840 intended for logging, perhaps notifying the Control & Services module 2841 would be more appropriate. 2843 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2844 ...... 2845 > If the Connection Nonce field contains a value identical to the 2846 > most recently received Connection Nonce from the same IP Address, 2847 > the FCIP Entity SHALL close the TCP Connection and notify the FC 2848 > Entity with the reason for the closure. 2850 Same comment. 2852 Rejected 2854 Current plans call for the MIB interface to be in the FC Entity. 2855 Therefore, this notification is necessary for MIB logging. Also, 2856 requirements are being added to FC-BB-2 that depend on the 2857 requirement as stated in FCIP. 2859 Comment 130 2861 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2862 ...... 2863 > 1) Leave the Destination FC Fabric Entity World Wide Name field 2864 > and Ch bit both 0; 2866 So allow the FCIP Link to be established? It is unclear to me how 2867 implementations adopting this option would be able to prevent 2868 unintended FCIP Link formation. 2870 Accepted 2872 A requirement needs to be added somewhere that the TCP Connection 2873 MUST be closed if the echoed Destination FC Fabric Entity World Wide 2874 Name field contains zero. 2876 Comment 131 Technical 2878 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2879 ...... 2880 > 2) Change the Destination FC Fabric Entity World Wide Name field 2881 > to match FC Fabric Entity World Wide Name associated with the 2882 > FCIP Entity that received the TCP connect request and change 2883 > the Ch bit to 1; or 2885 In effect, this is being indirectly allowed as a legal discovery 2886 process. Is there a DoS concern here? Also, would revealing the FC 2887 WWN be acceptable in confidentiality terms? 2889 Duplicate of comment 53. 2891 Comment 132 2893 > 9.1.2.3 Connection Setup After a Successful TCP Connect Request 2894 ...... 2895 > 3) Close the TCP Connection without sending any response. 2897 I like this option best, :-) 2899 Inquiry 2901 See comment 53. 2903 Comment 133 2905 > 10.2 FC Fabric and IP Network Deployment Models 2906 ...... 2907 > Entities in an equal manner. This varies from a true Client- 2909 S/b "varies" w/ "differs". 2911 Accepted 2913 3. Comments from Don Fraser 2914 ======================== 2916 Comment 134 2918 9.1.3 (page 31) 2920 "If an FCIP Entity receives a duplicate FCIP Short Frame during the 2921 FCIP Link formation process,..." 2923 "Short Frame" s/b "Special Frame" 2925 Accepted 2927 Comment 135 2929 Annex G (page 63) 2931 The reference to section 9.5, should refer to 9.4. 2933 Accepted 2935 Comment 136 2937 Annex G 2939 The table should have a number and title like the rest of the 2940 tables in the document. Also, do not put just the table header 2941 on a page by itself. 2943 Accepted 2945 4. Comments from Murali Rajagopal 2946 ============================== 2948 Comment 137 2950 -- Section 5 Protocol Summary 2952 8) The FCIP Control & Services function MAY use TCP/IP quality of 2953 service features (see section 11.2) to support Fibre Channel 2954 capabilities. 2956 [E] "function" s/b "Module". 2958 Accepted 2960 5. Comments from Bob Snively 2961 ========================= 2963 Comment 138 2965 -- 6.6.2.3 Synchronization Failures 2967 I would suggest the following minor editorial correction: 2969 b) return to sending valid FC Frames only after 2970 synchronization has been verified; and 2972 should be changed to: 2974 b) return to emitting frames through the FC Transmitter 2975 Portal only after synchronization has been verified; and 2977 Accepted with changes 2979 Make the change as written, except replace "emitting" with 2980 "forwarding". 2982 6. Comments from Ralph Weber 2983 ========================= 2985 Comment 139 2987 Annex C (first step in algorithm) 2989 "f) Reserved field and its ones complement." 2991 The "reserved" field is now pFlags. 2993 Accepted 2995 Comment 140 Technical 2997 The bit/byte numbering resolution approved for the FC Frame 2998 Encapsulation draft must be replicated in this draft. 3000 Accepted 3002 Comment 141 Technical 3004 In order to support the FC-BB-2 Link Keep Alive (LKA) switch 3005 internal link service, it is necessary for FC/FCIP Entities to 3006 communicate a time interval for transmission of the LKA. The 3007 T11 FC-BB-2 working group has asked that this 32-bit quantity 3008 be added to the Special Frame. 3010 Accepted 3012 Comment 142 3014 Update contributors and acknowledgements. 3015 Update contact information for Murali Rajagopal. 3016 Move Jim Nelson from contributors to acknowledgements since Jim no 3017 longer is FC-FS editor and has provided no updated contact 3018 information. 3020 Accepted