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

[Christopher Dearlove <[e-mail]>]

There's nothing in the draft exclusive to proactive protocols. The examples are mostly of NHDP and OLSRv2, because those exist as Proposed Standards. But if you look closely they aren't about them being proactive or reactive, they are about that they illustrate protocol multiplexing and extensions.

We've had comments from members of the AODVv2 author team. I'm not sure what proportion of the changes to make are due to their comments, but it might be a majority.

--  
Christopher Dearlove
[e-mail] (iPhone)
[e-mail] (home)

> On 1 May 2016, at 10:55, Abdussalam Baryun <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet