Re: [manet] New DLEP extension drafts

[Rick Taylor <[e-mail]>]

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

> -----Original Message-----
> From: manet [mailto:[e-mail]] On Behalf Of Henning Rogge
> Sent: 01 September 2017 07:18
> To: [e-mail]
> 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