Subject: tentative minutes

From: Patrick Droz <[email-masked]>
Date: Thu, 4 Dec 2003 11:56:23 +0100

Attached are the tentative minutes from the ForCES meeting at
the IETF 58 in Minneapolis. Please send me corrections or
extensions. I would like to send the official minutes in during
next week.

Thanks to the minutes takers Sue, Lilly, Hormuzd, and Robert.

Regards,
Patrick
-- 
   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
58th IETF ForCES WG Meeting Minutes

Monday, November 10 2003 at 1300-1500
=====================================

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

AGENDA:

5  min - WG status - chairs

10 min - A proposed vocabulary and conceptual model for 
         discussing metadata within ForCES - Alan DeKok
         http://www.ietf.org/internet-drafts/draft-dekok-forces-metadata-00.txt

25 min - ForCES Model Update - Steven Blake
         http://www.ietf.org/internet-drafts/draft-ietf-forces-model-01.txt

5 min - Topology representation for ForCES FE model - Weiming Wang
         http://www.ietf.org/internet-drafts/draft-wang-forces-model-topology-00.txt

20 min - General Router Management Protocol (GRMP) Version 1 - Weiming Wang
         http://www.ietf.org/internet-drafts/draft-wang-forces-grmp-00.txt

20 min - Netlink2 protocol - Steven Blake
         http://www.ietf.org/internet-drafts/draft-jhsrha-forces-netlink2-01.txt

20 min - Status update for FACT protocol - Ram Gopal
         http://www.ietf.org/internet-drafts/draft-gopal-forces-fact-05.txt

15 min - Linux traffic control extensions & the forces model - Jamal Hadi Salim
         (no draft available)

Minutes

1) ForCES WG status update on major WG drafts
Requirements: waiting for RFC #
framework: seurity comments from IESG on authorization needs to 
be incorporated. 
Model: more work needs to be done but good progress.

2) Alan DeKok: A discussion of Metadata in ForCES

A proposed vocabulary and conceptual model for discussing metadata 
within ForCES. It is "data about data".
Meta data: Implicit - inside chip, explicit - outside chip

Jason: Why is it important?
Alan: this is important to the definition of the model 
LFB topology between FEs. Vendors may have internal
communication within a chip. This communication is out
the scope of the forces communication.

Robert Hass: explicit internal metadata for forcES, right?
Alan: depends on implementation. 

Joel: explicit and LFB-external metadata for ForCES.
Alan: Yes. if multiple LFBs inside one chip, the actual implementation 
of metadata between LFBs are not the same as how ForCES defines the 
metadata. We need to recognize that.

3) Steve Blake: on model v01
Changes since v00: merged with Zsolt and Steve's contribution, added 
as co-authors, significant re-organized
Directions taken:
distinguish between FE model and LFB model. Allow packet datapath to 
be represented using both topological and encoded state. Allow LFBS 
multiple in/out and group in/out concept

List of open issues:

Inter-FE topology - the protocol should be capable of querying this 
from the FE, but the question is whether it belongs to the protocol
or the model.

ForCES protocol parameters (in scope)
possibly inscope: implicit metadata for LFB topology validation & 
debugging. Do we really need to model pass-thru mode for metadata?

Multiple Inputs/outputs & input/output groups. Output group can be 
used as embedded redirector within an LFB Mux and redirector.

Dynamic LFB topology reconfig is good for enabling support for new 
protocols? Example: turn on L2TP support. Configuring QoS reservation 
for a new RSVP flow does not necessary require a topology reconfig.
Would the FE stop forwarding while reconfiguring the topology?

Joel: code downloading is out of scope for now. But should allow 
extension later. David: Shouldn't the CE know whether or not the FE 
stops forwarding when reconfiguring?
Joel: want to avoid explict "stop, reconfig, start". It is best to 
have transparent operation.
Jamal: It is feasible.

LFB class partitioning: finer grain or coarse grain? We need to 
come up with the right balance. 

Modeling port LFBs input and output: split or combined?
similar problem: ip interface, encap/decap

modeling lookaside LFBs: devices that receive part of a packet and 
produce metadata but otherwise are not in the direct datapath
modeled as "tap LFB + lookaside LFB" ?

Modeling queueing and scheduling LFBs. Schedulers pull packets from 
queues. Model does not model timing.

Modeling classification - classification LFBs. Protocol-specific LFBs 
look at appropriate fields within the packets, but not embedded 
classifiers.

Jason: what about content inspection for classifiers?

Upcoming work items for -02: work on Sections 4-8

Steven solicitated feedback on the draft. 

4) Weiming Wang: GRMP proposal
Deveopled separately from GSMP but considers compatibility
Messages to do FE, LFB, and datapath management. 

Reliability consideration: use GSMP built-in error mechanism.
Uses IPsec/TLS for security. Mor work has to be done to cover
mor medium

Operating objects in GRMP:
object types + object class = object ID

FE attributes/capabilities/events
GRMP defined/Model defined/vendor defined

DoS protection Scheduling & DoS Attack Alert Policy

Joel:  What you have here is interesting. But why in the protocol? 
Why not using LFB instead?
Lily: sounds like there is chicken and egg problem here. 
Weiming -- the GRMP slave module needs to be up before the ForCES 
protocol can be used.

5) Weiming Wang: On Topology representation (PkfID)
A name assigned to a single connection or a group of connection, 
conceptually like virtual buffer

Joel -- there are no buffers, don't know what you mean here. I am 
really sorry.

6) Steve Blake: on Netlink2

- changed TLV encapsulation to permit multiple TLVs in the same 
Netlink2 message.
- provided state transition diagrams for FE-CE protocol association
- added LFB definition derived from Netlink RFC 3549: Interface 
Service, Address Service, IPv4/v6 Forwarding, Neighbor Discovery.
- extended security measures for local scope and global scope 
environment: protection against DoS with policer LFB for data traffic 
redirected to CE. Netlink2 SYN cookie TLV to protect against Netlink2 
SYN flood attacks.
- use of qualified names for FEs and CEs to perform authentication.

Netlink2 and ForCES requirements:
- solves one of the scalability requirements by supporting multicast 
wires (ForCES-level group addressing): routing table updates can be 
multicast from CE to all FEs.
- Netlink2 can be layered directly on top of link layers (Ethernet, 
Infiniband, etc)
- all of the other requirements are met.

Netlink2 reference code:
- announcement will be made on the list within the next month
- open source
- demo of one CE updating route tables of two FEs using Netlink2 
group addressing over IP multicast. 

6) Ram Gopal: on FACT protocol
TCP used for control channel, DCCP for data channel and TLS for security.
There is a rate limiting mechanisms on FE

Jamal : what is the point of priority?
Ram: gave an example.

Explicit ACK/response msgs
Interconnect independence:
CE tag, FE Id for interconnect independent addressing
CE redunancy or Failover (heartbeat)

7) Jamal: Linux Traffic control extension and ForCES model
High level view of an FE

8) There was a demo given of running Netlink2 code.

---

From: Alex Audu <[email-masked]>
Date: Tue, 9 Dec 2003 12:31:17 -0600

Patrick Droz wrote:

>   ------------------------------------------------------------------------