Re: [manet] New DLEP extension drafts

[Stan Ratliff <[e-mail]>]

On Tue, Sep 5, 2017 at 5:33 AM, Rick Taylor <[e-mail]>
wrote:

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

This looks like more of an implementation problem to me - one that doesn't
actually require an interoperability spec. There's more than 1 way to
leverage existing hooks (up to and including using some of the "private
use" TLVs) to transmit the information you're looking for.

Right now, from your description, I get the mental image of an Airbus A380
arbitrarily connecting up to..... WiFi at Starbucks? One of Henning's
roof-top nodes? And then scrounging around for services. It also seems like
there's a potential for a hacker exploit - if some bad actor gets connected
to one of these radios, it would get a list of services available, which
leads to the attacker knowing how to disrupt the service.


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

I still want to push for some of the characteristics I listed earlier. And
to avoid confusion, I'm looking at them as remote characteristics. If I
have a vehicle with an LoS radio, and I connect to another vehicle that has
LoS and Satcom, I want to know sooner rather than later. I also want to
know if my new connection partner is actually a "base station" (with good
uninterruptible power), because that could influence my routing decisions.
I also like the notion of "I do IKE!"... I'm not completely sure, but I
don't think there are any IPSec/IKE discovery protocols.


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

+1 with Rick here. Yes, I've told people that no OTA traffic is
*specified*. And for the base DLEP, that will always be the case. But
again, if a radio vendor wants to exploit the Layer 3 addressing, then
additional OTA is required. If a vendor wanted to support this extension,
more OTA transmission is required. Since the extensions are (more or less)
a-la-carte, then you pick & choose as you see fit.


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

I'd prefer (and am volunteering to help) making it a "capabilities draft" -
one that encompasses both 'local' and 'remote' capabilities. I think the
scope is manageable,

Regards,
Stan