Re: D105 design draft issue: figure 3

I still think that the figure should be changed
(e.g. there's no routing protocols in a host).
But perhaps its better if I try to send you alternative
text (or picture in this case).

--Jari

Tero Kivinen wrote:

>[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... :-)
>  
>