Subject: ForCES Minutes, IETF 62 Minneapolis, USA

From: Patrick Droz <[email-masked]>
Date: Wed, 23 Mar 2005 09:43:25 +0100

Minutes ForCES WG at the IETF62 in Minneapolis St. Paul, USA
------------------------------------------------------------

Agenda, IETF 62

Monday, March 7, 2005, 9:00-11:30
=================================

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

ADs:      Alex Zinin <[email-masked]>
           Bill Fenner <[email-masked]>

AGENDA:

10 min - WG status & Agenda Bash - chairs

10 min   ForCES Intra-NE Topology Discovery
            Furquan Ansari
            draft-ansari-forces-discovery-01.txt

15 min - ForCES Forwarding Element Model
            Joel Halpern
            draft-ietf-forces-model-04.txt

30 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol
            Shuchi Chawla
            draft-khosravi-forces-tcptml-01.txt

30 min - ForCES Protocol Draft Status & Changes
            Avri Doria or Jamal Salim
            draft-forces-protocol-02.txt

Minutes
-------

Attendees: 35

Unfortunately there was no volunteer to take minutes therefore,
I recorded the meeting.

The chairs began the meeting by reviewing the agenda and then going
over the status of the group. It was stated the the protocol was
expected to go through 1 or 2 more drafts before going to WG Last
Call.

----------

Presentation 1: Furquan Ansari
draft-ansari-forces-discovery-01.txt

We then went into a discussion on the first agenda item on FE topology
discovery. A first version of the draft had been presented in the last
IETF meeting but at that time not many people had read the document. In
the meantime quite some animated discussions took place on the mailing
list. And the list came to the consensus that the draft does make sense
and that is useful to have. There was no presentation of the draft. Main
topic was to decide whether we should adopt the draft as a WG draft.

Furquant repeats that the draft has been discussed on the list and that
it seems we have reached consensus on making it a WG draft.

Chair: proposes to make the draft a WG draft but wants to follow up
first with the ADs.

Q Avri: I am not against the draft but why do you have to check with the
ADs first?

A chair: Because the charter is too vague on that. It does not prevent
us from doing but also does not say we must do it.

After checking with the ADs the draft is now a WG document.

----------

Presentation 2 Joel Halpern
draft-ietf-forces-model-04.txt

There has been made significant progress on the model and the protocol
draft and especially to line them up with each other. He presents the
changes that have been made since the last version. Also the open issues
      were presented.

Changes in brief: in the previous draft there was a thing that described
the FE this was done by a separate schema and then the protocol team
asked to make this an LFB. So the model has been changed that the FE
information is now in an LFB class. There is now an ID for the class and
an ID for the instance. But there is only one instance. So this is now
much cleaner. There were several request to have the ability to address
tables and arrays by value. So there are now methods put in place to say
that this table can be referenced by value. People also wanted to have
methods to share information among multiple LFBs, this is now achieved
by introducing the alias mechanism. The model also turned out to have
some missing type definitions so one was added but a second one might be
needed as well.

Changes in more depth:
    - FE schema changed into an LFB class definition using the same schema
that all LFB classes are using. This is now the only LFB class that is
defined in the model document. The LFB class definition go now into a
library document. This class is assigned class ID 1 and instance ID 1.
It is important to note that it is always 1 since it is the
bootstrapping of the protocol. It captures all the information that was
in the FE schema. When the CE comes up it gets connection to the FE then
it says give me LFB class ID 1, instance ID 1. Give me the whole thing.
However, this is not mandatory. But this is the typical scenario.
Assigning the instance ID like this is a bit unusual. Certainly more
information need to ge into the LFB class, more capabilities and
attributes are needed. The list is asked to come up with the missing
pieces. Probably there will be a similar LFB class to represent the
interaction with the ForCES protocol with the FE. That will probably be
included in the protocol document because it has protocol relevant
information rather then model relevant information.
    - Element identifiers - The protocol now references information
