Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"

Thank you for the submission. I too have some misgivings about the
documents current state and tradeoffs with regard to packet format and lack
of use of the Manet building blocks which seem like they could be easily
incorporated. RFC5444 has Hop-limit/count and sequence number fields, and
NHDP (RFC6130) has neighbor discovery and fixes the bidirectional problem.
In addition to the other security pieces and leveraging of CDS algorithms
found in either SMF or OLSRv2 one could build a similar protocol with only
the addition of a message type and a few TLVS. The two that jump out at me
for being useful beyond just this proposed protocol would be GPS and
Application/Higher Layer ID TLV encodings.

Justin Dean

On Wed, Jan 4, 2017 at 5:10 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> There some immediate retrograde steps compared to existing protocols:
> fixed message format (making adding new information to be used by the
> protocol hard), forwarding by blind flooding (hence scalability issues),
> and no security (an example of something that to add would require a
> changed format). The rather peculiar link metric (in effect) that mixes hop
> count, time and battery power leads to many questions (and while not simply
> hop count is likely to be a backward step in flexibility). There’s a rather
> unusual message body that is not used by this protocol but said to be for
> the application, which is a bit of a layering issue. GPS is included with
> no indication how to use and hence no indication why it is there. They are
> also underspecified in terms of format information (and for GPS at least
> even size of field). There’s quite a lot underspecified, such as route
> determination, and there’s no consideration of how the acknowledgements are
> used - and even what the meaning of acknowledgements in what must be (but
> is not so described) as a local broadcast/multicast message (with
> potentially unknown recipients). I don’t see any handling of the problems
> that link asymmetry produces. I’d have issues over timing parameters and
> their management (these being not reflected in the message). And in a
> proposed IETF protocol, I don’t see any IP addresses. That it hasn’t even
> caught up with the existence of RFC 7181 (only quoting RFC 3626) is not a
> good sign. It is suggested that RFC 3626 (and hence, no doubt, RFC 7181) is
> too complex. That may or may not be so (there are reasons for the added
> complexity in RFC 7181, which need to be understood before deciding whether
> you need them) and there thus may or may not be a space for a lightweight
> proactive protocol, but this is not that protocol in current or foreseeable
> evolutionary form.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194 <+44%201245%20242194>  |  *E: *
> chris.dearlove@baesystems.com
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai
>
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
>
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>
>
>
> *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Jiazi Yi
> *Sent:* 04 January 2017 09:08
> *To:* Peter S Lau (peterlau)
> *Cc:* manet@ietf.org
> *Subject:* Re: [manet] A proposed draft "draft-peterlau-manet-
> topology-refresh"
>
>
>
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> <http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> **** **WARNING ******
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
>
> Dear Peter,
>
>
>
> Thanks very much for your draft.
>
>
>
> Looking at the overview section:
>
>
>
>    TRP is a table-driven proactive data forwarding protocol and at the
>
>    same time allows users to announce their presence to the network.  A
>
>    node, wishing to be contacted, periodically broadcasts control
>
>    messages about itself to the network.  A node, receiving control
>
>    messages, caches an optimal path to each of the originators of the
>
>    control messages.
>
>
>
> Could you please briefly introduce what’s the difference between TRP and
> other proactive protocols like OLSR(v2)?
>
>
>
> Especially, it would be very helpful for the readers to understand by
> providing a bit more text about the mechanism of the protocol in the
> overview.
>
>
>
> best
>
>
>
> Jiazi
>
>
>
> On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <peterlau@memphis.edu>
> wrote:
>
>
>
> Dear manet Working Group:
>
> I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-refresh-00".
> for the WG to consider.
>
> Regards,
> Peter Lau
>
>
>
> Peter Lau
> The University of Memphis
> Electrical and Computer Engineering
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> ********************************************************************
> 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
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>