Tentative ForCES Minutes

[Patrick Droz <[e-mail]>]

attached a first version of the minutes please send me your
comments if you want changes or additions.

Thanks,
Patrick


Minutes ForCES WG, IETF66, Montreal, Canada
===========================================

Attendees 33


Agenda:

Monday, July 10, 2006, 15:20-17:20
==================================

CHAIRS:   David Putzolu <[e-mail]>
           Patrick Droz <[e-mail]>

ADs:      Ross Callon <[e-mail]>
           Bill Fenner <[e-mail]>

10 min - WG status & Agenda Bash - chairs

15 min - SCTP based TML (Transport Mapping Layer) for ForCES protocol
          Jamal Hadi Salim
          draft-hadi-forces-sctptml-00

10 min - Applicability statement
          Hormuzd M Khosravi
          draft-ietf-forces-applicability-04.txt

10 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol
          Hormuzd M Khosravi
          draft-ietf-forces-tcptml-03.txt

10 min - ForCES MIB
          Patrick for Robert Haas
          draft-ietf-forces-mib-03


WG Status by the chairs:

Chair is asking for volunteers to take minutes as usual nobody was to be
found. Therefore, the chair recorded the meeting in order to produce
some reasonable minutes.

The chair announces that there is a new TML draft that addresses SCTP.
Jamal the author had already asked to make this a WG draft as TML are
part of the ForCES charter. Discussion on this will take place after his
presentation.
Then Hormuzd will give an update on the Applicability Statement and on
the TCP based TML. A final presentation will be on the MIB which the
chair is presenting in the name of Robert.

The chair then gives a status of the group. There is a rather big
problem still with the model draft. Since the last meeting only little
progress had been achieved. Due to the dependency of most of the other
draft the model will probably hold back all the other drafts including
the protocol draft that has been forwarded to the IESG. During the last
meeting some people had volunteered to help Joel on the draft but there
was only little input so far. The chair asks the working group to
contribute to the model to move forward. The chair mentions some of the
discussions on the wg chairs list about what to do with working groups
that do not make progress. It is mentioned that some chairs suggest the
shut down of the wg. This would be quite unfair to the contributors,
editors, and authors of the other drafts.

Q Hormuzd: there were some contributions on the list on the model. There
was not a lot of detailed feedback. I am not exactly sure what Joel is
looking for.

A chair: there are still open issues, Joel had posted a whole list of
them to the list. All of these things have to be closed first.

Q Hormuzd: would it be possible for the editors to put a straw model
draft out that would be ready for last call and then get feedback on that?

A chair: this should be discussed with Joel as he posted the list of
open issues that he would like to have closed first. Joel had expressed
to the chair that he was quite disappointed that so little progress had
been made since the last meeting. As Joel has written quite a number of
documents he knows quite well when a document is ready to be moved on.

Jamal: there are a number of issues that have been open for a long time.
Joel says that he was asked by people to put things in put people do not
respond on the list anymore to close them.

Chair: what we need is to get some common consensus that the draft is in
reasonable state to get advanced.

Jamal: we should probably set a deadline for people to respond to the
open issues then close it or even remove some of these features.

Chair: agreed.

During the status update no other issues were raised and the group moved
on to the presentations.

--------------------------------------------------
SCTP based TML draft by Jamal:
The draft is a proposal for a SCTP based TML draft. The draft matches
the SCTP capabilities against the TML requirements which are fully
matched when not perfect. The first comparison is done again TCP, UDP,
and DCCP. SCTP compared to TCP provides ordered, reliable, connection
oriented, flow controlled and congestion controlled data exchange. It is
message oriented rather than byte streaming. Compared to UDB it provides
message boundaries, unordered and unreliable data exchange. It does not
provide true multicast. Compared to DCCP it provides all the services
that DCCP has. It can provide unreliable, ordered, congestion controlled
connections. SCTP can be made to behave like any of the other three.
SCTP has additional features like multi-homeing. You can have multiple
IP addresses that appear as one end-node. It has runtime IP binding (via
ADDIP) where you can dynamically bind to IP addresses. It also provides
r range of reliability shades plus congestion control. You can have
partial reliability not like in TCP where you have total reliability.
This is appropriate for events that do get obsolete. Timeframes can be
specified in which messages become obsolete. It has built-in
heartbeating which are not very different from TCP keep-alives. The
multi-streaming allows for having multiple streams between to
end-points. So between the FE and CE you only need one socket. Message
boundaries plus reliability,
improved SYN DOS protection, simpler transport events, and
simplified replicasting are additional features that SCTP offers. Some
of these features may not be implemented yet.
So why to use SCTP? Because it has everything in one package, you don.t
need to use different transports. All the others need more than one
protocol. This allows simpler programming. I am not trying to make the
other proposals down I rather just want to have a single protocol. SCTP
is very mature compared to DCCP, as it has been around for a couple of
years and also widely deployed. Most operating systems support. It also
offers additional features like high availability and sub-streaming
concept for data versus control traffic separation. This means that the
channel is basically within the socket. Between the protocol and the TML
there is a TML API. Ten between the TML and the SCTP there is the SCTP
socket API. These APIs will not be discussed in this presentation.
Meeting the TML requirements we have first the reliability it.s a given
by SCTP. The second requirement is congestion control. All data can be
congestion controlled by SCTP. Next one is timeliness. There is a
feature called PR-SCTP with which messages can be time limited. In case
a message is not sent before the time limit then the message is locally
dropped. And the message is acknowledged after the time limit it is
ignored. The next thing is prioritization. This is not implemented some
more code is needed. It will allow for the prioritization of multiple
streams. PL addressing to peers can be done with the replicast feature
of SCTP where a packet is replicated and sent to several destinations.
It is not as good as UDP multicast but is saves you bandwidth between
the user space and kernel. Encapsulation is not needed. Then we have HA
which is actually the reason for looking at SCTP. There are things like
multi-homing where you can have multiple paths between the two end
points. In case one path goes away you can switch without TML
intervention. There is reliability and fault detection due to built in
heart-beat mechanism on a peer IP address base. There is a data
transmission threshold on a per peer IP address base. The migration of
IP address from one node to another can be achieved through ADDIP. On
the last slide Jamal asks the WG to make the draft a WG document. There
was no comment in the meeting.