through class ID, instance IF of an LFB and a sequence of attribute or
element identifiers with array subscripts. So those numbers need to be
defined. Each one is defined within a given scope. Within a given LFB
class they have to be unique. But they do not have to be unique across
classes. But it is much cleaner and simpler than what we had to do in
SNMP. However there is an interesting point. The way the protocol and
the model is structured we assume the LFB class ID are globally unique.
How to make that work? Global uniqueness is always an interesting
problem. Should we keep a global list of all the class IDs? We need to
do something to make them easily globally unique. At the moment we do
not know how to do it. LFB class, attributes, capabilities, and
structure element have an ID. There is an ongoing stylistic debate on
what belongs into attributes or nested tags. Many WGs that are using XML
are having this debate when to use tags and when to use attributes. So
we thought using attributes was an appropriate thing to do. If somebody
has an issue with this please speak up now or raise it on the list.
    - Content keying - There was a major request for the ability to
reference arrays and table elements by their content instead of just by
their subscript. So we are supporting this. Get and set operations are
supported. There was a big debate on the list what the scope of this
should be. Joel thinks there was WG consensus but he knows what he has
written on the foils. Key 'ContentKey' is only for predeclard keys and
they must be unique within their tables. There is an example given in
the presentation. You can declare to have multiple key fields and that
declares that the combination of multiple key fields in a single key.
That means the combination of the fields is the key and the combination
must have a unique value on every entry in the array. You can also have
multiple key declarations that declare each of these keys is unique in
every entry of the array and you can use anyone for reference. That is
the current compromise on content keying. How to call this keys is not
completely settled yet. There was also some XML violations that had to
be fixed. According to the XML folks introducing a container would solve
the problem. This is almost an editorial change. It does not affect the
protocol at all.
    - Alias -  There are situation and this can be debated for ever where
LFBs need to share information e.g. ARP LFB sharing MAC addresses. So a
way is needed to describe sharing. There are multiple ways to achieve
this e.g. an LFB owns the information and the other LFBs can point to
it. That approach is being taken. This is basically a pointer. Now what
are the properties of such pointers. The pointer needs to contain what
class of LFB it points to, what instance of the LFB you are pointing to,
what attribute within the LFB you are pointing to, and something that
you can use to get the data. So you can declare within a LFB class
definition or structure that something is an alias. An alias is used to
point to something else. An alias has a type. All the way the protocol
works everything is strictly typed. Therefore, the alias has to have a
type. So per alias we need to have four related pieces of information.
We wanted to have things simple. You create an alias, then give it a
type and under the cover create a structure that can take all four
pieces. They can be chained. The concept lets you easily reference
information at other places.

Q: if you make an alias and it points somewhere and then you remove that
element. What happens to the alias?
A: We do not want to require automatic cleanup. This is an important
question and we have to solve this. In other cases you may also point to
something that does not exist. So we would probably require that you get
back Nil / Null as a result. We need to define this and what the
behavior of dangling pointers is.

    - Open Issues -
The list of the 5 open issues is:
o Configured Adjacency Description -
o Element Meta Information
o Events
o Optional Elements
o Unlimited length strings

In more detail:
- Configured Adjacency Description - The FE object has in it a set of
information about configured FE neighbors. This is what the WG decided.
This includes information of the MAC and IP address of the neighbor.
This seems to be the natural way of configuring neighbors. Jamal raised
an interesting alternative. This kind of configured neighbors is really
used by the CE that has multiple things that it controls who are
neighbors to each others. A better way to discover this is the ansari
draft on FE topology discovery but there was a request to have the
configuration capability. So what when you just configured the neighbor
FE ID and the port that he reaches you. This will tell you how to send a
messages to the guy because this is enough information. So we basically
have to methods of identifying neighbors. What is important is that we
have to pick one method. It is important to note that this is for
configured neighbors and not for real discovery.
Q. What happens if you use both methods could you get a conflict.
A: Yes, if you configure both you could indeed get a conflict. You could
mix up some of the values. So you do not want to use both. We have to
pick one or the other. That is why I brought it up.

