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

From: JS <[email-masked]>
Date: Fri, 3 Apr 2015 12:32:09 -0700

Christopher,

We explained both in our draft (Intro and section 3) that the purpose of CL3 is to select intelligently,
from all potential endpoints in the MANET, a "good" set of OSPF peers to present to its attached router.

The selection is based on whatever algorithm the CL3 node is using; coordination among different CL3
nodes is not required nor do they have to use the same algorithm.

This avoids presenting all potential OSPF peers to the router, as would happen in the case you describe
below. The advantage is that MANET nodes can be expected to have intermittent connectivity as they move,
so if all of them were OSPF peers, we would see OSPF adjacencies constantly being brought up and then
brought down. An intermediate algorithm operating before the router can filter out potential nodes on the
MANET that have show recent intermittent connectivity; we cannot expect most commercial IP routers to
have implemented protocols from the MANET WG or to supplement them with algorithms like these.

Our draft presents results with and without such an algorithm; without means all potential OSPF peers
are presented to the router, as would happen in the case you described.

The second key point is that CL3 adapts to work with any typical IP router and with any MANET. This is
important because very few commercial IP router models have implemented DLEP and because many
MANETs are in use that have not been defined by the MANET working group. We defined a mechanism
that adapts to work with both of these and described results using a publicly-released MANET (OLSRv1).

thanks,
     Jack Shaio

 Date: Wed, 1 Apr 2015 11:37:25 +0000
 From: "Dearlove, Christopher (UK)" <[email-masked]>

 Subject: Re: [manet] draft-shaio-manet-common-l3-interface
 Message-ID:
     <[email-masked]>
 Content-Type: text/plain; charset="us-ascii"
 
 Jack Shaio
 > 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.
 
 That's mixing up two things.
 
 The Local Attached Network Set is in input into OLSRv2 from
 its environment. OLSRv2's use for it is to propagate it
 across the network to inform other routers' Attached Network
 Sets (no Local) which in turn inform the Routing Set. OLSRv2
 supplies the Routing Set to its environment which,
 typically, uses it to set the local IP routing table. What
 matters about other routers across the MANET for simple
 routing is in the Routing Set. (The Attached Network Set may
 be accessible e.g. using a MIB.)
 
 So IP at the router knows about other routers across the
 network in terms of how to route to them. It even has metric
 information about them, in OLSRv2 terms (which includes a
 term specific to the attached network). It doesn't
 (unmodified) know whether an attached network is just hosts,
 or another network running OSPF or any other alternative.
 The assumed model is that each network takes care of its
 only internal details, network A does not need the internal
 details of network B. That's the basic Internet approach.
 The question that I don't think is clear to anyone here is
 your use case and why it differs from that model.