Re: [manet] New DLEP extension drafts

[Henning Rogge <[e-mail]>]

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.

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

>>> 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?

> 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?

> 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. ;)

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.

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.

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

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.

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

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

I think so too.

Henning

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Zanderstrasse 5, 53177 Bonn, Germany
Telefon [phone]
mailto:[e-mail] http://www.fkie.fraunhofer.de