Table of Content

[hgn]

General structure of the document:

• Intro ...
• ...

[reisub-de]

v1

• Introduction
  • Terminology
  • Overview
• Message Format
  • Types ( = partial, full)
  • Header ( = binary header)
  • Fields ( = paths, networks, link attributes etc)
  • Full
  • Partial
  • Requests
  • Reflections
• Behavior
  • Neighbor detection
  • message handling (=hold time, etc)
  • policies
  • route selection
  • network retraction
• Optional Features
  • Asymmetric Neighbor detection

[hgn]

This means that the message types are fully described first, correct?

What about:

• https://www.ietf.org/rfc/rfc2328.txt
• https://tools.ietf.org/html/rfc1247
• https://www.ietf.org/rfc/rfc3626.txt
• https://tools.ietf.org/html/rfc7181

What I miss is the "glue" text in the beginning, the "why", the background. I need at least a slightly larger introduction to understand the protocol before digging into the details as "message format". Like in OLSRv2: "Protocol Overview and Functioning"

[hgn]

OLSR v2 has also a appendix:

" Appendix C. Example Algorithm for Calculating the Routing Set"

this can be written in an equal way for calculating the loss based metric. Just an idea.

We should also add a section where DMPR differs from BGP,OSPF,OLSR.

[reisub-de]

This means that the message types are fully described first, correct?

hmm, behavior would indeed suite better before message format

What I miss is the "glue" text in the beginning, the "why", the background.

This would be in the introduction, I will give that an extra point in the new version

OLSR v2 has also a appendix:
" Appendix C. Example Algorithm for Calculating the Routing Set"
this can be written in an equal way for calculating the loss based metric. Just an idea.

I added an Appendix with different policy examples

[reisub-de]

v2

• Introduction
  • Why
  • Terminology
  • Overview
  • distinction from other routing protocols
• Behavior
  • Neighbor detection
  • message handling (=hold time, etc)
  • policies
  • route selection
  • network retraction
• Message Format
  • Types ( = partial, full)
  • Header ( = binary header)
  • Fields ( = paths, networks, link attributes etc)
  • Full
  • Partial
  • Requests
  • Reflections
• Optional Features
  • Asymmetric Neighbor detection
• Appendix
  • Policies
    • low loss policy
    • high bandwidth policy

[hgn]

Ok, I think we can go with this into first revision in the xml.