Subject: [manet] draft-shaio-manet-common-l3-interface

From: "Broderick, Don" <[email-masked]>
Date: Thu, 26 Mar 2015 18:14:21 +0000

We are submitting http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-interface/ to be an Experimental RFC. It describes an approach to overlay IP over MANET but does not specify a protocol; rather the focus is on an interface between IP and MANET that is local to one terminal. The draft also presents results of large scale simulations of this approach. Our intent is to show that it is not necessary to standardize the interface between these two layers by prescribing a new message exchange between them.

This draft was submitted to the MANET working group for 12 months and we are now asking if it can be moved to Experimental RFC status, based on our understanding of RFC 2026 section 4.2.

Thank You,
Donald Broderick
The MITRE Corporation
202 Burlington Road
Bedford, MA   01730

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Mar 2015 13:20:47 +0100

Hi,

I think before a document can become a MANET RFC it needs to be
adopted by the working group.

Henning Rogge

On Thu, Mar 26, 2015 at 7:14 PM, Broderick, Don <[email-masked]> wrote:
> We are submitting
> http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-interface/ to be
> an Experimental RFC. It describes an approach to overlay IP over MANET but
> does not specify a protocol; rather the focus is on an interface between IP
> and MANET that is local to one terminal. The draft also presents results of
> large scale simulations of this approach. Our intent is to show that it is
> not necessary to standardize the interface between these two layers by
> prescribing a new message exchange between them.
>
>
>
> This draft was submitted to the MANET working group for 12 months and we are
> now asking if it can be moved to Experimental RFC status, based on our
> understanding of RFC 2026 section 4.2.
>
>
>
> Thank You,
>
> Donald Broderick
>
> The MITRE Corporation
>
> 202 Burlington Road
>
> Bedford, MA   01730
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Jiazi YI <[email-masked]>
Date: Fri, 27 Mar 2015 14:35:32 +0100

Hi,

I don't know what "IP router" exactly means in the draft. The definition of
MANET terminal and the Reference Diagram don't sound fit in the current
MANET architecture.

   MANET Terminal: The terminal comprising only MANET routing and radio
       access to the MANET, but not an IP routing component.

         -------------------
        |   [IP router]     |
        |        |          |
        | [Common Layer 3]  |
        |        |          |
        | [MANET terminal]  |
         -------------------
                 |
            Radio Network

btw, when submitted to IETF, it is recommended to change a "paper"  to a
"document" or  "specification", or other more appropriate format.

regards

Jiazi

On Thu, Mar 26, 2015 at 7:14 PM, Broderick, Don <[email-masked]> wrote:

>  We are submitting
> http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-interface/ to
> be an Experimental RFC. It describes an approach to overlay IP over MANET
> but does not specify a protocol; rather the focus is on an interface
> between IP and MANET that is local to one terminal. The draft also presents
> results of large scale simulations of this approach. Our intent is to show
> that it is not necessary to standardize the interface between these two
> layers by prescribing a new message exchange between them.
>
>
>
> This draft was submitted to the MANET working group for 12 months and we
> are now asking if it can be moved to Experimental RFC status, based on our

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 27 Mar 2015 10:25:54 -0400

Hello Working Group,

As was mentioned in an earlier email, the first step for this document
would be to accept it as a working group doc. So, I ask the WG to review
and comment on this draft, with a concentration on whether it should be
accepted as a working group item, with the author's stated desire to
ultimately publish as Experimental.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 27 Mar 2015 15:38:13 +0100

> prescribing a new message exchange between them.

After reading the introduction I have already one important question...

You state that (about the modification of existing protocols to MANET)

> Key to these modifications is an algorithm that will choose intelligently, among
> all potential IP routing peers in the MANET, those that provide the "best" set of
> IP routing adjacencies.

This ignores the routing metrics. An algorithm which is just deciding
the "neighbor set" of a routing algorithm would be unable to provide
different costs for the links, which would mean that the MANET would
run with a "hopcount metric".

Practical experience shows that this does not work.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 27 Mar 2015 15:23:33 +0000

This is related to that the draft has no mention of OLSRv2, only OLSR (v1). At a minimum I don't think that's acceptable in a MANET WG draft, and it's not just a matter of changing the reference.