- Element Meta Information - We have LFB elements, structure elements,
in the model and referenced by the protocol. These elements have
properties. The simplest property is, does it exist, is it readable, is
it writeabel. It may have other properties. We have foreseen for LFB
level capabilities that are described in the model. And if you look at
the FE object LFB it has a capability section. So this was captured but
only at the LFB level. If you have an FE with a structure of option
elements, how do you know whether they are supported. If you have a
structure that is readable or read / writeabel how do you know what
information there is. Just try it? Maybe we need to find a consistent
way of talking about properties of elements. When you think about
arrays, arrays have an additional set of properties. How many elements
do you have currently, what is the highest subscript currently being
used, maybe what is the first hole that might be useful for reusing the
space. So arrays have more complicated properties. When you look at the
aliases I was showing you earlier, you can easily talk about pointers
that have properties of the actual pointer element. It makes the alias
cleaner if you can talk separately about the properties and its values.
Then the value would always be the pointer and the properties would be
the LFB attributes. So it seems that if we could talk about the
properties of any given piece of information in the LFB structures would
be a useful generalization. And we could use the class that we put into
the data path in the protocol to indicate that we are talk about the
property instead of the data. But this implies that we are talking about
how do we define what the property information is for each object we can
have. We can define those as structures themselves. So there are
structures for the array properties and so force. That would allow us to
consistently talk about them. Joel thinks that we should add this
feature. But it is a major increase in complexity. That is why he is
reluctant in doing it. Joel asked the floor for comments. There are just
some nodding heads but no comments. Joel will post additional
information on the subject to the list.

- Events - Thins can happen at the FE that the CE needs to know of.
These are things that need to observed now and not a certain period
afterwards. So we need to have a mechanism for the FE to send up reports
or notifications to the CE called events. A different thing would be
from the CE to the FE. We have to define a number of things about the
events. For each LFB we have to somehow say what events can each LFB
generate and we have to create some mechanism for the FE to say I want
this event. But as the number of events is probably going to be large we
do not want to mandate that each FE shall consider all events and each
CE will be perceived by each event. So depending what the elements are
doing they may not be interested in all the events. It might be
reasonable to be able to subscribe to events. So we need a way to
subscribe to events. We also have to create IDs for the events. I
identified two ways of defining the events but there are probably more.
One way of doing it is for each structure definition, for each array
definition you could include in it the event definition with the
structure definition and then create the appropriate identifiers with
boolean pieces for the sign-up. At the LFB level you would have another
event declaration for the LFB level of events. This gives some
simplicity to it but that is also its draw back. It means that when I
have the same structure used in multiple places one needs to know at
creation already who is interested in what. So this method is probably
not feasible. The other alternative is to have in the LFB definition an
event section in which you define all the events of interest for that
LFB. But that means you have to reference all the top level things and
any structures that are buried in arrays. So the whole thing ends up
with a much more complex naming problem. Though it is much more powerful
    and more verbose. Which one to pick is currently not known. That is
why I brought it up for discussion. But it is clear we need to have the
events defined somehow.

Q: Is correlation of events and root cause analysis within scope?
A: What I believe is within scope is we have to define what is supported
    in the events whatever method we are going to use. I don't think that
correlation and root cause analysis is our problem but we should have
enough information such that is useful for the CE to find out what heck
to do with this. If for example an Ethernet switch is failing that is
certainly not a ForCES problem. It is however an important problem.

