Subject: Re: [manet] Status of DLEP-draft at Cisco?

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 3 Jul 2012 19:49:04 +0200

Hi

It was mentioned in meeting 83 the interest of use RFC5444 and should
not be mandatory, however, it is important that we notice the reasons
why AODVv2 and DLEP may not use the RFC5444. It is understood so far
that AODVv2 and DLEP workers are still investigating the use
performance. On the other hand if more than one MANET routing draft
(excluding DLEP) don't use RFC5444 then I will try to investigate how
can we update RFC5444 so it can be more compatible to others without
affecting OLSRv2 and RFC6130.

 Regarding my work for DSRv2, I am interested also like Henning to
using DLEP. I am also considering the use of RFC5444 (even though I
notice AODVv2 may not use it with reasons) until I get a good
reason/result to not use it. However, IMO it is always a credit for
the protocol that it has the both possibility to use and not use
RFC5444 and let the industry/scenario decide.

Overall using RFC5444 or a future updated one by all MANET routing is
a big advantage for MANET.

Abdussalam Baryun
University of Glamorgan, UK

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To: Henning Rogge <henning.rogge at fkie.fraunhofer.de>
Subject: Re: [manet] Status of DLEP-draft at Cisco?
From: "Stan Ratliff (sratliff)" <sratliff at cisco.com>

Henning,

(Based on earlier discussions, *all* of this is from the perspective
of a Working Group Participant, and a Draft co-author/editor)...

Yes, the authors are still in discussions with regard to DLEP 5444
"compatibility".  There are still roughly 3 options I see for moving
forward.

1) Remove RFC 5444 compatibility as a requirement. This "solves" the
issue of multiple address types vis-a-vis address blocks. Also, since
the reactive protocol drafts being considered by the WG don't
necessarily require RFC 5444 (e.g., *both* LOADng and DYMO) don't
require or have non-5444 packets, the WG mandate that everything use
5444 seems capricious at best.

2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's,
leaving the addressing internal to DLEP. This avoids the issue of
carrying multiple address families in 5444 address blocks. I've seen
several recommendations on how to "pretend" that a MAC address (or an
IPv4 address) is IPv6, so as to carry everything in address blocks of
a single length. However, I see that as a hack, plain and simple. I'm
adamant that this won't fly - not at IESG review, at least. I'll lodge
the complaint against the draft myself if I have to on that one. In
order to do that, we'd need to….

3) Create RFC 54444 bis, or some other update to 5444 to handle
multiple address families with a single transmission.

Now, if the WG chooses option 2 or 3, I *still* see an issue with
respect to the mandate of "we must use 5444 for all drafts"…
especially since our reactive drafts seem to be excluded from that
mandate.  Long story short? I'm leaning towards option 1.

Regards,
Stan

On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote:

> Hello,
>
> I think it is time to talk about the status of the DLEP draft. We stopped the discussion to give the authors time to talk about the ideas of the WG about how to change and improve the draft.
>
> That was two months ago.
>
> I would like to hear an update how we should go forward with DLEP in the Manet WG, the concept is too important to just let it stay quiet for months.
>
> Has there been a decision what Cisco thinks about all the discussions we had in March/April? Do you work on a -03 draft updated to RFC5444 compatibility?
>
> I think that many members of the Manet WG are very interested to push DLEP forward.
>
> Regards
> Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 3 Jul 2012 21:48:09 +0200

============  possible duplication  ==========
+1

I still don't see good reasons of dlep-draft to leave 5444 (different
from AODVv2), I support the investigation of using 5444. DLEP is like
RFC6130 as discovery tool, but still we should not force the
investigation result. Please note that RFC5444 was designed for
routers exchange not for L2 technologies.

I heard before two months a suggestion for DLEPv2, so we may give the
first version it way and v2 may include 5444.

