Subject: [manet] RFC5444 packets for routing protocols (was Re: #33 (aodvv2): RFC 5444 processing constraint

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 9 Sep 2014 21:10:39 +0200

I think your understanding will not give opportunity for
future protocols to use its own packets or to use the 5444-packet with zero
messages (as RFC5444 defined this zero message possibility). Protocols
extensions may use exchange of 5444-packet with zero message, but if you
leave packets for only parsers then this limits the use of RFC5444 by
protocols, so they only define 5444-messages.

Comments below,

On Tuesday, September 9, 2014, Stan Ratliff (sratliff) wrote:

>
>  On Sep 8, 2014, at 8:58 PM, Abdussalam Baryun <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>>  Disregard does not mean drop, so those messages are still in
>> next 5444 packet. This comes back to multiplexing by ownership or not,
>> which that is not specified yet so we leave it for another future draft for
>> multiplexing. We need to focus this reactive standard not make it
>> complicated.
>>
>>
>>  Again, I respectfully disagree. A deployment model to envision is a
>> router, running both OLSRv2 and AODVv2. Both of those protocols share a
>> transport using RFC5444 to a second router, which is also running both
>> protocols. The "multiplexing" being spoken of would be a mix of OLSRv2 and
>> AODVv2 messages, bundled up into an RFC5444 packet.
>>
>
>  Ok, to be more general and to serve majority users of AODVv2 and more
> security consideration.  we need to consider that some users don't want
> such mix network and some do. First if users are wanting your mix scenario
> then they go for a parser that is unified for both protocols ( this
> case routers need same multiplexing method otherwise they don't work
> ), while parsers are independent of protocols as RFC5444 says. If the
> AODVv2 sends a packet then parser is able to do packing again locally with
> adding other messages if available. Secondly,  users don't want to use
> specific unified parser dependence, so just the one protocol packing with
> its user method for security purpose. This way we have more independence
> for this AODVv2.
>
>
>  If a given protocol specification/design adheres to the RFC 5444
> multiplexing as it should, then both of your scenarios above (e.g., "…some
> users don't want such mix network and some do.") work just fine.
>

But that limits the routing protocols use of 5444-packet as never they
should create packets. They will depend on parsers (even if one protocol is
running alone in the MANET) which can increase delays and maybe less QoS.
Designs need to be simple and the protocol packets are defined by protocols
not parsers.

> However, if a given protocol specification does NOT adhere to the RFC 5444
> multiplexing, it then PRECLUDES the protocol from being used in what you
> are calling a "mixed network".
>

No still we can use it in the mix, because the parser will understand
5444-packets. RFC5444 is for the protocol to define its packets not the
parser.

In summary, adherence to the RFC 5444 multiplexing gives deployments MORE
> flexibility instead of less, and is, IMHO, the superior design choice.  As
> for your assertion that "…users don't want to use specific unified parser
> dependenc…", I believe that is at best merely anecdotal, and at worst,
> completely baseless.
>

I think the use of RFC7181 is not flexible for users, because it depends on
the unified parser's packets, if parser fails/attacked then OLSRv2 fails.
IMHO, in future still 7181 will have more updates, which we had seen many
in short time.

AB

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Sep 2014 19:42:59 +0000

On Sep 9, 2014, at 3:10 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

I think your understanding will not give opportunity for future protocols to use its own packets or to use the 5444-packet with zero messages (as RFC5444 defined this zero message possibility). Protocols extensions may use exchange of 5444-packet with zero message, but if you leave packets for only parsers then this limits the use of RFC5444 by protocols, so they only define 5444-messages.

Precisely. And that is what is currently mandated by the RFC5498: MANET WG developed routing protocols only define RFC5444 messages, NOT RFC5444 packets. And the rest of the push-back you're getting on the list indicates there is NO interest whatsoever in re-litigating that decision.

Comments below,

On Sep 8, 2014, at 8:58 PM, Abdussalam Baryun <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

Disregard does not mean drop, so those messages are still in next 5444 packet. This comes back to multiplexing by ownership or not, which that is not specified yet so we leave it for another future draft for multiplexing. We need to focus this reactive standard not make it complicated.

Again, I respectfully disagree. A deployment model to envision is a router, running both OLSRv2 and AODVv2. Both of those protocols share a transport using RFC5444 to a second router, which is also running both protocols. The "multiplexing" being spoken of would be a mix of OLSRv2 and AODVv2 messages, bundled up into an RFC5444 packet.

Ok, to be more general and to serve majority users of AODVv2 and more security consideration.  we need to consider that some users don't want such mix network and some do. First if users are wanting your mix scenario then they go for a parser that is unified for both protocols ( this case routers need same multiplexing method otherwise they don't work ), while parsers are independent of protocols as RFC5444 says. If the AODVv2 sends a packet then parser is able to do packing again locally with adding other messages if available. Secondly,  users don't want to use specific unified parser dependence, so just the one protocol packing with its user method for security purpose. This way we have more independence for this AODVv2.

If a given protocol specification/design adheres to the RFC 5444 multiplexing as it should, then both of your scenarios above (e.g., "…some users don't want such mix network and some do.") work just fine.

But that limits the routing protocols use of 5444-packet as never they should create packets. They will depend on parsers (even if one protocol is running alone in the MANET) which can increase delays and maybe less QoS. Designs need to be simple and the protocol packets are defined by protocols not parsers.

What?!? There is no intersection with RFC5444 and QoS (or there needn't be). RFC5444 serves as formats for the routing protocol only; the data-path (which is where you would apply QoS) uses standard switching/forwarding techniques.

However, if a given protocol specification does NOT adhere to the RFC 5444 multiplexing, it then PRECLUDES the protocol from being used in what you are calling a "mixed network".

No still we can use it in the mix, because the parser will understand 5444-packets. RFC5444 is for the protocol to define its packets not the parser.

No, you can't.

In summary, adherence to the RFC 5444 multiplexing gives deployments MORE flexibility instead of less, and is, IMHO, the superior design choice.  As for your assertion that "…users don't want to use specific unified parser dependenc…", I believe that is at best merely anecdotal, and at worst, completely baseless.

I think the use of RFC7181 is not flexible for users, because it depends on the unified parser's packets, if parser fails/attacked then OLSRv2 fails. IMHO, in future still 7181 will have more updates, which we had seen many in short time.

OK. You are free to hold that opinion - as I am free to disagree with it.  But again, other than your emails, I see no desire to re-open, re-discuss, and re-decide the current architecture of RFC5444 packets/messages/multiplexing. And unless (or until) there is wide-spread desire to re-open that debate, I see no useful purpose in continuing this email thread, because the answer to all of your opinions/concerns  is "RFC5444 is what it is, and RFC5498 is what *it* is."

IMHO, it's time to move on to other discussions.

Stan