NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
Chair(s):
Murali Rajagopal <murali@gadzoox.com>
Internet Area Director(s):
Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>
Internet Area Advisor:
Jeffrey Burgan <burgan@home.net>
Mailing Lists:
General Discussion:ipfc@standards.gadzoox.com
To Subscribe: ipfc-request@standards.gadzoox.com
In Body: subscribe
Archive: standards.gadzoox.com/pub/archives/ipfc/ipfc
Description of Working Group:
The importance of running IP and ARP over Fibre Channels has reached a critical point wherein a standardized approach seems to be the only solution. Historically over the past few years, there have been a multitude of attempts and approaches to implementing IP and ARP over Fibre Channel (FC). This has resulted in islands of implementations with no interoperability. Several vendors from the Fibre Channel Association (FCA) have proposed taking this problem to the IETF with the intent of generating one "standard" specification.
This working group will be responsible for standardizing a specification that will allow IP and ARP to ride over various Fibre Channel topologies, which may include point-to-point, Loop, and Fabric.
The specification will include procedures and protocols for the broadcast of ARP packets between Fibre Channel devices and an encapsulation mechanism to carry IP payloads.
Objectives:
1. Specify a Standards Track procedure for broadcasting ARP packets and resolving IP to FC MAC address and FC MAC to FC port address
2. Specify a Standards Track encapsulation for carrying IP over FC.
Goals and Milestones:
Aug 98 |
|
Review progress at Chicago IETF meeting; resolve outstanding issues |
Oct 98 |
|
Submit ARP/Encapsulation draft to IESG for consideration as Proposed Standard |
Dec 98 |
|
Review status of WG |
Internet-Drafts:
· Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard
No Request For Comments
The 43rd IETF Meeting in Orlando had 31 attendees. There were many new company reps. Including international attendees (Korea, Germany, Japan, France). The companies that were in the room included: Brocade, Sony, 3Com, NEC, Compuserve, Lucent, Ericsson, IBM, EMC, Boeing, Qlogic, Tellabs, Emulex, ADC, Fujitsu, Compaq, among others.
The meeting addressed issues and comments raised by many on the reflector
1. NAA Issue : Compaq wanted to optionally include other NAA Types besides the IEEE 48-bit addresses. Their motivation was that their future SAN were likely to use other addressing schemes.
Resolution: The group was generally opposed to this and the suggested resolution by the two IESG Area Directors present in the room was that, Compaq could generate another RFC as an extension to the present one. It was stated that this approach was commonly taken in the IETF process and would not result in delays to the movement of the existing draft. Second, since allowing other NAA Types was proposed as an option, this would not result in implementations that were supposedly compliant but could not interoperate because of the optional nature. However, the IETF would still approve the DRAFT standard if there were at least 2 interoperable implementations of the optional components of the spec.
Action: It is now up to Compaq to write a separate draft and bring it to this group and drive it. For DRAFT STD. at least interoperable implementations are required.
2. MTU Issue: There was some disagreement on the MTU sizes in the 03.txt draft because it did not include optional IP headers.
Resolution: Min MTU and Max MTU was specified by Gadzoox to include the IP Optional headers and agreed to by the group.
- The Max MTU for IP: 65,280 bytes.
- The Min MTU for IP: 92 bytes
- The Max MTU = Min MTU for ARP: 52 bytes
- Action: Include this in 04.txt
3. Inverse ARP Issue: Raj Bhagwat initiated this protocol as a way to solve the lack of broadcast support in some implementations.
Resolution: The group was against making this is a mandatory requirement. The group agreed to include this as an optional parameter with the proper wording without causing a concern for interoperability problems
Action: Include this in the 04.txt with appropriate wording
4. Multiple IP Addresses per MAC address for InARP Issue: This requirement was originated by Jeff Stai from Brocade as a Fibre Channel VI requirement.
Resolution: The proposed solution of just one IP address representing a group of IP addresses was inconsistent with the way it works in Frame Relay according to Jeff Burgan/Tom Narten. Therefore it was suggested that some scheme be devised if this was really required, even if it meant a number of InARP Replies one for each IP association. The suggestion was to look into some Frame Relay solutions for a similar problem.
Action: If this is really required include the new scheme in the 04.txt.
5. Modes of FARP and Interoperability Issue: Ezio from Brocade believes that the spec. as it is written today may end up having interoperability problems. FARP specifies two mechanisms.
1. Resolving <WW_PN, Port_ID>
2. Resolving <IP Address, Port_ID>. Although, FARP is optional today, if a node receives a request to resolve the WW_PN to Port_ID then the Reply is mandatory. The real problem arises when an implementation only supports the second FARP mechanism and not the first.
Resolution: The group felt that the second method should be entirely removed form the document. The group felt that the only way the second method could stay in the document if it was properly reworded. EMC's suggestion was to require all implementations to support the first method in a reply and to optionally allow support for the second method. So if a FARP request using the second method arrives first where there is no support, then a silent behavior is acceptable as it states today, but additionally the node ought to be able to retry using the first method. Note that still means that a FARP implementation is optional on Requests for either mechanism and optional for Reply using the second mechanism (silent behavior).
Action: The suggestion was that 04.txt draft shall word-smith the document specifying this behavior.
6. Next Step: The 04.txt document will include the suggested changes. The goal is to send out the 04.txt document out before the end of the year.
7. MIB: It is anticipated that the MIB work will reassume during the March/April meeting.
None received.