Subject: Tentative meeting minutes

From: Patrick Droz <[email-masked]>
Date: Tue, 10 Aug 2004 16:05:14 +0200

attached are the tentative meeting minutes. Please let me know
if you would like to have modifications / extensions to it.
Many thanks again to Steven Blake for taking minutes.

Regards,
Patrick
IETF-60 ForCES meeting minutes     02-Aug-2004, 13:00 - 15:00
---------------------------------------------------------------------------------

Chair: David Putzolu (absent),
          Patrick Droz 
         
Notetaker: Steve Blake (many thanks for the excellent notes!)

Attendees: ca. 40 persons in the room

Agenda:
10 min 	WG status & Agenda Bash - chairs
15 min	Alex Audu - draft-audu-forces-PL-00.txt - main design criteria
35 min	Avri Doria - Protocol Team Draft Submission
	draft: draft-doria-forces-protocol-01.txt
15 min	Hormuzd Khosravi - Analysis of Control, Data separation in ForCES 
	protocol for protection against DoS attacks
10 min	Lily Yang - ForCES Model Draft update & questions
	draft: draft-ietf-forces-model-03.txt
20 min	Steven Blake - Some Possible Extensions of the Current LFB Modeldraft: 
	draft-blake-forces-attrib-00.txt
15 min	Furquan Ansari - ForCES Element Bindings and Topology Discovery Protocol
	draft: draft-ansari-forces-discovery-00.txt

Presentations:

Alex Audu: draft-audu-forces-PL-00
This draft is an alternative to the outcome of the DT (see below).
- Discussed NE states
  - Joel: do you mean a collection of CEs and FEs?  Not sure an NE has state?
  - Alex: Yes, a collection.  Any device has a state.
  - Joel: Not necessarily.  No single physical device.
  - Alex: Need to know the state of the element.
  - Joel: I think I disagree.  Questions you want to ask: Is there a working
    CE?  Are there FEs associated with that CE that are working.
  - Alex: NE is defined as the collection.  How do the states of the
          individual components affect the state of the whole.
  - Joel: Redundancy is within the scope of the NE (?).  Not sure that the
          NE is a useful element to discuss with respect to the protocol.
- Discussed how CE/FE states can be used to compute NE state
  - Joel: this table assumes one CE, but we assume multiple.
  - Alex: table is misleading; mean to say that, for example, "CE State"
          refers to all CEs.
  - Joel: Long history of how to represent things in SNMP, etc.  Don't need
          to invent new nomenclature.
  - Alex: not intending to invent nomenclature.
  - Patrick: it is not clear that this is part of the charter
  - Joel: If none of your CEs are up, then there is no way to talk to the
          NE.  The NE state is only of concern in the context of network
	  management.
  - Alex: This needs to be defined in the context of ForCES.
- Discussed CE-FE state transition matrix
  - NE state basically tracks the states of the FEs
- Discussed Protocol Overview
- Discussed Message Design
  - Fully Coupled API (FCA)
  - Fully Decoupled API (FDA) (preferred)
- Discussed ACKs
- Discussed Message Structure
- Discussed Layers
  - If transport is IP, don't need a TML
  - Joel: do you want to reinvent everything in transport protocols in the PL?
          Your statement doesn't follow.
  - Alex: Main reason for TML is to adapt PL to non-IP transports.  TML is
          a transport mapping layer.
  - Joel: You need more than just IP as a transport.

Avri Doria: draft-doria-forces-protocol-01
http://psg.com/~avri/forces/forces-ietf60-fpteam.pdf

This draft is the outcome of the DT that was chartered to come forward
with a merged ForCES protocol based on the input of the 3 competing
protocol proposals

- Discussed layers, pre-association phase, post-association phase
- Discussed PL/TML separation
  - Alex: Making the TML too heavy.  Example: security.
  - Avri: How much of this do you want to handle in the PL?
  - Alex: How do you cope with different TMLs on the CE and FE.
  - Jamal: No point in reinventing the wheel.  Nothing being reinvented.
- Discussed message header:
  - Joel: What are you attempting to accomplish with the version field.
          Differentiating major/minor is not helpful.  CEs and FEs may support
	  and advertise a range of supported versions.  Encoding specific
	  feature support in a "minor" version will not work out.
  - Jamal: Joel has a point.  This was brought out in the interop test.
  - Avri:  Ok
- Discussed Messages
  - Alex: Draft suggests State Maintenance Messages may not be necessary down
          the road.  Believes that state maintenance is demphasized.
  - Avri: Probably agree with you.
  - Alex: Draft should address the issue of state.  Need a state machine.
  - Jamal: State machine will come.  Have an FE Object and FE Protocol Object
           which may conflict with the State Maintenance messages.
