Re: [dtn-interest] [dtn] DTN static routing

ION also supports some primitive wild-carding of “dtn”-scheme endpoint IDs, and it additionally supports “ipn”-scheme static routing on the basis of “groups”, i.e., ranges of node numbers (which can nest).  Again, not ideal, but simple.

All of these mechanisms are implementation-specific, though.  I’m not yet clear on what standardization of static routing would look like.

Scott

From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Amy Alford
Sent: Monday, April 27, 2015 9:29 AM
To: Rick Taylor
Cc: dtn-interest@irtf.org; dtn@ietf.org
Subject: Re: [dtn-interest] [dtn] DTN static routing

Somebody correct me if I'm wrong here, but DTN2 allows wildcarding of eids.  This is not an ideal solution, but it does let you do grouping if you pick your eids appropriately.  I allow wildcarding in the rules tables for my internal version of BSP/SBSP for the same reason.
- Amy

On Mon, Apr 27, 2015 at 5:47 AM, Rick Taylor <rick@tropicalstormsoftware.com<mailto:rick@tropicalstormsoftware.com>> wrote:
Nabil, et al.

I have been mulling over the comments here about static routing, and
although I do agree with most of the comments along the lines of "Static
routes are just entries in a config file stating where to forward
bundles, dynamic routing is much harder/interesting", I do have a
question to those interested:

What do I put in my 'static routing table' for DTN? (Please note I am
not asking about a specific DTN implementation, this is a more general
question)

For IPv4, I would have an entry like: 10.10.0.0/16<http://10.10.0.0/16> via 10.1.1.1. But in
a DTN network, endpoints have string EIDs, with no concept of
subnetting.  I know there has been some work on intermediate node ids,
but I am not sure if the concept of 'subnetting' or grouping has been
explored.

So, yes, static routing seems like a simple topic, but unless every
implementation is happy to have a routing table containing a next hop
entry for every potentially routeable endpoint, and every dynamic
routing protocol is happy to exchange such potentially large sets of
routes, there has to be some work done in endpoint
aggregation/sub-netting, and this, I suggest, would be the most useful
output from any work on static routing in DTNs.

Hopefully this sounds like work that the IETF should tackle, rather than
the IRTF, it seeming more like an 'engineering' task to me.

Comments anyone?

Rick Taylor

On 23/04/15 22:25, Paulo Mendes wrote:
> Dear Nabil
>
> For me it makes no sense to talk about static routing when we are
> talking about networks that should be able exploit any forwarding
> opportunistic to overcome the problem of facing intermittent Internet
> connectivity. If you’re talking about Delay-tolerant Networks as in
> transmissions over long delay links, it makes no sense to talk about
> routing at all, since the problem is more a reliable transport problem.
> On the other hand if you are talking about Disruptive-tolerant Networks,
> then you need dynamic routing to overcome the intermittent connectivity,
> implementing a store-carry-forward algorithm.
>
> What chairs are you referring to? It should be from the new DTNWG and
> not from DTNRG. To the best of my knowledge there were presented at
> least two routing proposals to DTNRG. One is Prophet, which is now
> RFC6693, and the other is dLife
> (https://datatracker.ietf.org/doc/draft-moreira-dlife/ ). dLife last
> version is the fourth one. In the meantime, due to lack of feedback, we
> didn’t releases version 5 in the DTNRG. Currently dLife is being
> exploited in the European project UMOBILE (http://www.umobile-project.eu).
>
> Paulo
>
>> On 22 Apr 2015, at 15:18, Nabil Benamar <benamar73@gmail.com<mailto:benamar73@gmail.com>
>> <mailto:benamar73@gmail.com<mailto:benamar73@gmail.com>>> wrote:
>>
>> Hi All,
>>
>> Thank you for your insights and comments!
>> In fact, I have suggested during the DTN session in Dallas why not to
>> work on Dynamic routing instead of static routing. I got an answer
>> from the chairs that we don't know which routing protocols could be
>> considered !! And this is the reason that pushed John and I to
>> volunteer for static with the intention to provide a document (short
>> or detailed ) on the aspect !
>>
>> We do static routing in some cases even if Dynamic routing is
>> available. It's the case when one wants a stable path (through a
>> firewall) for the packets.
>>
>>
>> On Wed, Apr 22, 2015 at 1:53 PM, Ivancic, William D.
>> (GRC-LCA0)<william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov>
>> <mailto:william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov>>>wrote:
>>
>>     In line.
>>
>>     On 4/22/15 8:37 AM, "Greg Troxel" <gdt@ir.bbn.com<mailto:gdt@ir.bbn.com>
>>     <mailto:gdt@ir.bbn.com<mailto:gdt@ir.bbn.com>>> wrote:
>>
>>     >
>>     >"Ivancic, William D. (GRC-LCA0)" <william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov> <mailto:william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov>>>
>>     writes:
>>     >
>>     >> My understanding is Static mean hard wired.  You know what, where and
>>     >>when
>>     >> - similar to IP static routing where you know what and where.  No
>>     >>protocol
>>     >> is involved.  It is simply configuration.  You propagate the forwarding
>>     >> table.
>>     >>
>>     >> If I recall correctly, static routes usually get preference over dynamic
>>     >> routes.
>>     >
>>     >That makes sense.  I wonder then what it means to work on it
>>
>>     Me too.
>>
>>     >- to fix up
>>     >the reference implementation so that it has equivalents to "netstat -r",
>>     >"route add", etc.?  Or to write a document giving guidance to people
>>     >deciding which static routes to add?   Or ?
>>
>>
>>     I guess one thing would be to state whether or not the "when" is
>>     required.
>>
>>
>>     A second is to state whether "Static" or "Dynamic" has precedence.
>>     Actually, I prefer dynamic if it is available. If you are doing Static
>>     routing, it is because you do not have Dynamic routing. Static
>>     tends to
>>     get you in trouble.  We may think we know all, but we usually don't.
>>
>>     I think this should be a very short document.  Maybe it could
>>     actually be
>>     incorporated into 5050bis or some other document that states default
>>     assumptions.
>>
>>     Will
>>
>>
>>
>>
>> --
>>
>>
>>         Best Regards
>>
>>
>>
>>     *nabilbenamar.ipv6-lab.net<http://nabilbenamar.ipv6-lab.net> <http://nabilbenamar.ipv6-lab.net/>*
>>
>>
>> *
>> *
>> _______________________________________________
>> dtn-interest mailing list
>> dtn-interest@irtf.org<mailto:dtn-interest@irtf.org> <mailto:dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>>
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>
> Melhores Cumprimentos/Best Regards/Mit Freundlichen Gruessen
> Paulo Mendes
> ------------------------------------------------------------
> Paulo Mendes, Ph.D
> Vice-director of the Research Unit in Cognition and People
> Centric Computing (COPELABS)
> Director of the Ph.D program on Informatics - New Media and
> Pervasive Systems (NEMPS)
> Associated Professor at University Lusofona, Portugal
>
> http://copelabs.ulusofona.pt/~pmendes
> Tel.: +351 217 50 50 22<tel:%2B351%20217%2050%2050%2022>
>

_______________________________________________
dtn mailing list
dtn@ietf.org<mailto:dtn@ietf.org>
https://www.ietf.org/mailman/listinfo/dtn