Incidentally with regard to Jiazi's question what is a router, I think (but this is another issue) this means a router in the sense of a hardware router, not just something that performs that architectural function. I could be wrong. But if it doesn't mean that, then we now have two routers and I really don't see why we need the non-MANET one (and can it cope with the network dynamism in many MANETs?)

If you did want just the local connectivity information, don't use OLSRv1 or v2; use NHDP. Maybe with OLSRv2's metrics?

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

> On 27 Mar 2015, at 14:38, Henning Rogge <[email-masked]> wrote:
>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 27 Mar 2015 16:31:57 +0000

Our usual approach to that is to represent each network to the other as (OLSRv2 terminology) and attached network at a gateway and not want to know what's going on in the other network. If you want to use the MANET as a transit network it's harder. But ideas that involved metrics in that case to decide whether to transit the MANET were part of the OLSRv2 motivation, I wrote about that over a decade ago at the second (I think) OLSR interop. 
Metric was hop count there, but similar principle.

> On 27 Mar 2015, at 15:32, Jack Shaio <[email-masked]> wrote:
> 
> Thanks Christopher,
> 
> We used OLSR because at the time we had a software implementation from olsr.org and the draft covers the setup
> we tested with.
> 
> The intent of comnon layer 3 was to allow a MANET to be part of a larger IP network, not all of it communicating over MANET.
> As such, we do not assume we can choose the MANET protocol as we like. Instead, we take the MANET protocol as a given
> and try to find a way to export some of its knowledge, in the form of IP routing adjacencies, to the larger IP network
> 
> 
> 
> --jack shaio
> 
> 
> 
> On Fri, 27 Mar 2015 15:23:33 +0000  Christopher Dearlove <[email-masked]> expounded:
> 
> === Date: Fri, 27 Mar 2015 15:23:33 +0000
> === From: Christopher Dearlove <[email-masked]>
> === To: Henning Rogge <[email-masked]>
> === Cc: "Broderick, Don" <[email-masked]>,        "Jack Shaio ([email-masked])" <[email-masked]>,        Caleb Lo <[email-masked]>, "[email-masked]" <[email-masked]>
> === Subject: Re: [manet] draft-shaio-manet-common-l3-interface
> === 
> === This is related to that the draft has no mention of OLSRv2, only OLSR (v1). At a minimum I don't think that's acceptable in a MANET WG draft, and it's not just a matter of changing the reference.
> === 
> === Incidentally with regard to Jiazi's question what is a router, I think (but this is another issue) this means a router in the sense of a hardware router, not just something that performs that architectural function. I could be wrong. But if it doesn't mean that, then we now have two routers and I really don't see why we need the non-MANET one (and can it cope with the network dynamism in many MANETs?)
> === 
> === If you did want just the local connectivity information, don't use OLSRv1 or v2; use NHDP. Maybe with OLSRv2's metrics?
> === 
> === --  
> === Christopher Dearlove
> === [email-masked] (iPhone)
> === [email-masked] (home)
> === 
> === > On 27 Mar 2015, at 14:38, Henning Rogge <[email-masked]> wrote:
> === > 
> === >> On Thu, Mar 26, 2015 at 7:14 PM, Broderick, Don <[email-masked]> wrote:
> === >> We are submitting
> === >> http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-interface/ to be
> === >> an Experimental RFC. It describes an approach to overlay IP over MANET but
> === >> does not specify a protocol; rather the focus is on an interface between IP
> === >> and MANET that is local to one terminal. The draft also presents results of
> === >> large scale simulations of this approach. Our intent is to show that it is
> === >> not necessary to standardize the interface between these two layers by
> === >> prescribing a new message exchange between them.
> === > 
> === > After reading the introduction I have already one important question...
> === > 
> === > You state that (about the modification of existing protocols to MANET)
> === > 
> === >> Key to these modifications is an algorithm that will choose intelligently, among
> === >> all potential IP routing peers in the MANET, those that provide the "best" set of
> === >> IP routing adjacencies.
> === > 
> === > This ignores the routing metrics. An algorithm which is just deciding
> === > the "neighbor set" of a routing algorithm would be unable to provide
> === > different costs for the links, which would mean that the MANET would
> === > run with a "hopcount metric".
> === > 
> === > Practical experience shows that this does not work.
> === > 
> === > Henning Rogge
> === > 
> === > _______________________________________________
> === > manet mailing list
> === > [email-masked]
> === > https://www.ietf.org/mailman/listinfo/manet
> 
> 
> 
>

