[Manet-dt] Comments on draft-ietf-manet-dymo-05

["Dearlove, Christopher (UK)" <[e-mail]>]

Some comments on draft-ietf-manet-dymo-05. Many should
be credited to my colleague Alan Cullen rather than me.

- Section 2: is "small, medium or large" quantifiable?

- Section 2: "all" mobility ranges is definitely too
  broad a claim - I don't think any algorithm could
  ever claim this.

- Section 2: provided the layer in question supports
  multicast and unicast. (Not a major constraint, most do.)

- Route.Prefix: zero indicates no prefix. Is there any
  possibility you might want to use zero? Conceptually
  (I don't know if real routing tables support this)
  0.0.0.0/0 means "the Internet is this way - if you
  don't have a better idea". Might an ad hoc network
  sitting on the edge of the Internet want to indicate
  this? (I don't know, I'm just asking the question.)
  Later comment - I see you have a single bit concept
  of this instead, but you might still want /0.

- Is Route.Prefix really optional - particularly once we
  get into IPv6?

- I think it would be beneficial to clarify how address
  blocks are used: if more than one is possible is there
  any logic (other than convenience/efficiency of
  compression) to division of addresses between the
  blocks. Are there any address ordering constraints?
  This also relates to how additional addresses are
  recognised. Later comment - I see the AddTLV.Node.IsTarget
  attribute. I think an up front comment would help. I'm
  not sure about the first address - is it the target if
  no address has this TLV, but not the target if one does?
  I think it would be easier to go with position or TLV
  rather than a mixture. Even more so with the second
  address rule (how does it apply if there is more than
  one address block, the first block having one address?)

- According to the syntax specification in packetbb,
  the message TLV block is part of the message body, not
  part of the message header, so presenting it as part
  of the header in the example pictures isn't right.

- In the address block, address lengths are in octets, not
  bits, so the head length in the RREQ message should be 3,
  not 24.

- Again, using packetbb syntax, the TLV block length is not
  part of the address block, so again confusing (wrong).

- I'm not sure why the multivalue bit is set on the RREQ
  TLV when it only covers one index, so it makes no odds
  whether set or clear - I would have thought clear was
  easier, but maybe in the more general case you plan set,
  so might as well be set here.

- When there's only one address you could set head length
  to 0, 4 or anything in between with no other change.
  I find it easiest to code with it set to 4 (so as you
  add addresses the length may shrink) but anything goes.

- I'm interested in why rollover is from 65535 to 256 rather
  than the more obvious 1 (0 being taken). This is just for
  my own interest rather than any comment on the protocol.

- Can the process in 5.1.4 loop forever resetting its waiting
  period?

- I haven't reviewed the loop-prone stuff and similar points
  in detail at the moment I'm afraid.

- 5.2.2 "queued data packets". I think the whole concept of
  queuing data packets - mandatory or optional, how long for,
  is this standard IP or a modification? needs a comment up
  front (section 1 or 2). Later comment - I see a note in 5.4,
  but I still think this belongs up front (as well as or
  instead I'm not fussed).

- 5.3.1 can a standards track RFC reference an experimental
  RFC (3561) for part of its algorithm as here? (procedural
  question rather than technical).

- 5.5.2 requires lower layer support. It would be worth
  summarising this and other cases of cross-layer support (the
  initial route request) up front.

- 5.5.2 should this should be done only if the receiving interface
  matches Route.NextHopInterface?

- 5.5.3 is there any value in considering a hop limit less
  than diameter? You may have some idea of how far the intended
  target is - or is this now sufficiently dead it's dangerous
  to use (even with an added margin)?

- I have previously objected to 5.6.2. I maintain that objection.

- Use of A.B.C.1/24 rather than A.B.C.0/24 is unusual isn't it?
  But packetbb supports it (though it can support A.B.C.0/24
  more efficiently now) so if it's what you want/need, fine.

- 5.8 is a model of a single gateway and a stub MANET. Is this
  the only model supported? (Not a problem, but worth indicating
  - maybe this is up front stuff too.) If not could use some
  more material.

- 5.10 is entitled packet generation limits, but discusses message
  limits. The multi-message packet format in packetbb could really
  help you here.

- Section 6 reports cases in terms of small and medium, this ties
  in with an earlier comment - and here you must have done tests.

- Section 8. As DYMO messages are mutable, this must be hop by
  hop I think, and worth saying.

- Isn't packetbb a normative reference?


********************************************************************
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-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt