Re: [arch-d] Development of Internet Protocol "Five Fields" (IP-FF): Presentation

[Alexey Eromenko <[e-mail]>]

Tony Li <[e-mail]>:

Routing is described in [IPFF-ADDRESSING] spec.



On Thu, Jan 7, 2016 at 8:48 PM, Bob Briscoe <[e-mail]> wrote:

> Alexy,
>
> I suspect you are most proud of the fact that you have produced a set of
> ideas that all work well together.
> But see inline...
>
> On 05/01/16 20:56, Joe Touch wrote:
>
> On 1/5/2016 10:14 AM, Tony Li wrote:
>
> On Jan 5, 2016, at 9:43 AM, Theodore V Faber <[e-mail]> <[e-mail]> wrote:
>
> Let us know when you’ve implemented something.
>
> … and when you’ve thought about the routing implications of your design.
>
> ...and when you have a plan for tech transition.
>
> It's very easy to redesign any protocol if you ignore the need to
> support legacy systems.
>
>
> *1. Deployability*
>
> ...I would argue that the value of each part of FF has to be assessed as
> if that part was separate from the rest, for the reason Joe gives...
> ...there is little mention or consideration of incremental deployability
> {note 1} of the whole system, let alone each of the parts (other than the
> NAT part).
>
> But even though the FF system is unlikely to ever be deployable as a
> whole, it might be possible to modify some of the individual ideas in FF to
> add incremental deployability, so that the most valuable ideas can become
> usable individually.
>
>
IPFF-Babysitter (new NAT) solves Deploy-ability problems (for desktops).
IPFF private servers will be useful in-house, and IPFF desktops can browse
IPv4 Internet.
IPFF Internet servers will obviously require new Internet core. (just like
IPv6 requires)



> *2. Private problem statement?*
>
> The biggest problem with FF is that you have been working on solving a set
> of problems that few would agree have been articulated as the real
> underlying problem that needs to be solved. The problem statement is the
> part that should be done in public, even if you do the design in private.
>
> * v6 address space too big - so what? it's more important to agree on any
> size, than to have the "right" size.
> * v6 addresses hard to transliterate, read etc    - so what? - just a
> tools problem
>
There are no tools for that. IPv6 is unusable in every way.


> * mobility without breaking transport - need to solve this without
> compromising other features like ability to keep ports private. A number of
> alternative ways already solve this: multipath TCP, or Teemu Koponen et
> al's "Resilient Connections for SSH and TLS," USENIX Annual Technical
> Conference
>

My "Mobile Protocol Stack" works with every Transport Protocol in theory,
although my paper describes "Mobile TCP" and "Mobile UDP".


> * ports at L3 or L4 - Just because ports can be useful at L3, doesn't mean
> they should be moved to L3. A better answer is "Design for Tussle", ie on
> the wire it needs to be possible to have ports hidden or not, and
> everything works (for some definition of "works") whichever way you choose.
> {note 2}
>

Ports were moved to layer 3 for fast firewalling and fast Flow-based
routing, the latter of which explained in detail. Doing some kind of Layer
3.5 shim will not solve those problems.


> * no ARP - looks useful to replace with an algo. The question then becomes
> how do you introduce new MAC layer addressing schemes in future - ARP is
> agnostic to the internal semantics of a L2 address, but an algo cannot be.
>

Right. LARA is specified for Ethernet. Other data links will require other
specifications, and I don't mind if some are still using ARP. (Frame-Relay?)


> * stronger L4 checksums - useful, but needs to be considered as part of
> the bigger problem of L4 extensibility currently being addressed.
> * IP-VRF - again the problem here is the extensibility architecture of
> existing IP. We can't keep changing to a completely new Internet Protocol
> every time we realise we missed an extension we should have thought of.
> Well it would be worth the change if the new Internet Protocol had a
> brilliant extensibility architecture...
>
* ...which raises a good question...
>
Where's your extensibility architecture? Should be the first design
> decision, not the last.
>
>
You are right.

I'm working hard to improve IP-FF extensibility (both L3 [IP options] and
L4, [future Transports]), and also working on new Multicast solution.

Thanks for link to SNA: Sourceless Network Architecture; I need to study
that one.

>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>


-- 
-Alexey Eromenko "Technologov"