Re: [manet] New DLEP extension drafts

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:
> 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.
> 
> > 
> > 
> > > 
> > > > 
> > > > 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.
> 
> > 
> > 
> > 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.
> 
> 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?
> 
> Cheers,
> 
> Rick
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet