Re: [manet] New DLEP extension drafts

[Stan Ratliff <[e-mail]>]

My 2-cents worth...


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

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


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

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



>
> >
> > 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
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>