Preliminary minutes

Preliminary

Chair: Jamal Hadi Salim <[email protected]> 

1) Chair (10 minutes)
     *) Administrivia
     *) Blue Sheets
     *) Jabber & Minute scribes appointment
     *) Agenda bashing
     *)	WG Status

2) Joel M. Halpern <[email protected]> (15-20 minutes)
     ForCES Forwarding Element Model, Pre-requisite reading material:
     ftp://ftp.znyx.com/users/hadi/private/forces/draft-ietf-forces-model-09.txt

* Working on making things clearer with Jamal which resulted in
an updated model.

* Major changes to the way we talk about things:
  - LFBs used to have "elements" and "attributes" which are used in XML
  - Replaced "elements" and "attributes" with "component".
  - Made sure that all remaining "elements" and "attribute" referred to XML.
REQUEST: If there are some missed please say so

*Jamal has re-written Section 3 extensively Will be posting another 
version with the re-writes; right now working on Events section. 
Text was very awkward due to many changes

*IANA considerations
  Added FCFS space, "ext-"
QUESTION:  Do we need to register frame types, atttribute types?  
ANSWER: Not right now.

***** We are close to last call.  It is very close to done.

Jamal: we need a fresh pair of eyes to read it


3) Avri Doria <[email protected]> (10-15 minutes)
     ForCES Protocol Specification, Pre-requisite reading material at:
     http://www.ietf.org/internet-drafts/draft-ietf-forces-protocol-12.txt

There will be a -13 soon.
UPDATE: -13 has been posted ..

In -12:
* Replaced "element" to "component" but not "attribute".
Will be fixed in -13.
* Philosophical approach: strongly arguing for minimal change.
Current working draft available at 
http://psg.com/~abri/ietf/draft-ietf-forces-protocol-13-0.txt

* Figure4 changed, statemachine.
* Figure 43 statemachine goes from Pre-Assoication to
Associated, without a failover policy, goes back to
pre-association.  Teardown goes to not-associated.
Changes recognized when synchronizing model and protocol docs.

Think it's really close to ready.

4) Kentaro Ogawa <[email protected]> (15 minutes)
     SCTP based TML (Transport Mapping Layer) for ForCES protocol
     Pre-requisite reading material at:
     http://www.ietf.org/internet-drafts/draft-ietf-forces-sctptml-00.txt

* History: original version submitted by Jamal, June 2006.
Draft mentions rationale for SCTP based TML, accepted as WG item.
Discussions have been deferred, due to instability of protocol, model, etc.
Now these other items are almost done.
Now released as WG draft.

* SCTP vs. TCP, UDP, DCCP
TCP: SCTP uses messages, instead of byte stream.
UDP: SCTP doesn't provide multicast
DCCP: SCTP can do everything DCCP does.

* Additional services that none of the others provide
Multi-homing, runtime IP binding (ADDIP), a range of
reliability shades + congestion control...

* Why SCTP?
SCTP has all features to provide robust TML.  Very mature.
Provides High Availability with little effort.

Joel: 2 diff notions.
We have defined things that there should be multiple TMLs.
For interoperability we're going to have to pick one of them
as mandatory to implement.  I thought we had decided one.
Are you arguing that we should change from TCP mandatory
to SCTP?  That would be a big issue.
Ken: yes, that is what we are proposing.
Joel: don't like those debates.  Not the case that one is
better than another.  Think SCTP is A good choice.

* Meeting TML requirements
one socket 2 streams.
Reliability: yes
Congestion control: yes
Timeliness: Message can be discarded if not sent before timeout.
Prioritization: Multiple streams can be prioritized
PL Addressing to peers:  SCTP can replicate a packet to several destinations
  Not as good as UDP multicast, but saves local system memory b/w.
Encapsulation: None needed by this TML
HA (High Availability?): Multi-homing provides path diversity.
  If one of the peer IPs becomes unreachable, the others can take
  over without TML intervention.
  Reachability fault detection.
  Can migrate IP addresses from one node to the other

Discussion: Should SCTP be mandatory?

Joel: A number of problems with making this mandatory to implement TML.
Draft isn't really done.  Can't tell reading that draft how to use SCTP.
It's not done.  In order for AD to approve protocol, it must be able to run.
Changing horses right now would delay considerably getting this done.
Like TML, would like to see it finished.  Frankly, SCTP is not sufficiently
ubiquitous.  People know how to work with UDP and TCP a heck of a lot better.
In routers, making TCP and UDP work well for control operations has
been an interesting undertaking of many years.

Sue: it's not always done

Joel: Mandating that?

Jamal: there are a few other WGs who have mandated SCTP over TCP.
  Can't use UDP because of lack of congestion control.  TCP has
  issues/challenges: head of line blocking.  Ubiquity issue: it has
  improved because of other WGs who are forcing SCTP as the way to go.
  Our implementation uses TCP at the moment.

Joel: not saying you shouldn't be able to use SCTP, but for interoperability
we should make sure it's something that vendors will get right.  Document
needs to be in good shape, it might take too long.

Jamal: TML for TCP also needs work.

Avri: q: implementations that we have now, are they all TCP at the moment?
  Would they still count if SCTP was mandatory?  Are we back to no
  implementations?

Ross: Whether they count is in the eye of the AD who's voting.
  In the past, routing protocols had to have 2 interoperable implementations.
  OSPF, etc are fairly complicated.
  Talked with Bill Fenner and may relax this to a case-by-case basis.
  Bill wrote a draft that makes the other RFC obsolete.
  For very complicated protocols, it makes sense.  Forces is about
  as complicated, so would like to have 2 that work.  Can be interpreted
  that 2 implementations can be one control plane one bearer plane.
  Would be hard to argue that we have any implementations using SCTP.

