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

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 1 May 2016 11:55:46 +0200

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) <
[email-masked]> 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:  +44 (0)1245 242194  |  E: [email-masked]
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 1 May 2016 12:06:58 +0100

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
[email-masked] (iPhone)
[email-masked] (home)

> On 1 May 2016, at 10:55, Abdussalam Baryun <[email-masked]> 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) <[email-masked]> 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.
>> 
>> - 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
>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>> www.baesystems.com/ai

---

From: John Dowdell <[email-masked]>
Date: Sun, 1 May 2016 15:26:46 +0100

I'd just like to be clear that the AODVv2 team asked for this document, and I think all of the author team have commented on one aspect or another.

John

Sent from my iPhone

> On 1 May 2016, at 12:06, Christopher Dearlove <[email-masked]> wrote:
>