Subject: tentative minutes

From: Patrick Droz <[email-masked]>
Date: Tue, 16 Mar 2004 14:27:32 +0100

attached are the tentative minutes from the last IETF.
Please let me know if you would like to have some changes
or extensions. Many thanks again to the minutes taker Sue
and Hormuzd.

Regards,
Patrick

--------------------- cut here --------------------------

ForCES Minutes - IETF59, Seoul, South Korea,

Forwarding and Control Element Separation WG (ForCES)

Tuesday, March 2 at 0900-1130
=============================

CHAIRS: David Putzolu <[email-masked]>
         Patrick Droz <[email-masked]>

attendees: 62 (signed the blue sheet)

AGENDA:

5  min - WG status & Agenda Bash - chairs

40 min - Transparent Inter Process Communication protocol
          proposal - Jon Maloy
          http://www.ietf.org/internet-drafts/draft-maloy-tipc-00.txt

20 min - A Testbed for GRMP Protocol - Dr. Ligang Dong

20 min - Updated Forces FE model (Steven Blake)

All presentations from the meeting are available at the following
web site:
http://www.sstanamera.com/~forces/Ietf59/index.html

1) WG status

    Status:

	1) Charter
	    We need to update the charter.
	    Please look at the charter and see if the
	    dates are reasonable?  Comments should be sent to
	    the mailing list or David or Patrick as chairs.

	2) Document status:

	    a) Forces framework has been approved for publication as an RFC.
	    b) Forces Model was just released in February
		- It's over 100 pages.
		- Should we consider splitting into 3 different drafts.
	    c) Evaluation Drafts
		[draft-ietf-forces-evaluation-00.txt]
		- 3 protocols proposed, and an evaluation draft worked.-
		- Design team formed to determine if a merger is possible.
		  Design team will report back on March 20th.

		- Please send comments to the list on what might be good.

	   d) Applicability statement is on hold until further work completed on
               other drafts.
	      draft-ietf-forces-applicability-02.txt

2) Transport Inter Process Communication

	TIPC is not a ForCES protocol but rather a transport protocol.
	It is freely available under Linux. It offers also reliable
	multicast.
	
	Discussion:

	    Joel Q: asks 1) Whether the stack could support multiple channels
		(Ethernet, UDP, etc.) simultaneously, and if so how they would
		be selected.
	    Jon A: it could support such, and that the decision was based on
		scope (a cluster used ethernet, inter cluster used other
		mechanisms.)
	    Joel Q: asks 2) whether they had implemented inter cluster or
		internee support.
	    Jon A: they had not completed that work.
	    Joel Q: Is there a keep alive protocol assumed by TIPC?
	    Jon A: Yes, there is an underlying protocol sending probes.
		 There is a underlying timer that watches the probes
		 to see if it comes back.
	    David Putzolu Q:
		Did you determine a connection has a loss or is in error in
		the transportation?
	
	    Jon Maloy A: There is a queue on each link.  On this queue the 
buffers will
		be released once the messages arrives.  when this queue exceeds a
		certain limit, then the messages will be tossed.

		The process trying to send the messages will queue messages if congestion
		is detected in the transport.

		On the receiving side, the messages will be rejected if the messages are
		in error.  A messages will be sent back indicating the error.	

	    Hormuzd Q: Is it possible to address a message to multiple LFBs ?
	    Jon A: This is possible for multicast, unicast will be on per LFB basis

3)20 min - A Testbed for GRMP Protocol - Dr. Ligang Dong
	Introduction to Testbed - deployment
	CE code using VC++
	Smartbits software used to measure packets

	Introduction of the experiments on the testbed:
	    2 experiments - one for configuration of LFB, second for
		redirection packets/DoS attacks
	    2 scheduling schemes - FCFS, priority based, rate based
	        with RR experiments with scheduling strategy from linux
		kernel

	    Hormuzd Q:
		Did you experiment with different packet size?

	    Dr. Dong A:
		answer; yes.

	    David Putzolu Q:
		Did you try a congestion aware protocol for the control channel?

	    Dr. Dong A:
		Yes, we did.  The results (table 3) on the slides.  The information
		is partially complete.  We will be doing more.

		Table 1 - is about the loss of control packets.

3) Updated Forces FE model (Steven Blake)  [20 minutes]

	URL:  http://www.petri-meat.com/sblack/networking

	3rd revision of document.

	David Putzolu Q: The url does not work for the XML

	Steve Blake A: Perhaps we can get this working. 		

	Joel Halpern Q:
		It would good to have a location to get all the XML for forces.

	Steve Blake A:
		May be the working group can provide a location to put all the
		XML on.   We don't really know where to put XML.
		MIBs are contained in files.
	
	Joel Halpern: we are looking for feedback on the XML information.

	Open issues:
		1) Is the augmentation useful
		2) How useful are input groups?
		3) in which documents will the protocol payload associated with the LFB
			attributes be defined?
			- forces model?
			- LFB Class definitions?
			- Protocol specifications?

	Pending work items:
		(be ready for last call in August)
		1) Define rules and schema extensions for LFB class derivations via 
inheritance
		2) Support for data type augmentation (if needed)
		3) Inclusions of type and Class IDs (if needed)
		4) Rules for version handling
		5) Simplistic handling of LFB class definition using the LFB Library 
schema
		6) Improve schema representation of capability attributes for
		   an associated attribute.

	Discussions:
	  Lily:  1st two items are related
		  The primary reason we have data type augmentation is for inheritance.
		  We'd like feedback on that
-- 
   Dr. Patrick Droz 			| [email-masked]
   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

---

From: Steven Blake <[email-masked]>
Date: Tue, 16 Mar 2004 09:50:26 -0500

>         URL:  http://www.petri-meat.com/sblack/networking

Should be
http://www.petri-meat.com/slblake/networking/drafts/forces-model-02.pdf

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-991

You wouldn't be seeing the following text if my employer
didn't block ports 25 and 110.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Alex Audu <[email-masked]>
Date: Wed, 17 Mar 2004 12:31:42 -0600

For where to define the protocol payload associated with LFB attributes,
I'll vote
for  LFB Class definitions .

Alex.

Patrick Droz wrote:

>         1) Define rules and schema extensions for LFB class
> derivations via inheritance
>         5) Simplistic handling of LFB class definition using the LFB
> Library schema