Jamal: shouldnt be that hard.  Have no problem letting TCP be mandatory,
  but not in the form of the current TCP TML.  It is too complicated.

Ross: Other ADs might think differently.

Joel: If TCP TML isn't done, we need to finish it.  Whatever is
  mandatory must be documented.

SueHarris: With SCTP doc, one problem that has been occurring in
  other WGs, is interaction between 2 protocols.  If you are going
  forward with SCTP, need to iron those out.  Capwap did that,
  ended up re-writing a lot of drafts.  Look at state machine from
  capwap, state machine from BGP, make it work.  For the TCP piece,
  make sure these are cleaned up.  Failovers, what happens when
  keys fail, etc.

Jamal: thanks for the feedback

5) Evangelos Haleplidis <[email protected]> (15-20 minutes)
   Implementation experience

ece.upatras.gr
University of Patras
Department of Electrical and Computer Engineering
Along with 2 professors

What part was implemented
Overcoming some challenges
Questions

* Need
Flexnet: scalable, modular network architecture
His part was to create a WLAN AP with dynamic service deployment capability,
should be able to configure the forwarding path as well.
At the time, draft was at version -06.
LFBs:
FEProtocolLFB
FEObjectLFB
IncomingLFB
OutgoingLFB
ClassifierLFB

* Current project: Phosphorous
www.ist-phosphorous.eu
His part was to build token-based switch for traffic routing
and packet identification.  Code based on protocol draft -11.

*Current implementation has 1 CE and 1 FE.
FE contains mandatory LFB, Rx Tx LFBs
TML: TCP

Jamal: Is the FE a hardware-based?
Yes, based on Intel IXP.

*Protocol implemented:
  Association
  Heartbeats
  Set/Get

*CE
Basic CE functionality
Incorporates a web service for sending commands
Commands are processed in XML and translated into ForCES.

*FE
based on IXP enp2611 (no security) 2850 (with security)
TBS and IXP coding done by Mihai Cristea (science.uva.nl)
Token based switch

*TBS
FE can have 3 configurations, based on application type
  Entrance point of a packet: only TB
  Entrance point to an authorized network
  Internal change

*Rx model based on model draft.
TB model: 
TS model: has tuples to create tokens and compare them
Counters to count bad tokens, good tokens.
Event when bad token count exceeds a certain amount.
Tx Model:
Packet counter, needs to know which port it should send packets

*Development Challenges:
No hardware that is forces-compatible.  Had to build APIs to
  send messages to hardware.
Complex model components
Dynamic protocol messages, many LFB selects, many commands, operations
  Need a way to de-serialize message from wire to validate correctness and
  make use of it.
Protocol interface: web server.

*First implementation (-06) done in Java.
Pros: a little easier to code in Java.  No pointers.
Con: no system calls.

*Second implementation (-11) done in C++
Pros: have system calls
Con: pointers

*Modeled components based on inheritance.

*LFB component hierarchy:
  Component, Component_Byte, Compnent_Byte_Array
  Dense data and sparse data.

To create more complex, re-use Component_Array

*Protocol basic Messages

Basic_TLV .......... ILV.
Type, Length,        
data, list of
next TLV.

*Basic_TLV is superclass of LFBSelect_TLV

*Decided to have 1 CE that would control multiple FEs,
needed an API on which to issue commands.  Used web services.
Conceal ForCES model and protocol from programs.
Connections of multiple programs into one Forwarding Element.
Advertise API.

ForCEG Architecture (not fully implemented)

*Questions for the group
How will ForCES be used by higher layer apps & to alleviate network services?
What is relationship bewteen ForCES and netconf?  Similarities/differences.

*Joel: netconf is doing something conceptually very different.
Netconf assumes human being changing device over there.
Not what ForCES is doing.  In ForCES, the CE is the brains of the router.
Netconf notion is CLI.  ForCES allows CE to modify the details of an FE.
CE's can't be geniuses.  Would like to just say "here is a policy"
but it's going to take a lot to get that working.  CE is the brain,
but it's not the be-all and end-all of policy server.  For different
problems you would build different CEs.

*Sue: You are asking why these two are different.  From a research
perspective: Data flows are different.  Should look at work from
Network Processor Forum.  Look at different data flows.  IPv4 API or
IPv6 API of NPF.  There were things you could do intelligently
(split apart routes from next hops).  Network configuration follows
a different data flow.  You can look at it as a database or an
inline hierarchy.  Those data flows for netconf can be optimized.
If you need papers I have references.  Data flow doesn't work as
well.  HW devices differ.


6) Evangelos Haleplidis <[email protected]> (15 minutes)
   Demo (if there is time)

University of Amsterdam

3 things:

1. 2 FEs with Ids 4 & 8 will associate with CE upon bootup
   Demonstrate simple token-based Network Access control with
   in-band signaling.  Access to privileged and non-privileged
   domains.

Steve casner: rembrandt 2 and 3 have different IP addresses?
Jamal: he is demonstrating 2 different networks.
SC: both have same destination address?
    When you change policy in the router, destination would remain the same?
EV: just the demo


7)  Jamal Hadi Salim <[email protected]> (1-5 minutes)
   Wrap-up and  Adjourn

TCP vs. SCTP, will we talk about that online?
Joel: list is the place to do it.
Jamal: TCP has been sitting dormant for over a year
Joel: we've got to finish something, we've got to make something mandatory.

Avri: just submitted -13.