Q: Can I turn on and off all events or can I turn on and off some
events for a certain table?
A: We probably have to allow some of these things but I hope we will not
go overboard with this! This can become very complicated especially for
the FE. I hope we can keep this simple to implement. Scope sign-up's on
tables has not been put in yet but Jamal really would like to have it.
For example I would like to have a status update for every port up or
down on a certain table. And you do not need to sign up for every new
port for that particular event. Side comment, event history is not the
FE's job. This is definitely the CE's job.

Q: Are events reliable.
A: The ForCES protocol is reliable and so are the events. They run over
TML and this is for example TCP which is reliable.

There are 2 more changes to the model. One went in the other did not.
The model had text strings that had a fixed length. This was always
fixed. There were multiple places while I was doing the LFB FE object
where I needed a binary string which was up to a certain length but was
not always that length. So I added a type for that one. Strings are
defined as variable length but they have a length limit. In some places
we needed unlimited length. In some cases it was unclear whether we
needed a length or not and if yes how long it should be. And I think it
is not the model's job to say it must be length so and so. So we
probably need an unlimited length string in the model. And a property of
such a string would be how long it is.

Q: But unlimited length strings do have security problems.
A: No the security problem comes from buffer overflow. But in our case
the CE or FE has to make sure the the unlimited length string is not
going to exceed the size of the buffer. The security problem comes only
if you do a bad job of implementing this. We can define a max length and
maybe we should but I could not come up with a length limit that made
any sense. So folks may look at the FE LFB definition and see if they
can come up with a reasonable length limit for every place I had to put
in a length limit. Or we can go with an unlimited length string.

What was also added are derived classes to the model. How to implement
this is part of the XML debate.

Presentation 2: Shuchi Chawla
draft-khosravi-forces-tcptml-01.txt

I will go through the revisions that have been made to the draft since
the last meeting. I will start with a brief overview of the TCP/IP based
TML. Due to the ForCES requirements of reliability and flow control we
have picked TCP. By picking TCP the TML does not have to do any
additional things to meet those 2 requirements. Then ForCES also
requires that security should be addressed so we propose to use TLS for
security. As in the ForCES protocol the CE is the master and the FE is
the slave, the CE would be setup as the TLS server and the FE as the TLS
client. The TML draft allows for unicast, multicast and broadcast
addressing. Unicast is supported by using standard TCP/IP channels and
multicast would be simulated through multiple channels. Some more
details will follow later. The TML draft supports prioritization in TML
messages and it also prioritizes control messages over data messages. by
using different data and control channels. At the moment the TML draft
proposes a TML header to do encapsulation. This is currently under
discussion. The reason for it was to have additional signaling messages
for multicast support. So the goal is to investigate how to make things
as lean as possible. The support of high availability (HA) has not been
detailed yet what we have specified yet is that if the PL heart beat
does not continue we would use the TML heart beat. There are methods in
place to do fast switch over between the active and a standby FE or CE.
DoS attacks are mitigated by the separation of control and data
channels. When the data channels gets flooded with malicious traffic the
control channel still remains operational. In addition, the control
messages are prioritized over data packets.

It is only recommended to use two TCP connections between the CE and FE,
one for control the other for data. In case of a standby CE we would
have additional 2 TCP channels between the backup CE and the FE. In
terms of functions the CE is considered to be the server and the FE the
clients. So the CE is the one that is listing on predefined ports and
the FEs are going to connect to them. Channel shut down can be initiated
by both sides. There is a diagram in the slides that shows how the setup
/ tear down looks.

Q: Question on how the exact hand over between a failed active CE and a
backup CE would work. - lengthy discussion including what the hardware
can do or not -
Editors comment and summarization: There was mainly some confusion what
the exact definition of a backup CE is. Everything seemed to be clear by
assuming that the backup CE just listens to everything and maintains all
the states from the active CE without actively sending out messages.
That is one of the HA Models.  However, various HA models are possible
where the backup CE may not be completely passive or there might be load
sharing etc.  The final conclusion (with Joel adding the final comment)
was that the TML draft should not specify the HA Model or what can /
cannot occur over the channels to the backup CE(s). It is outside the
scope of TML.  All that the TML draft should specify is that control and
data channels must be established between the CE and FE, and in case of
a switchover from the active to the standby CE, the FE should be able to
communicate to the standby CE (or in other words, the new active) using
the TCP TML channels.

