Subject: RE: [manet] DYMO-04 Comment Solicitation

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 04 Apr 2006 15:30:47 +0100

Ruffino Simone [mailto:[email-masked]] wrote

> 1. What is exactly the motivation for the packet header? Reading the
> draft it seems to me that the most important functionalities (i.e.
> duplicate suppression and scope-delimited forwarding) are achieved
using
> the msg-seq-number field in the message header (msg-header field). Is
it
> intended as a replacement for DPD header option for use with SMF ?

The initial motivation for the packet header was OLSRv1. If you look in
RFC 3626 you'll see its use for link quality purposes using the packet
sequence number - and no, you can't achieve that effect using message
sequence number.

On top of that, there is a suggestion to add (like the packet header
with zero overhead if not used) an optional packet TLV block to the
packet header. This would allow the transfer of any sort of hop by hop
information, for example if you want a hop by hop packet signature.
(Message TLVs are convenient for end to end signatures, as other people
want. We should cater for both.)

The key point is it's a generic format, not everyone is going to want
everything, but if someone does, and it has a zero or minimal impact
on those who don't, then it's a candidate for inclusion. (Of course
not all candidates make it, we - for all values of we - have finite
time and effort of course.)

> 2. regarding address representation in compact form: I think it
provides
> for a good flexibility and it is especially effective if used with
many
> v6 addresses. However, I was wondering if, in case addresses are only
> network prefixes, more compact representations are possible: this
would
> be important for AUTOCONF, I think. Have you maybe tried with some
other
> way to represent prefixes ?

This is something I have thought about - even my co-authors don't
actually
know that, as I haven't yet come up with a good suggestion to include.
Obvious solution is to include two lengths in each address block, but
this
adds overhead to every address block, which is not a winner, unless you
do
some playing around with flags and other stuff - and we also have people
who, for good reasons, want minimal complexity and are against such
additions.
So at the moment I haven't come up with anything good here. (Note that
we
have introduced complexity before - TLV semantics is one case - but that
also had a simplification aspect as well as a complication aspect.)

> 3. I was wondering what other use can CONTENT-SEQ-NUMBER have, besides
> fragmentation. I'm asking this 'cause it could be easily treated as an
> additional field in the FRAGMENTATION TLV, since they MUST be present
> both when message is fragmented.

OLSRv2 TC message ANSN. (As an example.)

The content sequence number does however need a tweak, it needs to be
(always or optionally not firmed up yet) message type dependent.

> 4. Sec 5.2, three lines above sec 5.2.1: I think there is a typo. ",
if
> bit 4 in the msg-semantics" should be ", if bit 2".

Thank you, I've added it (with your name) to the bugtracker we (Thomas
actually) maintains.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 04 Apr 2006 16:39:55 +0100

provides
many
would
other

actually
this
> adds overhead to every address block, which is not a winner, unless
you do
additions.
we
> also had a simplification aspect as well as a complication aspect.)

A detail I forgot to mention, just in case anyone missed it, I'm
talking here about more efficient representation of prefixed addresses.
Prefixes can already be represented, with a prefix TLV, which I'm not
suggesting changing (if all addresses in a block are /64s, the actual
prefix costs a single 4 octet TLV). The inefficiency is each address
has 8 octets of zeros that the prefixed address doesn't actually need.