tentative minutes

Patrick Droz <dro@zurich.ibm.com> Fri, 28 March 2003 13:26 UTC

Message-Id: <FRI.28.MAR.2003.142624.0100.>
Date: Fri, 28 Mar 2003 14:26:24 +0100
From: Patrick Droz <dro@zurich.ibm.com>
Organization: IBM Research
Subject: tentative minutes
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable

Attached are the tentative minutes from the last IETF.
In case you want to have something changes please let
me know. I intent to submit them to the IETF server
early next week.

Regards,
Patrick

ForCES IETF 56 Meeting Minutes

About 100 persons attended the meeting. Thanks to
Hormuzd for taking notes.

FACT - Ram Gopal

Ram presented a protocol overview including the NE model
and the message structure,

Q Adam - why CE tag if one CE is active?
A Ram - cause of multiple CE sets

He then showed message classes and the types. Afterwards
the association phase including the sequence of
operations were shown. Also the states of the elements
were introduces.

Q Jamal - Is this CE-to-CE or FE-to-FE communication?
A Ram - NO, CE-to-FE.

Then the normal operation phases were given. Finally
some other features were given like 2 phase, command
bundling, and high availability (HA).

Q XYZ - Can this be used only for post-association?
A Ram - yes, but certain configuration needs to be done in pre-association
Q Adam - All IP Address are only 32 bits, is that on purpose?
A Ram - No, this need to be fixed


Netlink2 - Robert Haas

The reasoning why Netlink2 is derived from netlink
is because netlink is already widely used in linux
systems as a message-based interface between control
code (usually running in user space) and forwarding
code (kernel space) to perform, for instance, IP
routing, ARP, QoS, etc. Netlink2 extends netlink to
address the fact that CEs and FEs can be distributed.
The Netlink2 header is an extension of the netlink
header with slight changes, and supports optional
TLVs. FEs and CEs have unique PIDs. Logical PIDs can
be used to group FEs and CEs. Netlink2 extends the
concept of the netlink wire to Netlink2 wires and
bundles that are built with IP unicast and multicast
addresses to enable scalability and high-availability.

Q XYZ - How do multiple CEs send messages to multiple FEs?
A Robert – by different multicast addresses

Netlink2 has built in reliability, it has a
prioritization method, an ACK strategy to confirm
messages. It support atomicity, ordering and
batching.  The flexibility of Netlink2 comes from
its wires & bundles. In the current version of
the draft there is no capability discovery yet.

Q Alex - The draft does not seem to give specifics about configurations. 
Lots of should/could but no details ?
A Jamal - last section talks about this, the draft gives mechanisms, 
need to add details
Q Alex - What about Scalability issues?
A Jamal – by using broadcast and multicast
Q Lorenzo Vicisano (co-chair of reliable multicast WG) - Scalability 
might be limited by reliability
A Robert – reliable multicast methods from this WG should be used if needed.

FE Model - Ram Gopal

Ram showed the FE Block and the block library. On
the Issue list he had - topology discovery out of
scope, no restriction of FE block layout, control
of topology CE or FE? The intend is to provide a
bunch of handles and do not represent topology.

Q XYZ - what do you mean by logical loops & physical loops?
A Ram - physical - layout of board, logical - blocks can have some logic
Q Jamal - looping to same instance should be allowed
A Ram - yes, this depends on the block properties
Q Joel - describe blocks on wire and in doc and need input from WG
Q Jamal - no constraint on how many FE blocks can be connected, add some 
text for this.
Q Chair - Has the doc been read?
A Quite a few people have read the draft but more people should be involved.
Chair – Should further discuss the draft on the mailing list


TIPC (Telecom Inter Process Communication) - Jon Maloy

TIPC is high-speed, reliable message oriented
communication service specially designed for cluster
environments. They implemented the FACT proposal on
top of TPIC and using XML encoding.  The protocol
has a logical addressing scheme and agile connections.
It was claimed that TIPC is easily portable. It runs
on different interconnects (over Ethernet, UDP/IP,
SCTP/IP).

Q Alex - Why TIPC over SCTP, it is already a transport?
Q - how does TIPC addressing work on IP?
Q - is it used most of the time over Ethernet or over IP ?
A Jon - over Ethernet,
Q - then why 2 addressing schemes?
A – for logical addressing

TIPC is location transparent, and FE binds to services.
At the start of the synchronization the topology
detection takes place.

Q Jamal - is this built into TIPC ? or in lower transport ?
A Jon - yes

Demo of FACT/XML over 2 P4 systems

Q Alex - what is the latency of the switch?
A Jon - currently 1 sec
Q Jamal - how big is this protocol? Would it fit on top of a router?
A Jon - code size is 15,000 loc
Q - why is it inside the kernel?
A - for performance reasons


-- 
   Dr. Patrick Droz                     | dro@zurich.ibm.com
   IBM Zurich Research Laboratory       | http://www.zurich.ibm.com/~dro
   Saumerstrasse 4                      | Tel. +41-1-724-85-25 CH-8803
   Rueschlikon/Switzerland              | Fax. +41-1-724-85-78