Unicast and multicast is supported over unicast links. The multicast is
simulated over multiple unicast channels. This required the introduction
of additional TML messages that are used for join and leave operation on
multicast connections. The message are then replicated according to the
FEs that are part of a certain multicast group. It is kind of the
traditional multicast with the root at the CE and the leaves at the FEs.
    So it is assumed that the FE is configured with multicast group
information.

Q: why do you do that. This model already has been significantly
modified in the SSM (Source Specific Multicast) model. In the ForCES
case it is sender driven, the sender knows what to send where. An FE
never knows what a particular CE wants to achieve. The sender knows
exactly what to send to whom. Avri is not so sure about that. Joel is
the opinion that we get a much simpler behavior if we do not try to
mimic multicast.
A: We were investigating 2 multicast models -- one which is FE
initiated/configured mimicking traditional multicast, and one which is
CE configured.  We picked the one which is FE initiated under the
assumption that since it mimics traditional multicast we wouldn't be
reinventing the multicast model.  But if the ForCES use of multicast is
expected to be slightly different from what occurs in traditional
multicast, we will revisit this.

The proposed multicast schema is currently under investigation to find
out whether it can me made leaner and simpler. The CE could for example
tell to the FE in which multicast group they are which means we do not
have to mimic join and leave messages. Another thing is that the same
channel is used for unicast and multicast. The group / channel
descriptor is going to distinguish if a message has to be sent to a
single FE or needs to be replicated for a multicast group including
multiple FEs.

The TML supports to carry PL control and data messages and if we cannot
do away with TML control messages also the TML control messages. In case
we have TML control messages then there would be a TML shim header in
order to support these messages. TML and PL control messages would be
exchanged on the same control channel. The exact definition of the
header can be found in the slides and the draft. A simplification of the
header would be very welcome. The draft contains also an interface to
the PL in the form of an API as a guideline of what functionality the
TML can provide to the PL layer.

Q: (Joel) a guideline is probably not sufficient. We need to mandate
exactly what the TML can provide to the PL. We also should not provide
this in the form of an API but rather in terms of a service interface.
This service interface should be generic to all TML. He does not care
whether the spec goes into one of the TML drafts or in the PL draft.
A: I agree. We started off with an API definition. We just needed to
start somewhere but we know we will have to evolve this into the exact
service interface that the TML will provide. This service interface
could also go into a separate draft.

Then the functionality of the current API proposal is presented (see the
foils). The services are:
    - tmlInit
    - tmlOpen
    - tmlClose
    - tmlWrite
    - tmlRead
    - tmlMulticastGroupJoin
    - tmlMulticastGroupLeave
In the current model tmlOpen and the last 2 are FE initiated.

Then the setup procedure is shown (see foils). Then the same thing is
shown for multicast support (see foils). The presentation is given
according to the currently proposed multicast model. If the multicast
model would be changed into a more CE driven model then the join and
leave messages would not be necessary anymore.

    - Open Issues - Broadcast has not been addressed so far. HA needs to
be  spelled out in much more detail. Message prioritization also needs
further details. Finally message encapsulation and multicast model needs
additional work. Shuchi concludes with a summary of the presentation.

Finally Shuchi asks to make this draft a WG document. The chair asked
the floor if there are any objections to make this draft a WG document.
There was no opposition. The chairs and ADs had discussed this before
and  there was also no objections. Therefore, the draft became a WG
document. But the chair raised again some points:
- data channel using TCP from the TML even if it is a raw or UDP
connection. Probably many routing protocol people will not at all like
this as they are taking care themselves of flow control and retransmit.
Also RDMA support should be thought of.
A; we are considering tunneling like GRE or DCCP to address the issue.