AB
=========
> On Tue, Jul 3, 2012 at 6:59 PM, Stan Ratliff (sratliff)
> <sratliff at cisco.com> wrote:
>> Chris,
>>
>> OK, that's fair enough. As you mention, since DLEP isn't a routing
>> protocol, and can exist quite cleanly on its own port, that's the
>> direction I'm leaning. I think there are also uses outside the MANET WG
>> where use of 5444 would actually cause more code to be employed, and
>> increase packet overhead (think ROLL)…
>
> I think the small overhead is pretty meaningless because DLEP is not
> sent over the mesh links, just between radio and router.
>
> Also the "use 6 byte addresses for MACs, use TLVs for IPv4/6" will
> work quite well for DLEP, because many radios will not even need the
> IPv4/6 part at all, especially with the bridged data-path DLEP
> describes.
>
> There should be the options to transmit IPv4/6 addresses over DLEP if
> they are available, but I wonder if this would be a common usecase.
>
> Most of the workinggroup seems to have the opinion that DLEP should
> move to full RFC5444 compliance, because it will fit the purpose of
> DLEP fine and spare the IETF "just another proprietary data format".
> With RFC5444 we can easily get to a point where we get a protocol that
> can be extended for more metrics without the need of a version field,
> which will simplify future DLEP revisions.
>
> Henning Rogge
> --
> Steven Hawkings about cosmic inflation: "An increase of billions of
> billions of percent in a tiny fraction of a second. Of course, that
> was before the present government."
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 4 Jul 2012 13:17:31 +0200

Hi John and Chris

I am more interested in DLEP (of any version) with RFC5444 (general
manet format)because DLEP serves routers without a need of specifying
routing protocol (it is general interaction with any router protocol),
also complexity may not be an issue because DLEP use-case is mostly
for complex networking (if I understood the use-case). If DLEP uses
5444 it may interact with NHDP for more advantages. Usually if we take
the case of OLSRv2 with DLEP the channel can be through NHDP or direct
between DLEP and router. Also if we consider that many other routings
may use NHDP (MANET-interface) then it is nice to have DLEP with 5444
for its use flexibility,

I recommend the DLEP designers to consider if they taking the general
interaction with all routers, then it is more simpler design to use
5444, but if they choose specific interaction with routers they may
not use 5444 but can be complex (e.g. routers: AODV, OLSR, LOAD,
future-manet-routers)

Regards

Abdussalam Baryun

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 5 Jul 2012 18:38:19 +0200

+1

As a group participant, we want most MANET protocols to use RFC5498,
but as I said before the messaging format is not the main issue (we
can if needed to update 5444 if helps), the main issue is
functionality, however, if not using RFC5498 there should be a good
reason why? by the way DSRv2 draft will be using RFC5444 and RFC5498.

Regards
AB
=====
> I'm of the view
> - There is no compulsion for DLEP to use 5444. The only compulsion is
> 5498's that anything using the manet protocol/port uses 5444.
> - 5444 is a flexible format. I believe (but no one has yet done and
> published the work to support that) that 5444 could be used to
> represent DLEP at least quite well, maybe very well.
> - The currently proposed way to use 5444 to represent DLEP is not a
> very good use of 5444 to do that.
> - The pros and cons of a non-5444 representation of DLEP versus a good
> 5444 representation of DLEP are hard to judge when neither is
> well-defined yet.
> - A key question is future extensibility, adding new attributes. This
> is a strength of 5444. How much is it needed by DLEP?
> - As an author of 5444 it's always gratifying when someone uses what
> you helped create. But that's not a factor in the choice.
>
> --
> Christopher Dearlove
> Senior Principal Engineer, Communications 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
> chris.dearlove at baesystems.com | 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: manet-bounces at ietf.org [mailto:manet-bounces at ietf.org] On
> Behalf Of Stan Ratliff (sratliff)
> Sent: 05 July 2012 15:07
> To: Henning Rogge
> Cc: <manet at ietf.org>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Keep this in mind if you answer this message.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>