Subject: [manet] AB#2 (olsrv2-multitopology): Adding section for packets

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 18 Sep 2014 15:36:48 +0200

The draft depends on RFC7181, however, the draft does not define/restrict
RFC7181 packets clearly. In RFC7181 section 13.2, it specifies what are the
protocol packets. The protocol packets are having freedom to include all
RFC5444 messages even for other protocols. In 7181 it mentions in section
13.2:

{{{

Messages with different originating routers MAY be combined for
transmission within the same packet.  Messages from other protocols defined
using [RFC5444], including but not limited to NHDP [RFC6130], MAY be
combined for transmission within the same packet.

}}}

AB> For this protocol MT OLSRv2, it is reasonable to follow the edition way
of RFC7181 and to having a subsection of packet and to describing the
conditions for MT protocol in one clear section as did 7181 for non-MT
protocol. So I suggest to add one section/subsection of packets for MT
OLSRv2 and that describes restrictions/conditions of multitopology messages
to be combined among topologies.

AB

--- past review input related below ---

1. http://www.ietf.org/mail-archive/web/manet/current/msg16890.html
2. http://www.ietf.org/mail-archive/web/manet/current/msg16892.html
3. http://www.ietf.org/mail-archive/web/manet/current/msg16895.html
4. http://www.ietf.org/mail-archive/web/manet/current/msg17009.html

---

From: Henning Rogge <[email-masked]>
Date: Thu, 18 Sep 2014 18:24:56 +0200

On Thu, Sep 18, 2014 at 3:36 PM, Abdussalam Baryun
<[email-masked]> wrote:
> Messages with different originating routers MAY be combined for transmission
> within the same packet.  Messages from other protocols defined using
> [RFC5444], including but not limited to NHDP [RFC6130], MAY be combined for
> transmission within the same packet.
>
> }}}
>

I don't think the MT-OLSRv2 draft restricts the mechanism described in
section 13.2 of RFC 7181 in any way. It only defines extensions of the
existing TC messages. It does not even change any part of the flooding
process, including the flooding MPR set.

Could you maybe specify where you see the need of additional
restrictions/conditions and what kind of messages you want to combine
among different topologies?

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 18 Sep 2014 17:58:33 +0100

As Henning says, the original comment is wrong. It even uses the phrase RFC 7181 packets. There are no such things. (There are RFC 5444 packets, which may have some or all messages used by OLSRv2, or may not.)

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 18 Sep 2014, at 17:24, Henning Rogge <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Sep 2014 09:44:14 +0000

OK, I will agree I/we might have worded that slightly differently today. Rather than saying messages may be combined in packets, I would say messages (of different originators etc.)  can be sent to the multiplexer together for recommended inclusion in the same packet. But essentially this is a null comment, it says "The 5444 multiplexer may do what it is allowed to do."

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Christopher Dearlove [mailto:[email-masked]] 
Sent: 18 September 2014 17:59
To: Henning Rogge
Cc: Abdussalam Baryun; [email-masked]; [email-masked]
Subject: Re: [manet] AB#2 (olsrv2-multitopology): Adding section for packets

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

>> RFC7181 packets clearly. In RFC7181 section 13.2, it specifies what 
>> are the protocol packets. The protocol packets are having freedom to 
>> include all
>> transmission within the same packet.  Messages from other protocols 
>> defined using [RFC5444], including but not limited to NHDP [RFC6130], 
>> MAY be combined for transmission within the same packet.
>> 
>> }}}
>> 
>> AB> For this protocol MT OLSRv2, it is reasonable to follow the 
>> AB> edition way
>> conditions for MT protocol in one clear section as did 7181 for 
>> non-MT protocol. So I suggest to add one section/subsection of 
>> packets for MT
>> OLSRv2 and that describes restrictions/conditions of multitopology 
>> messages to be combined among topologies.
> 

********************************************************************
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.
********************************************************************

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 19 Sep 2014 14:57:14 +0200

Hi Henning,

