Re: [manet] draft-ietf-manet-rfc5444-usage

[Abdussalam Baryun <[e-mail]>]

Hi Chris, and WG,

IMO, this draft needs to clarify the usage for both reactive and proactive
routings, but it seems like it is for hybrid protocols only. I suggest that
we get more input from the AODVv2 experts/authors to comment on this work.
In our discussions before we seen MANET participants saying what 5444
experts think but I think that the packet-format experts cannot guide our
protocol experts (i.e. this draft is guiding protocol design). Usually the
protocol is the master of the packet not the packet is mastering the
protocol, however, It appears that our MANET WG has done the format-usage
to guide the general protocol, am I wrong?, I think it was good to do the
RFC5444 as general and let the protocol expert find what is the best rule
to use. It is better for routing security that proactive routing uses 5444
differently than reactive, am I wrong?

The best for this 5444 usage draft to be for general-routing, and needs to
include with section titles: How best to use 5444 for Proactive Routing
Protocol (including multiplexer roles), 2- How best to use 5444 for
Reactive Routing Protocol (including multiplexer roles). The hybrid routing
usage of 5444 can be done when we recharter. Furthermore, this draft should
be for only unicast routing protocols because we still did not do the
multicast routing (so this needs to be clear in the draft). Also we should
not ignore that our AODVv2 draft needs to be completed, and is not done yet
so we need to firstly complete it before submitting this usage of
packet-format. IMO this idea of 5444 and its RFC was the reason of delaying
the WG effort of AODVv2, therefore, I suggest that we don't make this
standard until completing AODVv2 (i.e. it will help the discussions for
both drafts).

I am expecting that my suggestion will be refused, but I think my reasons
can be understood.

AB

Humans designed the general ball, so it is good to let different people to
play-with/use it with different rules. Different players/experts use
different balls with different rules. Why do we limit the general design so
that all players use the ball the same way?

On Fri, Apr 29, 2016 at 6:04 PM, Dearlove, Christopher (UK) <
[e-mail]> wrote:

> WGLC having finished, I've been through everyone's comments. And by my
> reckoning this is what we (the authors) should do (agreed changes, and in
> at least one case I had an "aha" that's what I think is being asked for, in
> which case we can do that).
>
> - Section 4.2 is titled Packets and Messages, but is about Multiplexer.
> Take under advisement, can see both sides of that. Hope when we've done
> everything else what's best will be clear.
>
> - Section 4.4 "An unmodified extension to NHDP would ignore such
> addresses" Be clear that ignoring if just present. Don't ignore if address
> has TLVs router is using. Also be clearer up front in this paragraph that
> discussing case in final sentence.
>
> - Section 4.5. Some words up front as to why this material is here.
>
> - Read through document to check if clear where advice is for protocol
> designer, and where is for protocol implementer. The former is our main
> emphasis, though comments about parsing are the latter.
>
> - Words up front to be clear that, as well as multiplexer (and how RFC
> 5498 mandates that),RFC  5444 only specifies formats; parsing (and its
> opposite - forming?) is done by protocol. An implementer may simply do this
> in a protocol, but a natural design is a separate parser used by multiple
> protocols (e.g. NHDP and OLSRv2). Some comments are about if you choose to
> do latter, especially Section 6.4 but don't leave first mention to there.
> But a separate parser is not a requirement.
>
> - Section 6.1 to be clear, addresses always have a head a mid and a tail.
> Gain compression advantage when head and/or tail are not empty.
>
> - Section 6.1 " Putting addresses into a message efficiently also has to
> include" s/include/consider/
>
> - Section 6.2 Be clear that analysis of NHDP and OLSRv2 shows ordering
> possible, but the details are beyond the scope of this document.
>
> - Section 6.3 Be clear that UNSPECIFIED is for TLVs with discrete values
> (usually specified in a registry). There is an equivalent in at least one
> other case (OLSRv2 metrics).
>
> - Section 4.2 first bullet, or elsewhere cross-referenced. Be clear
> (reference to 5444 appendix) that the recommended approach is messages
> unchanged except for hop count/limit, because it enables E2E
> authentication, in particular using RFC 7182 message TLVs.
>
> - Section 4.2 bullet 3, add comment that protocol should not produce
> message that (with additional headers) would exceed MTU if sent on its own
> in a packet. (If it does, as the multiplexer can't fragment, IP will have
> to, and that's undesirable.)
>
> - Multiplexer adding packet sequence number, MUST be consistent (add to
> all packets or none - for each interface and destination as it already
> says).
>
> - Probably (if there's a suitable place to say it) note that the
> multiplexer has a relationship (message transfer) with protocols that own
> messages. The interaction between a protocol and any extensions is up to
> them, not the multiplexer.
>
> - Change uses of extended type to full type. Add full type to Terminology,
> matching to symbolic name in RFC 5444. Check if extended type is used in
> other RFCs, if it is, add comment that sometimes so referred to.
>
> Somewhere be clear that routers in a MANET need to have a common
> understanding of RFC 7182 usage, including whether by multiplexer (always
> for packets) or protocol.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence Laboratories
> __________________________________________________________________________
>
> T:  [phone]  |  E: [e-mail]
>
> 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
>
> ********************************************************************
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>