Re: [manet] New DLEP extension drafts

[Rick Taylor <[e-mail]>]

Ripostes inline...

> -----Original Message-----
> From: Henning Rogge [mailto:[e-mail]]
> Sent: 02 September 2017 21:54
> To: Stan Ratliff
> Cc: Rick Taylor; [e-mail]
> Subject: Re: [manet] New DLEP extension drafts
> 
> On Sat, Sep 2, 2017 at 10:17 PM, Stan Ratliff <[e-mail]> wrote:
> > My 2-cents worth...
> >
> >
> > 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.
> 
> 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. 

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

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

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