Subject: Re: [manet] New DLEP extension drafts

From: Rick Taylor <[email-masked]>
Date: Sat, 2 Sep 2017 09:20:43 +0000

Thanks for the comments, Henning, replies inline...

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
> Sent: 01 September 2017 07:18
> To: [email-masked]
> Subject: Re: [manet] New DLEP extension drafts
> 
> Am 31.08.2017 um 11:22 schrieb Rick Taylor:
> > Hi All,
> 
> Okay, time to get the ball rolling for service discovery.

Excellent!  This draft was first started 2 years ago, so bits of it are definitely unclear/out-of-date.

> 
> I must admit I am not that happy with the draft in its current form.
> 
> First reason is the that the draft focuses on announcing router services to
> other routers. This makes it practically necessary to add an over the air
> component to DLEP. I thought we agreed that one of the design goals of
> DLEP was only to communicate between the local radio and the local router,
> exchanging already existing local knowledge.

Okay... I'll answer this point in parts:
a) I remember the early DLEP discussions agreed that the DLEP protocol would not define how or what was sent over the air, but did require that something was sent in order to function.  The assumption being that nearly all radio systems have some kind of control plane.  DLEP only defines the 'how and what format' of the local communication.  

b) Yes, this extension does require some data to be transmitted over the air (it does not specify how or in what format, just like DLEP), but as an extension, it is optional.

> 
> I think DLEP is the wrong protocol to exchange knowledge between routers
> and I am sure the IETF already has protocols for the two routers exchanging
> service information.

Yes, the IETF has a plethora of protocols for peers of protocol X to exchange information with other peers, but all these protocols requires one of the following mechanisms: polling, broadcast announcing, or static configuration.

For example: A local router has an NTP service that wants to find some upstream peers (or whatever they're called in NTP-speak).  Whenever it receives a DLEP Dest_Up, it has to attempt an NTP session just in case the remote router is a valid peer.  This is Hello again, at Layer 4+, rather than Layer 3. 

If DLEP can provide layer 4+ information to avoid Layer 4+ Hellos, just as it provides Layer 3 information to avoid Layer 3 Hellos, then I see this as useful.  Even if the only service announced is mDNS, and mDNS is then used for all other service discovery, this is an improvement.

> 
> What I had expected in this draft was a way for the radio to announce its
> LOCAL services to the router, e.g. a SIP endpoint to connect your routers
> VOIP network to a locally existing "push to talk" voice channel.
> Other examples would be to announce the existence of HTTP ip/port
> (configuration GUI) or a netconf/ssh port.

Ah yes...  This is also very useful, but I would say it was a different extension.  However, there has been some general consensus that DLEP is not a management protocol, so one would have to be careful with what is described.  I'm happy to help/review/comment on any ideas you have.

As an aside, you are the second person who has conflated DSA with what you describe - perhaps I need to revisit some of the text!

> 
> The second (minor) issue I have with the draft is the text string used to
> identify the service. It feels a bit "out of place" in all the binary encoded data
> DLEP transfers.

Good point.  The textual data  is a bit of a mismatch with the rest of DLEP, but I couldn't (at the time) think of an alternative format generic enough to carry a loose bundle of layer 4+ protocol information.  However, what do people think about using something CBOR encoded?  It's binary and more concise and IETF-ish, which means that radio vendors could consider just shoveling it over the air, or they could proxy/compress fairly simply.  I will have a play around to see if it fits better.

Thanks for the feedback,

Rick

---

From: Stan Ratliff <[email-masked]>
Date: Sat, 2 Sep 2017 16:17:28 -0400

My 2-cents worth...

On Sat, Sep 2, 2017 at 5:20 AM, Rick Taylor <[email-masked]>
wrote:

> a) I remember the early DLEP discussions agreed that the DLEP protocol
> would not define how or what was sent over the air, but did require that
> something was sent in order to function.  The assumption being that nearly
> all radio systems have some kind of control plane.  DLEP only defines the
> 'how and what format' of the local communication.
>
> b) Yes, this extension does require some data to be transmitted over the
> air (it does not specify how or in what format, just like DLEP), but as an
> extension, it is optional.
>
>
I agree with Rick here - this is pretty much like the announcement of
Layer-3 addresses and subnets. If an implementation is going to support
that, some OTA transmission is implied, and required.