---

From: Jiazi YI <[email-masked]>
Date: Fri, 27 Mar 2015 17:41:07 +0100

My understanding is that we have two routers (or at least, logically):

    - A IP router running protocols like OSPF
    - A MANET router (or terminal) running MANET routing protocols.

        The draft tries to use CL3 to connect them.

I feel the gateway should be an easier solution? OLSRv2 has related
information set (like Local Attached Network Set, etc.) to do it.

regards

Jiazi

On Fri, Mar 27, 2015 at 4:23 PM, Christopher Dearlove <
[email-masked]> wrote:

> This is related to that the draft has no mention of OLSRv2, only OLSR
> (v1). At a minimum I don't think that's acceptable in a MANET WG draft, and
> it's not just a matter of changing the reference.
>
> Incidentally with regard to Jiazi's question what is a router, I think
> (but this is another issue) this means a router in the sense of a hardware
> router, not just something that performs that architectural function. I
> could be wrong. But if it doesn't mean that, then we now have two routers
> and I really don't see why we need the non-MANET one (and can it cope with
> the network dynamism in many MANETs?)
>
> If you did want just the local connectivity information, don't use OLSRv1
> or v2; use NHDP. Maybe with OLSRv2's metrics?
>
> --
> Christopher Dearlove

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 28 Mar 2015 08:18:10 +0200

I agree with Chris. Adding I will need the draft to include the
relationship with NHDP if any or why not.
Therefore, I don't accept this draft because it needs updating.

 However, the main idea is interesting to me and I would like to hear more
(see more information or participation) from the authors. The idea can be a
future update for the RFC6130 if the experiment gets more interest and
becomes successful.

Thanks,

AB

---

From: Rick Taylor <[email-masked]>
Date: Sat, 28 Mar 2015 09:27:11 +0000

All,

First, I'm sorry if this email comes across as a bit terse, but I'm on
my way home from Dallas, and the jet-lag is kicking in.

I'm afraid I'm not in favour of adopting this document as a WG draft,
for a number of reasons in no particular order:

1) I find the terminology unclear, and although that is not a
show-stopper, I feel that it highlights that the authors may not have
been tracking the progress of the MANET WG over the last few years.

2) Although I understand what the authors have done, I'm not sure what
new technique or technology they are proposing for experimental status. 
The draft reads as an experimental write-up: "We did this, and here are
the results".  This is not my understanding of what an experimental
draft is for.  Maybe an informational draft may be more appropriate.

3) In the text in the email announcing the draft, Dan states: "Our
intent is to show that it is not necessary to standardize the interface
between these two layers by prescribing a new message exchange between
them."  However, the MANET WG has just finished 5 years of work getting
DLEP to WG last call.  And DLEP is the "new message exchange".  And DLEP
solves a superset of problems that CL3 can't address. (Disclaimer: I'm
an author)

4) The MANET WG has worked hard to produce a reactive and pro-active
MANET routing protocol suitable for IP, with possibly applicability at a
lower layer.  Building an overlay using a non-MANET routing protocol to
provide IP routing over a MANET lower layer seems to me a backwards step.

5) There is a proposed future work item for the WG to look at gateways
between MANET networks and the fixed infrastructure, and it seems that
that approach has rough consensus as the right way to go.

6) It's not actually clear from the document what CL3 is.  It seems to
me that CL3 is a some code that uses OSPF packet sniffing, something
with PPP, and some SNMP to some low layer routers/forwarders/modems and
some poking pack up to the OSPF agent to spoof neighbour discovery and
link state (what state?).  That's about all I can glean.

I'm afraid I just feel that the team behind this draft may have been
working in isolation from the IETF MANET effort, and may be a little
behind the curve.  Might I suggest that a next step for them might be to
look at DLEP and OLSRv2 and perhaps experiment with writing a DLEP
interface around their code base, and perhaps issue a new informational
draft entitled something like 'Some techniques for implementing DLEP
over exisiting low-layer MANETs using SNMP, and PPP".  That might pique
my interest and perhaps some of the others of the group.

I don't mean to be negative, and I certainly don't want to appear
unwelcoming, but I think this document is 5 years late.

Cheers,

Rick Taylor
Airbus Defence & Space
(Using personal email because corporate firewalls are a pain at times)

---

From: John Dowdell <[email-masked]>
Date: Sat, 28 Mar 2015 12:56:33 +0000

Just wondering if the CL3 paper is publically available seeing as it is a normative reference.

Some experience in operational trials, albeit not using any manet routing protocol (and sorry those results are not publically releasable), shows that it is more productive to properly partition the fixed and mobile networks, since they have very different behaviours and needs. The CL3 method is interesting to see but I think it would be difficult to get working in practice.

John

-----Original Message-----
From: "Rick Taylor" <[email-masked]>
Sent: ‎28/‎03/‎2015 09:27
To: "Christopher Dearlove" <[email-masked]>
Cc: "Broderick, Don" <[email-masked]>; "Jack Shaio ([email-masked])" <[email-masked]>; "[email-masked]" <[email-masked]>; "Caleb Lo" <[email-masked]>
Subject: Re: [manet] draft-shaio-manet-common-l3-interface

All,

Cheers,

Rick Taylor
Airbus Defence & Space

---

From: Jack Shaio <[email-masked]>
Date: Fri, 27 Mar 2015 14:27:49 -0400

Thanks for your comments, Jianzi.

You are correct that there is an IP router running common IP protocols, a MANET router or terminal and a CL3 interface between them.

Both the choice of IP routing protocol at the router and the choice of MANET routing protocol at the terminal are given and were not
subject to change by CL3. The CL3 interface is to allow both of them to interoperate without requiring a standard that limits these choices.
We do not assume that the MANET protocol is OLSRv2; in many cases of practical importance it is not and we still need to interoperate
with the MANET. We picked OLSR (v1) only as a test case for CL3 because a good implementation was available to us at the time.

I believe the Local Attached Network set from OLSRv2 will only inform OLSRv2 of other interfaces that do not run this protocol.
But this will not inform IP at the router of potential OSPF peers across the MANET, which is what our CL3 interface is for.

One key feature of CL3 is that it will filter potential OSPF peers based on how stable connectivity to them has been in the past, as would happen
with mobile nodes constantly moving in and out of radio coverage. Presenting all potential OSPF routing peers to the IP layer would lead to
constant routing updates in the OSPF area as these peers entered and left radio coverage. Similar unstable routing would happen if the IP
protocol was RIP or IS-IS.

--jack shaio

  sent from my Debian Linux system:
    ASUS P6X58-E WS | Intel Xeon W3690 | MSI GTX-660 Ti | Creative X-Fi | Seasonic X-650 | Silverstone FT-02 | Akasa Freedom Tower

On Fri, 27 Mar 2015 17:41:07 +0100  Jiazi YI <[email-masked]> expounded:

