D105 design draft issue: figure 3

[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html
 working copy of document:
 http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt]

Jari Arkko writes:
> >                            +-------------+       +---------+
> >                            |User-space   |       | MOBIKE  |
> >                            |Protocols    |  +-->>| Daemon  |
> >                            |relevant for |  |    |         |
> >                            |MOBIKE       |  |    +---------+
> >                            +-------------+  |         ^
> >    User Space                    ^          |         ^
> >    ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++
> >    Kernel Space                  v          |         v
> >                                _______      |         v
> >        +-------------+        /       \     |    +--------------+
> >        |Routing      |       / Trigger \    |    | IPsec        |
> >        |Protocols    |<<-->>|  Database |<<-+  +>+ Engine       |
> >        |             |       \         /       | | (+Databases) |
> >        +-----+---+---+        \_______/        | +------+-------+
> >              ^   ^               ^             |        ^
> >              |   +---------------+-------------+--------+-----+
> >              |                   v             |        |     |
> >              |             +-------------+     |        |     |
> >       I      |             |Kernel-space |     |        |     |   I
> >       n      |   +-------->+Protocols    +<----+-----+  |     |   n
> >       t      v   v         |relevant for |     |     v  v     v   t
> >       e +----+---+-+       |MOBIKE       |     |   +-+--+-----+-+ e
> >       r |  Input   |       +-------------+     |   | Outgoing   | r
> >       f |  Packet  +<--------------------------+   | Interface  | f
> >     ==a>|Processing|===============================| Processing |=a>
> >       c |          |                               |            | c
> >       e +----------+                               +------------+ e
> >       s                                                           s
> >               ===> = IP packets arriving/leaving a MOBIKE node
> >               <->  = control and configuration operations
> >
> >    Figure 3: Framework
> 
> 
> I am confused by the role of the "Kernel-space protocols
> relevant for MOBIKE" box in this figure. There are parts
> of a node implementation that have to deal with IPsec
> processing; is this what you mean? And there are parts
> of a node implementation that may provide information
> to, e.g., MOBIKE and MOBILE IP -- such as IPv6 NUD or
> DNA. Is this what you mean?

I think both, i.e. both the IPsec processing things, i.e. for example
detecting IPsec packets coming from wrong address, etc, and also other
protocols like you list there.

There is quite limited space for drawing pictures in ascii, so it is
better to cluster things a bit more and describe the actual modules
needed, and not try to duplicate each box from the Pasi's slide.

> I think the latter is an important
> part that should be shown, but such components would appear
> to provide input to the MOBIKE daemon directly or via
> a "trigger database" rather than effect input and output
> processing directly.

The kernel-space protocols has arrows to trigger database, and to the
input / output processing. 

> What are "User-space Protocols Relevant for MOBIKE"?
> I can't think of any...

DHCP, perhaps PPP etc. 

> Also, I'd rather not see "routing protocols" in this
> figure, as it will confuse people.

Routing do affect the selection of the addresses and interfaces, so I
think it needs to be shown here. 

> And while a trigger database is a good idea, I'd rather not
> introduce it here. It would be better to have a simplified ascii
> version of the slide from IETF-62:

I think having trigger database there actually do simplify the picture
quite a lot, and that's why I think it is good idea to keep it there. 

> http://www3.ietf.org/proceedings/05mar/slides/mobike-1/sld6.htm

Simplifying that picture does not really help, as the main idea for
that picture was to so complicated enough picture having all kind of
boxes and arrows, so that everybody would understand that this MOBIKE
is only very small part of the whole solution.

Simplification of a very complicated picture which is complicated on
purpose (actually complicated to make sure it obfuscates things)
doesn't really help... :-)
-- 
[email protected]