Re: ForCES Minutes

[Weiming Wang <[e-mail]>]

Hi All,

I have noticed that notion of "meta-data" related to FE model has attracted many attentions in ForCES WG recently. I have come upon a simple idea called "PacketFlowId", upon which we may avoid using tought "meta-data"s when constructing FE building blocks, at least in terms of the meta-data role for IP packet walking in between FE blocks. Actually I have included this idea in a paper submitted to SCI2003 this April, so I attached this paper here. Please just forgive my poor english if you read it. And work is still going on, so please also forgive the immature for some of ideas inside. Comments and questions are definitely welcomed.

Best regards,

Weiming Wang


----- Original Message ----- 
From: "Patrick Droz" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, July 23, 2003 9:07 PM
Subject: ForCES Minutes


> attached are the tentative minutes from the meeting in
> Vienna. If somebody wants to have something changed please
> let me know. I plan to send them to the official minutes-
> list at the end of the Week. Many thanks also to the minutes
> taker Jason Goldschmidt.
> 
> Regards,
> Patrick
> 
> ------------------------------- cut here --------------
> 
> ForCES Minutes, IETF 57th, Monday 07/14/03
> 
> Attendees: about 50
> 
> WG status:
> 
> The Requirements and the Framework documents should become
> RFCs soon. They are currently under AD/IESG review.
> 
> AGENDA:
> 
> 5  min - WG status - chairs
> 
> 15 min - ForCES Framework respond to IESG feedback - Ram Gopal
> 
> http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-06.txt
> 
> 20 min - ForwArding and Control ElemenT protocol (FACT) - Hormuzd
> Khosravi
>           Individual contribution protocol proposal.
> 
> http://www.ietf.org/internet-drafts/draft-gopal-forces-fact-04.txt
> 
> 20 min   Netlink2 as ForCES Protocol - Robert Haas
>           Individual contribution protocol proposal.
> 
> http://www.ietf.org/internet-drafts/draft-jhsrha-forces-netlink2-01.txt
> 
> 15 min - ForCES Forwarding Element Functional Model - Joel Halpern
>           Individual contribution model proposal.
> 
> http://www.ietf.org/internet-drafts/draft-yang-forces-model-02.txt
> 
>           *** NOTE: Authors intend to ask to make the above a WG
> document. ***
>           *** Please read and review prior to meeting or comment on list!
> ***
> 
> 15 min - XML/TIPC based ForCES protocol and
>           ForCES Pre-association Phase Protocol - Jon Maloy
> 
> http://www.ietf.org/internet-drafts/draft-nait-forces-xml-model-00.txt
> 
> http://www.ietf.org/internet-drafts/draft-nait-forces-pap-00.txt
> 
> 15 min - ForCES FE Functional Model Elements - Zsolt Haraszti
>           Individual contribution model proposal.
>           Late contribution - available at:
> 
> http://www.petri-meat.com/slblake/networking/drafts/draft-haraszti-force
> s-model-00.txt
> 
> 15 min - Demonstration of working prototype of XML/TIPC
>           for ForCES - Jon Maloy
> 
> Drafts:
> 
> Minutes:
> 
> 
> Reached consensus that protocol selection will be attempted on the 
> mailing list in a month.
> 
> Comments on selection process, Joel Halpern spoke to first
> determining if the protocols are doing what we want. He thought
> it is obvious that they meet the requirements. Jason Goldschmidt
> asked if only post-association will be considered.
> Answer was yes. Comment was made that protocols should ONLY focus
> on post-association. Comment was made that documents should be
> sure to use a consistent language, set by the framework and requirements.
> 
> 
> Framework Presentation (Ram Gopal)
> 
> Update 05 and 06 made changes to address FE virtualization.
> FE partitioning is done during the pre-association phase.
> Comments were made about multiple FE managers, these comments
> were not accepted. Next draft may address offloading concern
> raised by IESG. Text added to support graceful restart,
> non-stop forwarding and dynamic association establishment.
> New section added to better detail of FE loss/restablishment,
> caching and session reestablishment.
> 
> The new draft adds text to discuss security threat; see
> security considerations of draft for more info. Security
> options for FORCES are as follows: No security, TLS,
> IPSec. New draft incorporates security handshake during
> association establishment.
> 
> No comments/questions on framework.
> 
> 
> FACT (Hormuzd Khosravi)
> 
> Protocol updates. Now compliant with requirements draft 9.
> 
> New draft adds definitions for separate control and data
> channels. Protocol Elements (PE) will be sent over data
> channel, all other FACT messages over the control channel.
> This was done to prevent against DoS attacks that would
> saturate the channel between FE and CE. Same reliable
> transport used for both data and control channel. This
> requirement is driven by the need for congestion control;
> though this is not called out in the FORCES requirements
> document.
> 
> FACT uses reliable transport to meet requirements. TCP/SCTP is 
> recommended. This simplifies the protocol design.
> 
> Security rewritten. 3 modes, no sec., IPSec, TLS. TLS is
> recommended.
> 
> Comments:
> 
> Joel: we need a mandatory to implement core of protocols
> for transport and security. David Putzolu: pick one and go
> with it.
> 
> Description of CE failover and difference between weak and strong
> consistency. Strong, FE communicates with both. In weak,
> CE's sync.
> 
> Question/comments
> 
> Zsolt Haraszti: problem with separation between data and
> control channel. For example asynch exception will happen
> over control. What if asynch exception requires sending
> the packet to the CE?
> 
> Joel: the kind of events that go over the control channel
> is regarded about the FE itself. The data channel handles
> info about packet related events.
> 
> Robert Haas: is the priority bits not enough to distinguish
> between the two.
> 
> Joel: Data channel should not be reliable.
> 
> Xiaoming Fu, How does CE-CE work.
> 
> Hormuzd: This is out of scope given the FORCES charter.
> 
> Ram Gopal: FACT can be used for CE-CE.
> 
> David: Framework points out the channel and explains why
> these other connections are out of scope.
> 
> Xiaoming Fu: Maybe next step in signaling WG and FORCES
> can work together.
> 
> 
> Netlink 2 – Robert Haas.
> 
> Summary of changes.
> 
> Joel: is it your assumption that FORCES is used for FE-FE
> or LFB-LFB communication. Comments to clarifying that
> netlink2 is not for LFB-LFB communication.
> 
> Netlink2 in a nutshell.
> 
> Uses groups and multicast to allow for scaling. The Goal is
> flexible CE-FE addressing. Netlink2 is making use of groups.
> Then some addressing examples were given.
> 
> Conclusion. Netlink2 addresses scalability whereas FACT focuses
> more on CE failover and availability.
> 
> Joel: scalability addressed by MC, this concerns him. IS there
> a need to send the same messages to the different FE's? How
> common is this today since FE's are not the same. Ie different
> routes, ports, yadda yadda. It doesn't seem obvious that there
> is a value add in sending same information to all or a set of
> FE's.
> 
> Patrick: if multiple FE of the same box they must have the same
> info for certain things a good example is the forwarding info
> generated by the routing protocols.
> 
> 
> 
> FE Model - Joel Halpern
> 
> State of document. Most of sections are there. Not all filled out.
> 
> Fine grained FE blocks. Does not want to talk about large scale blocks,
> like a DiffServ block. How to represent an IP Forwarding block (this is
> why there needs to be an affinity between NPF and FORCES).
> 
> FE block description. Formal description of a block is needed.
> 
> Classifier.
> 
> How to build a classifier? Two classifiers, one that modifies the 
> meta-data, other that has multiple exits. Compromise.
> 
> Meta-data. Where and how to use meta-data? FORCES model that can do 
> useful things, before meta-data definition is answered. Group need to 
> resolve how to tackle this.
> 
> Representation. Is representation for documents same as an on the
> wire. Team recommends XML Schema. Not DTDs
> 
> Thinks document is consistent with the framework and possibly group. 
> Should document be made a WG doc?
> 
> Comment. Classifiers without metadata seems like science fiction.
> 
> Joel: having a forwarded that does such is more uncommon.
> 
> Jason: why not classifier plus mux?
> 
> Joel reiterates the need for meta-data definition.
> 
> David: Should this document be accepted as WG document? Hums?
> The Favors have it. Still need to check with mailing list.
> 
> 
> Pre-association protocol - Jon Maloy
> 
> FE/CE manager accepts/rejects new PE's.
> 
> Why do we need this?
> 
> Need for dynamically changes NE's.
> 
> Protocol discussion.
> 
> 
> Robert: Could we use SLP instead of discovery phase proposed
> for CE-CE Manager protocol?
> 
> 
> Demo
> 
> Joel: we should focus on our chartered work, not out of scope work.
> 
> 
> FE Model elements (Zsolt Haraszti)
> 
> not alternative model.
> 
> Topo versus encoded.
> 
> a mixture is needed to deal with the problems related to each.
> 
> 
> -- 
>    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]
> 
>