=== Date: Fri, 27 Mar 2015 17:41:07 +0100
=== From: Jiazi YI <[email-masked]>
=== To: Christopher Dearlove <[email-masked]>
=== Cc: Henning Rogge <[email-masked]>, "Broderick, Don" <[email-masked]>,        "[email-masked]" <[email-masked]>, Caleb Lo <[email-masked]>,        "Jack Shaio ([email-masked])" <[email-masked]>
=== Subject: Re: [manet] draft-shaio-manet-common-l3-interface
=== 
=== My understanding is that we have two routers (or at least, logically):
=== 
===     - A IP router running protocols like OSPF
===     - A MANET router (or terminal) running MANET routing protocols.
=== 
===         The draft tries to use CL3 to connect them.
=== 
=== I feel the gateway should be an easier solution? OLSRv2 has related
=== information set (like Local Attached Network Set, etc.) to do it.
=== 
=== regards
=== 
=== Jiazi
=== 
=== 
=== 
=== 
=== On Fri, Mar 27, 2015 at 4:23 PM, Christopher Dearlove <
=== [email-masked]> wrote:
=== 
=== > This is related to that the draft has no mention of OLSRv2, only OLSR
=== > (v1). At a minimum I don't think that's acceptable in a MANET WG draft, and
=== > it's not just a matter of changing the reference.
=== >
=== > Incidentally with regard to Jiazi's question what is a router, I think
=== > (but this is another issue) this means a router in the sense of a hardware
=== > router, not just something that performs that architectural function. I
=== > could be wrong. But if it doesn't mean that, then we now have two routers
=== > and I really don't see why we need the non-MANET one (and can it cope with
=== > the network dynamism in many MANETs?)
=== >
=== > If you did want just the local connectivity information, don't use OLSRv1
=== > or v2; use NHDP. Maybe with OLSRv2's metrics?
=== >
=== > --
=== > Christopher Dearlove
=== > [email-masked] (iPhone)
=== > [email-masked] (home)
=== >
=== > > On 27 Mar 2015, at 14:38, Henning Rogge <[email-masked]> wrote:
=== > >
=== > >> On Thu, Mar 26, 2015 at 7:14 PM, Broderick, Don <[email-masked]> wrote:
=== > >> We are submitting
=== > >> http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-interface/
=== > to be
=== > >> an Experimental RFC. It describes an approach to overlay IP over MANET
=== > but
=== > >> does not specify a protocol; rather the focus is on an interface
=== > between IP
=== > >> and MANET that is local to one terminal. The draft also presents
=== > results of
=== > >> large scale simulations of this approach. Our intent is to show that it
=== > is
=== > >> not necessary to standardize the interface between these two layers by
=== > >> prescribing a new message exchange between them.
=== > >
=== > > After reading the introduction I have already one important question...
=== > >
=== > > You state that (about the modification of existing protocols to MANET)
=== > >
=== > >> Key to these modifications is an algorithm that will choose
=== > intelligently, among
=== > >> all potential IP routing peers in the MANET, those that provide the
=== > "best" set of
=== > >> IP routing adjacencies.
=== > >
=== > > This ignores the routing metrics. An algorithm which is just deciding
=== > > the "neighbor set" of a routing algorithm would be unable to provide
=== > > different costs for the links, which would mean that the MANET would
=== > > run with a "hopcount metric".
=== > >
=== > > Practical experience shows that this does not work.
=== > >
=== > > Henning Rogge
=== > >
=== > > _______________________________________________
=== > > manet mailing list
=== > > [email-masked]
=== > > https://www.ietf.org/mailman/listinfo/manet
=== >
=== > _______________________________________________
=== > manet mailing list
=== > [email-masked]
=== > https://www.ietf.org/mailman/listinfo/manet
=== >

--jack shaio

  sent from my Debian Linux system:
    ASUS P6X58-E WS | Intel Xeon W3690 | MSI GTX-660 Ti | Creative X-Fi | Seasonic X-650 | Silverstone FT-02 | Akasa Freedom Tower

---

From: Jack Shaio <[email-masked]>
Date: Fri, 27 Mar 2015 11:32:02 -0400

Thanks Christopher,

 
--jack shaio

---

From: Jack Shaio <[email-masked]>
Date: Fri, 27 Mar 2015 11:17:28 -0400

Henning,

Thanks for looking at the draft, I appreciate your taking the time to comment on it.

I don't think the observation below is correct: a common layer 3 algorithm looks for a set of IP routing adjacencies,
where IP is at the network layer. The MANET protocol runs independently with its own link costs. In our case we used
OLSR, a MANET link state protocol and exploited heavily our ability to view into its link state database.

Once the common layer 3 algorithm has selected, on its own criteria, a proper set of IP adjacencies, they are communicated
to the IP routing protocol using SNMP or some other tool. To the IP layer, these are IP routing adjacencies representing an overlay over
the MANET. They have a single IP metric, just as a GRE tunnel could be configured as an IP routing adjacency with a single IP link cost,
regardless of whether the IP routing protocol is hop count as RIP or link state as OSPF or IS-IS

This does not prevent the MANET protocol of using its own link metrics and changing routes as conditions change. We focused
on testing this case. Our addition is representing the set of potential IP endpoints on the MANET in a way a standard IP routing
protocol (OSPFv2 in our test case) can use as IP routing adjacencies without knowledge or direct interaction with the MANET
routing protocol.

=== This ignores the routing metrics. An algorithm which is just deciding
=== the "neighbor set" of a routing algorithm would be unable to provide
=== different costs for the links, which would mean that the MANET would
=== run with a "hopcount metric".
=== 
=== Practical experience shows that this does not work.

--jack shaio

On Fri, 27 Mar 2015 15:38:13 +0100  Henning Rogge <[email-masked]> wrote:

=== Date: Fri, 27 Mar 2015 15:38:13 +0100
=== From: Henning Rogge <[email-masked]>
=== To: "Broderick, Don" <[email-masked]>
=== Cc: "[email-masked]" <[email-masked]>, Caleb Lo <[email-masked]>,        "Jack Shaio ([email-masked])" <[email-masked]>
=== Subject: Re: [manet] draft-shaio-manet-common-l3-interface
=== 
=== On Thu, Mar 26, 2015 at 7:14 PM, Broderick, Don <[email-masked]> wrote:
=== > We are submitting
=== > http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-interface/ to be
=== > an Experimental RFC. It describes an approach to overlay IP over MANET but
=== > does not specify a protocol; rather the focus is on an interface between IP
=== > and MANET that is local to one terminal. The draft also presents results of
=== > large scale simulations of this approach. Our intent is to show that it is
=== > not necessary to standardize the interface between these two layers by
=== > prescribing a new message exchange between them.
=== 
=== After reading the introduction I have already one important question...
=== 
=== You state that (about the modification of existing protocols to MANET)
=== 
=== > Key to these modifications is an algorithm that will choose intelligently, among
=== > all potential IP routing peers in the MANET, those that provide the "best" set of
=== > IP routing adjacencies.
=== 
=== This ignores the routing metrics. An algorithm which is just deciding
=== the "neighbor set" of a routing algorithm would be unable to provide
=== different costs for the links, which would mean that the MANET would
=== run with a "hopcount metric".
=== 
=== Practical experience shows that this does not work.
=== 
=== Henning Rogge

---

From: Jack Shaio <[email-masked]>
Date: Fri, 27 Mar 2015 09:33:14 -0400

I believe that is true of draft standards but not of Informational or Experimental drafts, which do not define a standard and are provided only
as information for the IETF community. 

This is what I understood from the relevant section of RFC 2026 which defined the process: http://www.rfc-editor.org/rfc/rfc2026.txt 

4.2.3  Procedures for Experimental and Informational RFCs

   Unless they are the result of IETF Working Group action, documents
   intended to be published with Experimental or Informational status
   should be submitted directly to the RFC Editor.  The RFC Editor will
   publish any such documents as Internet-Drafts which have not already
   been so published.  In order to differentiate these Internet-Drafts
   they will be labeled or grouped in the I-D directory so they are
   easily recognizable.  The RFC Editor will wait two weeks after this
   publication for comments before proceeding further...
 
We thought this work was relevant to the manet WG and wanted to give the group another opportunity to comment on the draft first,
before submitting directly to the RFC Editor as the procedures state.

--jack shaio

On Fri, 27 Mar 2015 13:20:47 +0100  Henning Rogge <[email-masked]> expounded:

=== Date: Fri, 27 Mar 2015 13:20:47 +0100
=== From: Henning Rogge <[email-masked]>
=== To: "Broderick, Don" <[email-masked]>
=== Cc: "[email-masked]" <[email-masked]>, Caleb Lo <[email-masked]>,        "Jack Shaio ([email-masked])" <[email-masked]>
=== Subject: Re: [manet] draft-shaio-manet-common-l3-interface
=== 
=== Hi,
=== 
=== I think before a document can become a MANET RFC it needs to be
=== adopted by the working group.
=== 
=== Henning Rogge
=== 
=== On Thu, Mar 26, 2015 at 7:14 PM, Broderick, Don <[email-masked]> wrote:
=== > We are submitting
=== > http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-interface/ to be
=== > an Experimental RFC. It describes an approach to overlay IP over MANET but
=== > does not specify a protocol; rather the focus is on an interface between IP
=== > and MANET that is local to one terminal. The draft also presents results of
=== > large scale simulations of this approach. Our intent is to show that it is
=== > not necessary to standardize the interface between these two layers by
=== > prescribing a new message exchange between them.
=== >
=== >
=== >
=== > This draft was submitted to the MANET working group for 12 months and we are
=== > now asking if it can be moved to Experimental RFC status, based on our
=== > understanding of RFC 2026 section 4.2.
=== >
=== >
=== >
=== > Thank You,
=== >
=== > Donald Broderick
=== >
=== > The MITRE Corporation
=== >
=== > 202 Burlington Road
=== >
=== > Bedford, MA   01730
=== >
=== >
=== > _______________________________________________
=== > manet mailing list
=== > [email-masked]
=== > https://www.ietf.org/mailman/listinfo/manet
=== >