A chair: we should send a request to the mailing list and feel the pulse
of the members. Jamal should send a mail to the list.

----------------------------------------------------
Applicability draft by Hormuzd
As a quick refresher the draft is about the applicability of the ForCES
protocol and model. Some of the applicable Services include discovery,
capability and topology information, routing, QoS, security, filtering,
NAT, and tunneling. But the draft also talks about limitations and
out-of-scope. Out-of-scope examples are layer 2 switching and
multi-media gateways. Also the locality principle is given that the CE
and FE should not be more than one IP hop apart. The main areas that
were updated in the draft is the manageability section. Furthermore,
there were some editorial changes. The changes are based on feedback at
the last IETF meeting. The text on the manageability section on CE to CE
communication has been clarified. Explanation by Avri it basically means
that if you have an NE with multiple CEs you have to do it on your own
the protocol will not address this setup. Avri will also talk to the ops
area on the manageability section. They may come back with some more
recommendations. Hormuzd then asks for additional feedback on the draft.

Q ??: what does one hop mean, is this one IP hop?
A Hormuzd: yes, one IP hop

Q ??: can this be an Ethernet network.
A Hormuzd: yes the restriction is one IP hop.

The authors would like to have a LC on the draft but will wait for the
model draft because it might require some additional changes for the model.

----------------------------------------------------
TCP TML draft by Hormuzd
This draft is also very close to LC. The sections that have been update
are HA, TML service interface, and clarification / editorial changes. On
the HC sections the changes are the following. DCCP generated
connectivity loss indication will now be propagated by the TML. In case
more active monitoring is needed. The PL should arrange for a suitable
redirect packet to be sent from the FE to the CE at regular intervals.
There is no need for bidirectional check. The TML service interface
section has been moved to the Appendix and a not has been added that
this text in not complete and it will by specified in a separate draft.
This decision was made in the last meeting.

Q Hormuzd: is that separate draft a WG document.
A chair: yes, it was made a WG document under the condition that a time
plan will be followed for delivery.

Based on feedback a number of clarifications have been made. Correction
were made in the protocol initialization, security, and prioritization
section. Furthermore some editorial updates were made.
Q Hormuzd: does this draft need a manageability section or is the
manageability section in the applicability statement sufficient.
A Avri: manageability sections is still very voluntary. There is no
requirement for having one. In this case the idea was to have one in the
applicability statement that covers all the ForCES drafts. So this means
that if this draft requires addition text in the manageability sections
it should be added to the applicability draft. But of course there is no
harm in putting one in each draft.
Q Hormuzd: but what would be the content of it. Wht should go in there.
A Jamal: the parameterization of the TML might go in there
Q Jamal: Is there something that needs to be managed by the protocol
A Avri: Parameters and things that need to be configured should be in
there. If it affects other protocols

Hormuz asks for further comments on this draft.

Q Jamal: you said that the TML service interface has been mobbed to the
Appendix. What is the situation with this standalone draft is it a WG
document
A chair: yes, it was made a WG document under the assumptions that it is
really going to happen and in timely fastion.
A Jamal: it will going to happen.

----------------------------------------------------
MIB draft by Patrick for Robert:
Some modification to the draft have been made since the last meeting.
The version 01 of the draft was actualy last called by the WG. This
triggered some feedback that was incorporated into the verion 02 of the
draft. We added the ForCES highest protocol version supported by the CE.
Then we added notifications to indicate association going up or down.
Important to note is the fact that OID in a .down. notification refers
to an object that is no longer in the MIB as associations going down are
immediately removed from the table. Currently it is assumed that there
is no need for rate-control notifications as they are driven by the CE
accepting FE association. Feedback on this is asked . is it a valid
assumption. A further change was made that UP/DOWN/ESTABLISHING state
information has been removed since only UP state will be kept in the
MIB. Then in the association table the protocol version and counters
were added. As shortly after submission of the 02 draft further comments
came a version 03 had been released. In order to comply with RFC 2578
the FE/CE ID were made not-accessible. Before, they were read-only. In
addition, mandatory conformance information has been added, all stat
objects are optional. But one has to implement all or nothing. They
could be split into a time and counter group. Comments from the working
group are welcome if somebody would prefer just to implement the
counters or the time. Please respond to the list. Due to the fact of
multiple versions in the mean time we probably go for another LC before
contacting the MIB doctors.

In the end th chair again asked the WG to emphasize its engagement on
the model draft as it is a central document for the ForCES WG. Without
it we cannot really make progress. The WG is asked to contribute and
comment on the various drafts.

--
   Dr. Patrick Droz                  | [e-mail]
   IBM Zurich Research Laboratory    | http://www.zurich.ibm.com/~dro
   Saumerstrasse 4                   | Tel. [phone]
   CH-8803 Rueschlikon/Switzerland   | Fax. [phone]