W3C home > Mailing lists > Public > public-interledger@w3.org > March 2016

Non-source routing (was "failures during the preparation phase")

From: Evan Schwartz <evan@ripple.com>
Date: Wed, 16 Mar 2016 12:15:44 -0700
Message-ID: <CAONA2jVZ0XNdf+2xBDdp7TMoQurpVDDW2CaqjZ1WJJ6GouqzkA@mail.gmail.com>
To: Interledger Community Group <public-interledger@w3.org>
Cc: Jehan Tremback <jehan.tremback@gmail.com>, Xavier Vas <xavier@tr80.com>, mark.germain@germain.consulting
Thanks all for the input. I'm convinced that it would make sense to at
least support a variety of pathfinding approaches and you all might be
right that non-source routing will end up being the best option.

Looking at the original Internet Protocol RFC
<https://www.ietf.org/rfc/rfc791.txt> it's actually interesting to note
that there are fields that allow the source to specify routing information
(look for the "Loose Source and Record Route" and "Strict Source and Record
Route" options).

Regarding what we called the proposal phase, that's already being removed
from the reference implementation (see five-bells-sender/pull/37
<https://github.com/interledger/five-bells-sender/pull/37> and
five-bells-sender/pull/43
<https://github.com/interledger/five-bells-sender/pull/43>). Now, the
sender will still do the pathfinding but it includes the path in the memo
field as described in this Nested Transfers spec
<https://docs.google.com/document/d/1zTLQLBx0p6-Ds9Ki8nCaVBdXUK4mbJZDQOaz83n6VY8>
.

Supporting non-source-based routing protocols would require additions to
the connector. Anybody want to weigh in on what the best approach for this
would be?

-- 
Evan Schwartz | Software Architect | Ripple
[image: ripple.com] <http://ripple.com>
Received on Wednesday, 16 March 2016 19:16:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 March 2016 19:16:35 UTC