SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: IPS Draft Charter update



    
    
    David,
    
    The charter looks good and is well balanced.
    
    I am however concerned that if we include all the work items - including
    discovery - in the first version we might either miss our schedule or have
    a half baked solution.
    
    Can we exclude those from the first version and add them (either as a
    separate/complementary spec) in the MIB timeframe?
    
    A separate spec. could have the added advantage of being a good fit for
    several infrastructures.
    
    Julo
    
    
    
    
    
    Black_David@emc.com on 20/07/2000 06:07:32
    
    Please respond to Black_David@emc.com
    
    To:   ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  IPS Draft Charter update
    
    
    
    
    Slightly updated version of the draft charter.  Comments
    are welcome/encouraged, especially on the proposed schedule.
    There will probably be an opportunity to bash the charter
    in Pittsburgh, but bashing done on the list doesn't consume
    time in the meeting.
    
    --David
    
    IP Storage (ips) Working Group Proposed Charter - DRAFT 4
    
    There is significant interest in using IP-based networks to transport
    block storage traffic.  This group will pursue the pragmatic approach of
    encapsulating existing block storage protocols, such as SCSI and certain
    Fibre Channel protocols, in an IP-based transport or transports.  The group
    will focus on the transport or transports and related issues (e.g.,
    security,
    naming, discovery, and configuration), as opposed to modifying existing
    block
    storage protocols.  Standards for those protocols are controlled by other
    standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]).  The WG
    cannot assume that any changes it desires will be made in these standards,
    and hence will pursue approaches that do not depend on such changes unless
    they are unavoidable and in that case will create a document to be
    forwarded
    to the standards group responsible for the technology explaining the
    issue and requesting the desired changes be considered.  The WG will
    endeavor to ensure high quality communications with these standards
    organizations.
    
    The storage protocols to be encapsulated expect a reliable transport,
    in that failure to deliver data is considered to be a rare event for
    which time-consuming recovery is acceptable.  This has implications
    for both the choice of transport protocols and design of the
    encapsulation(s).  Encapsulations of the storage protocols may require
    quality of service assurances (e.g., predictable latency) to operate
    successfully; the WG will consider what assurances are appropriate and
    how to provide such assurances in shared traffic environments
    based on existing IETF QoS mechanisms such as Differentiated Services.
    
    Use of an IP-based transport raises issues that do not occur in existing
    storage transports.  The WG will address at least the following issues:
    - Congestion control suitable for shared traffic network environments, such
    as
         the Internet.
    - Security measures, including authentication and privacy, sufficient
         to defend against threats up to and including those that can be
         expected on a public network.
    - Storage naming and discovery mechanisms for block storage services
         on IP-based networks, including both discovery of storage for
         access by the discovering entity, and discovery for management.
    - Management, including appropriate MIB definition.
    
    The WG will consider issues raised by bridges and gateways to existing
    implementations of block storage protocols in order to support effective
    interoperability of the protocols developed in the working group with other
    implementations and/or encapsulations of the same block storage
    protocol(s).
    The WG will strive to support the approaches to discovery, multi-pathing,
    and booting taken by the existing block storage protocols it encapsulates
    at the levels of those protocols.
    
    It may be necessary for block storage traffic to pass through Network
    Address Translators (NATs) and/or firewalls in some circumstances; the
    WG will endeavor to design NAT- and firewall-friendly protocols that do
    not dynamically select target ports or require Application Level Gateways.
    
    Effective implementations of some IP transports for block storage traffic
    are likely to require hardware acceleration; the WG will consider issues
    concerning the effective implementation of its protocols in hardware.
    
    The standard internet checksum is weaker than the checksums used by
    existing
    block storage implementations.  The WG will consider what levels of data
    integrity assurance are required for block storage traffic over IP networks
    and how they should be achieved.
    
    The WG will produce a framework document describing the encapsulation or
    encapsulations it intends to pursue, and requirements, applicability
    and protocol specification documents for each encapsulation.  The framework
    document will consider whether both end-system and gateway node (including
    gateways to Fibre Channel) requirements can be accommodated in a single
    protocol
    family (e.g., as has been done by the IP Security Protocol).  The
    applicability
    and requirements documents will consider both disk and tape devices and
    take
    note of the variation in scale from single drives to large disk arrays and
    tape libraries; the protocols need not be applicable to all such devices.
    
    The WG will not work on:
    - Extensions to existing block storage protocols beyond those strictly
         necessary for the use of IP-based transports.
    - Modifications to internet transport protocols or approaches requiring
         transport protocol options that are not widely supported,
         although the WG may recommend use of such options for block storage
         traffic.
    - Support for environments in which significant data loss or data
         corruption is acceptable.
    - File system protocols.
    
    Milestones
    
    Aug 00 Initial meeting in Pittsburgh.  Launch framework discussion to
         select encapsulation approach or approaches.
    Sep 00 Publish initial version of framework draft reflecting WG consensus
         on encapsulation approach or approaches.
    Dec 00 Discuss framework, and requirements, applicability
         and protocol specification drafts at IETF meeting in San Diego.
    Jan 01 Submit framework and at least one set of requirements,
    applicability,
         and protocol specification drafts to IESG.
    Mar 01 Discuss MIB(s) and any ancillary drafts required to use the
         specified protocols at IETF meeting in Minneapolis.
    May 01 Submit primary MIB draft to IESG.
    
    Aug 01 Meet at IETF meeting to close any open issues and finish any
    outstanding
         work items.
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:08:06 2001
6315 messages in chronological order