- Discussed FE Protocol Object
- FE Object: not sure what is maps to in the model
  - Joel: The things you capture here are what we tried to capture in the
          model.  We will create two LFBs that always must exist, allowing
	  us to use the same protocol messages to manage FE attributes.
- Discussed Scalability Factors
- Discussed HA (specifically CE-CE failover)
  - ?: Not concerned with FE redundancy
  - Avri: Don't understand yet what we want for FE redundancy.  Haven't
          talked about it yet.
  - Jamal: We agree.  Don't know what to put in the header to facilitate
           this.  Suggestions welcome.
- Discussed Security
- Discussed To-Do items
- Request that draft-doria-forces-protocol-01.txt become a WG draft.
  - Hums indicate rough consensus for approving it as a WG draft
  - Alex: Comment on the draft.  Complexity makes me nervous.  Still
          lots of holes.  There is an alternative (my draft).  Don't see
	  a resemblance to what previously existed.
  - Patrick: WG previously agreed to a merge.  Wasn't sure it was possible,
             but is was.  Not done yet.
  - Joel: Accepting this as a WG document doesn't mean that it is done.  It
          is a good basis for further progress.  Expect that the final doc
	  will have major changes from this one.
- Announcement: Three preliminary implementations have interoperated to
                form a FE cluster.  Future interop tests planned.
We checked for rouph consensus to make this document a WG document. 
There was no hum against this. 

Lily Yang: Analysis of Control, Data separation in ForCES protocol for
           protection against DoS attacks.
Authors: Hormuzd Khosravi, Shashidhar Lakkavalli
- Discussed Requirements
- Discussed experimental setup
- Discussed experimental results
  - Jamal: where does the prioritization happen?
  - Lily: think it at the pthread level
  - Jamal: not at the Ethernet level?
- References: http://www.sstanamera.com/~forces/Ietf59/testbed_dong.pdf
  - Joel: have they tried the experiment with TCP for control, DCCP for
          data?  Don't want retransmission for data.
  - Lily: tried, but the DCCP implementation is buggy
  - Steve: Shouldn't these connections be separate anyway because
           the endpoints are in separate address spaces?

Lily Yang: draft-ietf-forces-model-03
- Discussed changes
- Discussed output groups
  - Jamal: Need a formal definition of what distinquishes ports in port
           groups.  I'm confused.
  - Joel: Input side is different from the output side.  Example Scheduler;
          need to know which one the packet came from.  Different LFBs
	  can do output port selection based on different criteria.  The
	  LFB class definition has to be very specific as to how this
	  selection happens.
- Discussed To-Do items
  - Jamal: Do you think there will only be one LFB class definition document?
  - Joel: One core library document with XML for each included LFB class
  - Patrick: Take off-line please.
The intention is to go for a last revision of this document and then shoot
for last call. 

Steven Blake: draft-blake-forces-attrib-00

- Discussed Bundled Configuration, Attribute Sharing, and Inter-LFB control
  problems not currently solved by the Model schema:
  - Joel: Can handle Inter-LFB Control problem with special control paths
          (metadata only) in the topology
  - Jamal: Can handle LPM case by having two LPM LFB instances with flags
           that show that they share attributes.
  - Steve: Needed mechanisms not in the schema yet.

Furquan Ansari: draft-ansari-forces-discovery-00
  - Joel: If you separate the bindings from the topology discovery, then
          couldn't we use something like BFD to do this topology discovery.
  	  Then we don't have to invent another protocol.
  - Furquan: Discussing BFD with extensions
  - Jamal: <missed comment>
  - Alex: Don't want a fat protocol (e.g., BFD)
  - Joel: BFD isn't fat!
  - Jamal: Do we really need this?
  - Joel: CE could configure FE to send all unrecognized packets to the CE.
          CE could receive OSPF Hellos; don't necessarily need a new protocol.
    	  Need to be very clear about what problem we are solving.
  - Joel: The CE needs to be able to discover the topology.  That does not
          mean that we need a CE discovery protocol.  What is the 
  	  interoperability we are achieving here.  There might be a BFD LFB.
	  Spell out more clearly what the value-add is.
- Discussed Discovery protocol
- Discussed Inter-FE Topology Discovery and Maintenance
  - ??: What is the neighbor ID?
  - Furquan: Neighbor ID is FE ID.
  - ??: <couldn't follow comment>
  - Furquan: If you are using IP, then you can get the MAC address.
  - Patrick: Please take offline.
- Conclusion: need to add inter-FE topology discovery and inter-FE topology
              maintenance to the charter.
  - Patrick: Need to discuss with co-chair (David)
  - ??: <couldn't follow comment>  In case of SONET, could be multiple
        IP addresses.
  - Furquan: IP address is not the equivalent of a router ID.
  - Jamal: Demo after this.
  - Patrick: Jamal will show the demo.  Meeting adjourned.