Comment from Joel: yes this should be a working group document but that
does not mean we take the draft as is. Joel is also the opinion that
DCCP might be a good alternative for the data channel. Take this draft
as good start and progress on it.

Chair comment: the service interface should either be a separate draft
or part of the PL. Important is that the service interface is generic to
the underlying TML as we want to have the option of swapping TMLs.

Q Avri: by making this a WG draft does it mean we are considering the
work on service interface and TML as WG issues. Can we split thing apart
later or not?
A chair: we basically have agreed on the list already that we need a
generic service interface usable for multiple TMLs. We also need a TML
to test different implementations against each other. Therefore, it
makes absolutely sense to embrace both topics by the WG. So in the end
we either have two WG documents or we attach the service interface to
the PL draft.

Joel is in support of adding it to the PL since there should only be
one service interface for all TMLs. He suggest to move a service
interface into the PL draft by the next meeting.

Presentation 3: Avri Doria
draft-forces-protocol-02.txt

Avri gave an update of the PL draft. It is the third version of the 
draft. The focus is on the progress that has been made since version 02.

An issue tracker has been setup and it is being used. Something still 
does not work with email responses going directly into the tracker. Avri 
will ask the tools folks about it.

There was extensive discussion among the authors and some folks on the 
list and also with the model team (especially with Joel) to bring the 
protocol together with the model. Last time we had 2 separate documents 
(model and the protocol) that went into 2 different directions. the 
documents are are still not in complete harmony but significant progress 
has been made due to Joel's help. In the mean time a number of tracker 
issues have been closed, more details below.

On the protocol BNF the PATH TLV is one of the bigger changes and one 
that impacts the whole PL draft. the presentation talks about 
Operations. In the document we talk about Type and not Operation. We are 
currently in the middle of a discussion on Types that are still called 
Operations. The operation type is really the T in the TLV and it needs 
to be expressed somehow properly in this BNF; sticking operation type in 
there is not the correct solution. Avri just wanted to bring it out on 
the slides because there still is an issue there.

Comment Joel: I am not really sure whether it belongs into the TLV in 
this BNF.

There is till a sort of inconsistency in the document when you read type 
we mean operation type. We have some language consistency to fix yet.

So there is PATH data TLV which includes a path and optionally data. The 
path is flags, IDs, and selectors (optionally). Selectors are basically 
the key info TLV that Joel was talking about. How it is used is not 
fully understood yet. We have reached consensus on all the notations and 
how it is being used.

Comment Joel: I think at the moment is is pretty clear how it is being 
used. But we do not know how to use it in an Addition.

Comment Avri: there is still some work to be done there.

Data can be DATARAW or it can be one more nested PATH Data TLV.
The RESULT TLV is still to be defined. There are a couple of 
implications of this. There can be one or more class LFB + instance 
targeted in a message. There can be one or more operations on an address 
LFB, class ID plus instance ID combo. There can be one or more path 
targets per operation. It is assumed that the type of data can be 
inferred by the context in which data is used. Hence, data will not 
include its type information. There is some inconsistency between type 
and operation. The basis for the inference is typically the LFB ID and 
the path. Among the open issues we are discussing the efficiency of 
encoding versus the efficiency of parsing and decoding and packaging 
overhead. For example do we include block data and if we do, how does it 
work. Or can we live without it? For the ones who have read the draft 
you see still a lot of questions and editors notes and TBDs. Updates to 
all the messages had to be made because of the PATH-DATA.

On the open issues.
Issue one on association setup / response has been closed. There were 
originally 2 messages that have been merged into a single one.

Issue 2 was mainly an editorial change to section 6.5.1.

Issue 3 consisted of modifying the query and query response message to 
include the PATH DATA with the limitation that when you do a GET 
operation the PATH-DATA does not require DATARAW-TLV or RESULT-TLV.

