Re: [manet] New DLEP extension drafts

[Rick Taylor <[e-mail]>]

Inline as usual...

On Tue, 2017-09-05 at 09:51 +0200, Henning Rogge wrote:
> Am 04.09.2017 um 23:46 schrieb Rick Taylor:
> > Ripostes inline...
> > > What is even the advantage moving "router to router"
> > > communication
> > > to DLEP?
> > 
> > The major advantage I can see is fast 'edge triggered' adjacency
> > formation.  This is one of the selling points of DLEP for Layer 3,
> > so
> > why not expose Layer 4+ triggers as well.  Given I work for a
> > company
> > whose vehicles move at some speed, being able to form an adjacency
> > between peer services fast is helpful.  If I have a transmission
> > window of 1 minute max, I don't want to spend the first 30 seconds
> > Hello'ing with every protocol that might want to find a peer over
> > the
> > possibly restricted/flakey link.
> 
> You could easily use the existing layer2/layer3 'edge trigger' to
> start
> a UDP (unicast?) based service discovery for the new neighbor. No
> need
> to relay the data over the radio.

Yes, I agree, you can, and I do.  My routers will use DLEP events to
kick off a proprietary service discovery protocol between peers, and it
works beautifully.  However, it only works between my routers.  When a
peer is a Cisco, or an OpenWRT router, or whatever, then I have to fall
back to per-service probing.

I also know Cisco have previously played with embedding
service/capability data in EIGRP and using that in a similar way.

In all honesty, there is nothing big or clever about my service
discovery (it looks a lot like DSA, but with some session maintenance
messages).  When I was last reviewing the design for this it occurred
to me that it would make more sense to re-use the existing DLEP session
to carry this extra information, hence the DSA extension draft.

> 
> > > I can see the point of IP address propagation, especially on
> > > radios
> > > without multicast support. Without the unicast IP of the other
> > > side
> > > you cannot reach it.
> > > 
> > > But for supporting services putting it into DLEP is no advantage
> > > at
> > > all... you could easily just let the routers exchange the
> > > information directly.
> > 
> > I'm not suggesting moving/wrapping the service protocol in DLEP,
> > just
> > the knowledge that it's even worth trying to begin it.
> > > > If, as you say, "Even if the only service announced is mDNS,
> > > > and
> > > > mDNS is then used..." - why not *assume* that mDNS is present,
> > > > and go for it?
> > 
> > Haha... you know the answer as well as I do.  Someone will say they
> > don't use mDNS, they use what they consider better.  I couldn't be
> > so
> > bold as to suggest mDNS as a one size fits all solution.  This is
> > the
> > IETF!
> 
> Which is another reason not to put another solution for the same
> problem
> into DLEP, because people will not be happy with it anyways.

Fair point, but one doesn't have to support individual extensions, as
it's already optional.

> 
> > > > I've gone back & forth over the notion of service
> > > > announcements.
> > > > I think we're going to get significant pushback from the IETF
> > > > that there are already multiple protocols for service
> > > > announcement, and we're just re-inventing the wheel for the
> > > > 47th
> > > > time.
> > > 
> > > That too.
> > > 
> > 
> > I quite agree... I'm expecting legitimate push-back, I just feel
> > there is a missing piece here.  This is why my first pass was
> > simply
> > to announce tuples of [service, address, port] and not much
> > else.  It
> > should be enough to bootstrap whatever service you're running.
> > Actually what's described in DSA is very close to DNS SRV records,
> > hence the text form.
> 
> DLEP trigger for an existing DNS-based service discovery?

The whole of DSA might boil down to a single Data Item for this...

Actually I need to re-read mDNS to check if it will work in the kinds
of ad-hoc peer-to-peer modes we're discussing here, I have a worry that
it is built around a very homenet/client-server view of the network.

> 
> > One reason why core DLEP is not quite good enough might be that a
> > remote router might only be running a given service (say NTP) bound
> > to a loopback interface.
> 
> Are we talking about a node with routing or just a layer-2 endpoint?

I don't actually care, and I'm keen not to make this distinction.

> 
> > The DLEP Dest_Up may include the loopback
> > address as part of the IP address data items in the message, but
> > any
> > potential peer is going to have to probe every reported address
> > until
> > it finds the one that works, if any.
> > 
> > I keep picking NTP as the example service as it is an a-priori
> > configured protocol (unless there is an exciting NTP peer discovery
> > protocol I don't know about).  For services that have a discovery
> > protocol (e.g. OLSRv2), DSA is overkill, for static I feel it's
> > less
> > clear cut.
> 
> Routing must do its own discovery because it has to work before Ip
> routing is finished. ;)

