Re: tentative minutes

[Alex Audu <[e-mail]>]

Patrick Droz wrote:

> 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                     | [e-mail]
>    IBM Zurich Research Laboratory       | http://www.zurich.ibm.com/~dro
>    Saumerstrasse 4                      | Tel. [phone] CH-8803
>    Rueschlikon/Switzerland              | Fax. [phone]
>
>   ------------------------------------------------------------------------
> 58th IETF ForCES WG Meeting Minutes
>
> Monday, November 10 2003 at 1300-1500
> =====================================
>
> CHAIRS:   David Putzolu <[e-mail]>
>           Patrick Droz <[e-mail]>
>
> 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.