> Yes, the IETF has a plethora of protocols for peers of protocol X to
> exchange information with other peers, but all these protocols requires one
> of the following mechanisms: polling, broadcast announcing, or static
> configuration.
>
> For example: A local router has an NTP service that wants to find some
> upstream peers (or whatever they're called in NTP-speak).  Whenever it
> receives a DLEP Dest_Up, it has to attempt an NTP session just in case the
> remote router is a valid peer.  This is Hello again, at Layer 4+, rather
> than Layer 3.
>
> If DLEP can provide layer 4+ information to avoid Layer 4+ Hellos, just as
> it provides Layer 3 information to avoid Layer 3 Hellos, then I see this as
> useful.  Even if the only service announced is mDNS, and mDNS is then used
> for all other service discovery, this is an improvement.
>

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?

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.

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

Regards,
Stan

> Ah yes...  This is also very useful, but I would say it was a different
> extension.  However, there has been some general consensus that DLEP is not
> a management protocol, so one would have to be careful with what is
> described.  I'm happy to help/review/comment on any ideas you have.
>
> As an aside, you are the second person who has conflated DSA with what you
> describe - perhaps I need to revisit some of the text!
>
> >
> Good point.  The textual data  is a bit of a mismatch with the rest of
> DLEP, but I couldn't (at the time) think of an alternative format generic
> enough to carry a loose bundle of layer 4+ protocol information.  However,
> what do people think about using something CBOR encoded?  It's binary and
> more concise and IETF-ish, which means that radio vendors could consider
> just shoveling it over the air, or they could proxy/compress fairly
> simply.  I will have a play around to see if it fits better.
>
> Thanks for the feedback,
>
> Rick
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Henning Rogge <[email-masked]>
Date: Sat, 2 Sep 2017 22:54:21 +0200

> that, some OTA transmission is implied, and required.

What is even the advantage moving "router to router" communication to DLEP?

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.

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

> 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
> where a "capability" (e.g., the reach back) is not necessarily a part of the
> radio being used. 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.

Capability might also include "need unicast traffic for datarate selection".

Henning

---

From: Rick Taylor <[email-masked]>
Date: Mon, 4 Sep 2017 21:46:54 +0000

Ripostes inline...

> From: Henning Rogge [mailto:[email-masked]]
> Sent: 02 September 2017 21:54
> To: Stan Ratliff
> Cc: Rick Taylor; [email-masked]
> > Layer-3 addresses and subnets. If an implementation is going to
> > support that, some OTA transmission is implied, and required.
> 

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. 

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

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

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

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.

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

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

Rick

---

From: Henning Rogge <[email-masked]>
Date: Tue, 5 Sep 2017 09:51:47 +0200

Am 04.09.2017 um 23:46 schrieb Rick Taylor:
> 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.

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

> 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

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 +49 228 50212-469
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Rick Taylor <[email-masked]>
Date: Tue, 5 Sep 2017 09:33:18 +0000

Inline as usual...

On Tue, 2017-09-05 at 09:51 +0200, Henning Rogge wrote:
> > > What is even the advantage moving "router to router"
> > > communication
> > > to DLEP?
> > 

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.

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

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

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

> Routing must do its own discovery because it has to work before Ip

Agreed, routing services were a bad example.

> Which sounds like a hint that we still have to work on the concept.

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

> In fact, NHDP works quite fine over networks like this if you know

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.

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

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

> 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

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

Cheers,

Rick

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 05 Sep 2017 09:27:35 -0700

Rick, Henning, et al,

Interesting discussion.  My comments are not leavened with
implementation experience....  But I agree with the comment that IETF
has solved, or tried to solve, similar problems many times before.

It appears to me that you have two problems and separation of them may
be a good idea:
 
1.  You have a data definition and standardization problem.  

2.  You have a communications problem.  

Suggest a focus on each separately, with the goal that the data items
can be used in several transmission means.  

On Tue, 2017-09-05 at 09:33 +0000, Rick Taylor wrote:
> > > formation.  This is one of the selling points of DLEP for Layer
> > > 3,
> > > so
> > > > But for supporting services putting it into DLEP is no
> > > > advantage
> > > > at
> > > don't use mDNS, they use what they consider better.  I couldn't
> > > be
> > > so
> > > > Capability might also include "need unicast traffic for
> > > > datarate
> > > > selection".

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 5 Sep 2017 12:54:09 -0400

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

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

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

> 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

---

From: Henning Rogge <[email-masked]>
Date: Fri, 8 Sep 2017 11:53:22 +0200

> one that encompasses both 'local' and 'remote' capabilities. I think the

I am currently upgrading my DLEP implementation to process "boolean"
values in TLVs... I want to do some tests with the "radio attributes"
before I start the draft.

At the moment I have three radio (interface) attributes, but no "neighbor" ones:

* MCS-by-unicast (radio needs unicast traffic to destination to
determine link speed)
* RX-unicast-only (radio will only receive unicast, but no multicast/broadcast)
* TX-unicast-only (radio cannot transmit multicast/broadcast)

Henning