Agreed, routing services were a bad example.

> 
> As soon as we have normal connectivity,
> 
> > Where additional config data beyond [service,address,port] might be
> > useful is for something like BGP AS number, but the counter-
> > argument
> > could be that you only need to advertise 1 tuple: [NETCONF,addr]
> > ;-)
> > 
> > I think any later revision will have to be liberally sprinkled with
> > text that warns that this extension is only for bootstrapping, not
> > for protocol parameter negotiation.
> 
> Which sounds like a hint that we still have to work on the concept.

Oh yes, I quite agree.  This is definitely not finished!

> 
> I see the "necessary" use-case for announcing IPs...
> radios/modems/networks that can not multicast/broadcast. They are a
> pain, but they exist... you need the IP of the other side to do
> "automatic discovery".
> 
> In fact, NHDP works quite fine over networks like this if you know
> the
> IPs of the other router.

Yes, and this is because NHDP was designed for MANETs by people who
understood the problem space.  There are however Layer4+ protocols that
are really useful in MANETs but were designed for fixed networks, e.g.
NTP, XMPP and most network overlays.  Any protocol that features the
immortal phrase "A TCP connection is made to each configured peer" is a
prime candidate.

> 
> > > > Having said that, I'm interested in being able to transmit
> > > > *some* additional information at Destination Up. For example,
> > > > consider a military deployment (I only use it because I've seen
> > > > this implemented, and can articulate the problem). There are
> > > > some
> > > > vehicles that are equipped with LoS mesh radios; and there are
> > > > also a few equipped with the mesh radios and a satellite
> > > > terminal/dish for reach back. I'd like some way for one of the
> > > > satellite-equipped "reach back guys" to be able to communicate
> > > > via DLEP on the LoS mesh radio that "I have reach-back
> > > > capability". To me, this information would fold into things
> > > > like
> > > 
> > > selection of a "Designated Router"
> > > > for OSPF, or an MPR for OLSR. This is something of a
> > > > "capabilities" TLV, where a "capability" (e.g., the reach back)
> > > > is not necessarily a part of the radio being used.
> 
> Both OSPF and OLSR(v2) already work fine without any service
> discovery... you can make them work faster by using "triggered
> Hello/TC
> messages", e.g. triggered by Destination Up messages of DLEP.

An interesting 'service' might be announcing IPSec tunnel endpoint
capability, rather than relying on NHRP (which requires a hub-spoke
model to bootstrap).  A kind of "I do IKE!" service announcement
allowing DMVPN construction without requiring a hub.  I know a lot of
modems 'do' transport security in some unspecified way, but not all of
them, and sometimes a consistent security policy across multiple
bearers is desirable.  As I've said before this is all optional.

> 
> My problem with this "use DLEP as transparent router to router
> communication" is that it breaks a major design goal of DLEP that I
> (we?) told a lot of people... the advantage of DLEP is that it does
> not
> introduce additional over-the-air traffic. The radio exports
> everything
> it knows and everything it can already do for you.

Yes, DLEP doesn't mandate any extra over the air comms, but if you (as
a radio vendor) allow DLEP to squeeze some extra data into your control
channel, then you can support some really useful extensions.  It's the
difference between MUST and MAY.

I suppose I'm trying to address the problem that the link just
announced by DLEP may be an extremely precious resource, and anything
DLEP can do to allow attached devices to make best use the link is a
good thing.

> > > > Another
> > > > "capability" would be to somehow announce "I'm plugged into a
> > > > reliable, 24/7 power source, so battery consumption isn't a
> > > > problem". In both of these cases, they enhance the node's
> > > > ability
> > > > and willingness to act as a traffic relay.
> > 
> > I share your use-cases, but I think you're in danger of conflating
> > local radio capability (what Henning was desiring) and remote
> > router
> > capability, but that's not to say I don't like the idea of both,
> > I'm
> > just trying to keep the scope manageable.
> > > Capability might also include "need unicast traffic for datarate
> > > selection".
> > 
> > That's a good capability, but I consider that more local not
> > remote.
> > I think "You need to use the link before the CDR goes above 0" is
> > something the local modem should know.
> 
> Yes, it is.
> 
> A "I cannot to multicast/broadcast" capability flag would also be a
> major help for some radios.

This can be done by rejecting a Destination Announce for a multicast
MAC.  But it's not instantly obvious that this can be done.

> 
> > Let's keep the conversation going, I think there is some value in
> > here somewhere!
> 
> I think so too.

Do you fancy starting a 'local modem capabilities announcement' draft?

Cheers,

Rick