SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iFCP: Minutes authors' confcall Fri December 21st


    • To: "IPS Reflector (E-mail)" <ips@ece.cmu.edu>
    • Subject: iFCP: Minutes authors' confcall Fri December 21st
    • From: Franco Travostino <travos@nortelnetworks.com>
    • Date: Fri, 21 Dec 2001 16:10:42 -0500
    • Content-Type: multipart/alternative;boundary="=====================_197112723==_.ALT"
    • Sender: owner-ips@ece.cmu.edu


    Attendees:

    Wayland Jeong, Troika Networks
    Charles Monia, Nishan Systems
    Franco Travostino, Nortel Networks
    Josh Tseng, Nishan Systems

    1. Debrief from IETF 52th IPS WG

    Wayland was brought up to date on IPS news in SLC, including the new standard-track status for the IPS security draft. From the IESG plenary, FT took home a couple of guidelines against a) exceedingly long authors' lists, and b) exceedingly long standard-track documents. None of the above was seen as applicable to iFCP.

    2. The road to iFCP 08.txt and Last Call

    2.1 Detection of multiple broadcast servers

    In SLC, Charles presented the new, TCP-based approach to realizing broadcast services. In a given zone, broadcast clients (many) and server (one) would be associated dynamically, with the latter advertising its presence to the iSNS. An external comment/concern was presented about two or more broadcast servers unduly coexisting in the same broadcast zone, as a result of misconfigurations, transient network partitions, etc. Since SLC, the authors have exchanged notes on how to best prevent this syndrome from happening. CM described the final solution, which entails a) adding "Broadcast Server" as an attribute in iSNS, b) administratively setting the broadcast server's WWN for a zone into iSNS, and c) having the broadcast server query the iSNS server, and match its own WWN with the one in the iSNS' reply, prior to actually joining the zone and start its broadcast duties.

    2.2 Maintaining liveness

    The aforementioned broadcast clients and server can use a keep-alive mechanism to check their connections. Such optional mechanism is best thought of as a FCP no-op, and purposely refrains from using the underlying TCP keepalive features. Liveness granularity can be dynamically set. Given that the broadcast sessions are undistinguishable from regular iFCP sessions after creation, the authors note that this optional liveness mechanism also applies to iFCP sessions. Regular iFCP sessions may use the liveness mechanism to refresh state in NA(P)T, firewall intervening boxes, and to assemble a somewhat meaningful history of IP prop times.

    2.3 Update on Charles' latest changes regarding address translation model et al.

    Work is well on its way, the authors will get a sneak preview the first week of January.

    2.4 Security

    Certificate words are the last known words still missing in action. JT and FT will exchange notes on a draft text, which they will then submit to the IPS security list for review.

    2.5. Misc.

    Happy Holidays


    -franco


    Franco Travostino, Director Content Internetworking Lab
    Advanced Technology
    Nortel Networks, Inc.
    600 Technology Park
    Billerica, MA 01821 USA
    Tel: 978 288 7708 Fax: 978 288 4690
    email: travos@nortelnetworks.com


Home

Last updated: Fri Dec 28 14:17:39 2001
8210 messages in chronological order