Issue 5 was about defining events in XML as attributes. This was made 
after discussions with the model team. So there will be a path that can 
be used by the config message for subscription. But there are a lot of 
open issues around this. So in the protocol we will use what comes up in 
the model.

Issue 7 was on how paths are described in the protocol messages to 
target a specific attribute or set of attributes. This caused a major 
revision to the draft.

Transactions: an important feature for transactions is the ACIDity which 
encompasses atomicity, consistency, isolation and Durability. There is 
still a lot of discussion going on on this.

Abort message for doing rollback and the format of the response messages 
is still not defined. We are trying to say enough about these things in 
the PL draft but not restricting the implementation.

Then Avri went through the example of a protocol message given in the 
slides where the structuring is illustrated. In the document there are 
several of these protocol visualizations depicted. Avri encouraged 
people to review them and report bugs and fixes.

On the XML for the FE protocol LFB, the definition has been started in 
Appendix C but no further details are being presented at the meeting. 
The working group is asked to review this Appendix carefully!

In Appendix D there are many examples and use cases given. The examples 
  show how the protocol is supposed to be used. Please read through them 
and make sure that they are clear. At the moment we are using in all the 
examples type as command.

As a next step to proceed with the draft all the TBDs, editor notes, and 
open issues note will be put in the tracker because we need to get them 
out of the document. Also some references need to be fixed. In addition, 
some consistency problems need to be fixed for example is it Type or 
Operation. We also need to decide if there are additional appendices 
required e.g. we definitely need one for types / commands. An IANA 
sections needs to be created.

What is not on the list is a manageability sections that needs to be 
created. This is necessary because there was a proposal made in the 
routing area by Avri and others that every document in the routing area 
should have a manageability section.  Avri, as an editor is supposed to 
add the section to the documents she is working on as part of a pilot.

Additionally, a scrub for nits will be necessary since there are still a 
bunch of them in. An important goal is certainly to get the document 
closer to WGLC (WG last call). In order to advance the document to LC we 
need many more people to read and comment on the document, so please 
read! Probably it will not the the next revision that will make it to 
WGLC. Another thing we will have to do because it is the routing area, 
will be to have somebody from the routing directory or one of the ADs 
assigned to the document so that when it comes to the time for last call 
we got everything covered in terms of implementations and reviews

Chair / AD Discussion
---------------------

After the meeting I had some discussions with the ADs. They are fine
with making the FE Topology Discovery draft and the TCP/IP base TML
draft WG documents. In addition, we discussed the TML draft, especially
the data channel. Both ADs were against enforcing the data channel to
use TCP for any kind of transport. UDP or RAW packet should not go over
TCP. TCP in TCP is super positioning 2 flow control methods which may
lead to some unpredictable behavior. The WG has to find something more
appropriate for it. Last but not least the ADs suggest to start with a
simple MIB for ForCES. Things that might be included are the FE topology
that can be discovered by the ansari draft. Other things of interest
might be if the adjacency between FE and CE is up or down. We will need
to identify information we want to export from ForCES. Most of this
information is probably helpful to the operator of the box.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 23 Mar 2005 11:57:46 -0800

Thanks Patrick for the very detailed notes!
 
regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Patrick Droz
Sent: Wednesday, March 23, 2005 12:43 AM
To: [email-masked]
Subject: [FORCES] ForCES Minutes, IETF 62 Minneapolis, USA

Agenda, IETF 62

AGENDA:

Minutes
-------

Attendees: 35

----------

----------

Changes in more depth:
    - FE schema changed into an LFB class definition using the same
schema
    - Alias -  There are situation and this can be debated for ever
where

    - Open Issues -

In more detail:

    in the events whatever method we are going to use. I don't think
that

Q: Are events reliable.

how it is being used.

On the open issues.

the model.

Chair / AD Discussion
---------------------