> process, including the flooding MPR set.

I think it should do, to ensure (with its conditions) that any packet
have combine messages of only same topology. RFC7181 section 13.2 does not
ensure that because it is not MT protocol. So it will be good to refer to
that in one section in this draft of MT.

> among different topologies?

IMO Conditions for MT are related to: metrics, route maintenance, and
packets. The draft tries to use assumptions but that can not be enough for
me without having analysis presented in IETF. IMHO, the dynamic topologies
can not have its control-messages mixed in one same packet. The draft
restricts that each topology has one-metric-type, but does not restrict
its control-packets, that is why we need a section about packets to
fix that. I will review the related drafts again to write down the full
conditions for this draft.

Regards,

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 19 Sep 2014 18:51:17 +0100

Wrong, wrong and wrong again. This is getting tiresome.

On 19 Sep 2014, at 13:57, Abdussalam Baryun wrote:

> I think it should do, to ensure (with its conditions) that any packet have combine messages of only same topology. RFC7181 section 13.2 does not ensure that because it is not MT protocol. So it will be good to refer to that in one section in this draft of MT. 
> 
> 
> IMO Conditions for MT are related to: metrics, route maintenance, and packets. The draft tries to use assumptions but that can not be enough for me without having analysis presented in IETF. IMHO, the dynamic topologies can not have its control-messages mixed in one same packet. The draft restricts that each topology has one-metric-type, but does not restrict its control-packets, that is why we need a section about packets to fix that. I will review the related drafts again to write down the full conditions for this draft. 
> 
> Regards,
> 
> AB

---

From: Jiazi YI <[email-masked]>
Date: Fri, 19 Sep 2014 21:40:43 +0200

> that in one section in this draft of MT.

No. There is nothing special regarding this point that needs to be added.

best

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 20 Sep 2014 00:15:29 +0200

Hi Chris,

We can look into use cases of MT, which helps know what we need (that was
my first question when the draft was proposed). However, we want to use
this work in best way we can/want.

> combined for transmission within the same packet.

Could we have  5444 packet tlv for MT OLSRv2 that may help to simplify the
MT administrative work? IMHO this will help identify packets per topology
or per use case. The current draft just looks into metric types for
topologies.
AB

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 19 Sep 2014 23:38:47 +0100

First, we don't need a packet TLV. We don't need to recognise "packets per topology". For not the first time of saying, references to packets in MT-OLSRv2 at to data packets. I'm not sure why you keep wanting to pull in 5444 packets, but unless anyone needs to, you shouldn't. Which means packet usage (packet TLVs) are for when someone has a concrete suggestion, not just a vague non-idea.

And beyond that, you are again trying to reopen closed questions already decided. Without showing understanding of them. The WG (which has done WGLC) agreed that in this experimental RFC that topology = metric (which is commonly used in other protocols) was a sensible approach, given that no one could see a clean more general solution that interworked with non-MT-OLSRv2. Despite trying.

> On 19 Sep 2014, at 23:15, Abdussalam Baryun <[email-masked]> wrote:
> 
> Hi Chris,
> 
> We can look into use cases of MT, which helps know what we need (that was my first question when the draft was proposed). However, we want to use this work in best way we can/want. 
> 
>> The draft depends on RFC7181, however, the draft does not define/restrict RFC7181 packets clearly. In RFC7181 section 13.2, it specifies what are the protocol packets. The protocol packets are having freedom to include all RFC5444 messages even for other protocols. In 7181 it mentions in section 13.2:
>> 
>> {{{
>> 
>> Messages with different originating routers MAY be combined for transmission within the same packet.  Messages from other protocols defined using [RFC5444], including but not limited to NHDP [RFC6130], MAY be combined for transmission within the same packet.
>> 
>> }}}
> 
> Could we have  5444 packet tlv for MT OLSRv2 that may help to simplify the MT administrative work? IMHO this will help identify packets per topology or per use case. The current draft just looks into metric types for topologies. 
> 
> AB