[arch-d] Help

[Brian Brown <[e-mail]>]

Unsubscribe 



Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: [e-mail] </div><div>Date:01-08-2016  9:14 AM  (GMT-05:00) </div><div>To: [e-mail] </div><div>Subject: Architecture-discuss Digest, Vol 30, Issue 7 </div><div>
</div>Send Architecture-discuss mailing list submissions to
[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/architecture-discuss
or, via email, send a message with subject or body 'help' to
[e-mail]

You can reach the person managing the list at
[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Architecture-discuss digest..."


Today's Topics:

   1. Re: Architecture-discuss Digest, Vol 30, Issue 6 (Brian Brown)


----------------------------------------------------------------------

Message: 1
Date: Fri, 08 Jan 2016 09:14:30 -0500
From: Brian Brown <[e-mail]>
To: [e-mail]
Subject: Re: [arch-d] Architecture-discuss Digest, Vol 30, Issue 6
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"

Unsubscribe?



Sent from Samsung Mobile

<div>-------- Original message --------</div><div>From: [e-mail] </div><div>Date:01-08-2016  9:02 AM  (GMT-05:00) </div><div>To: [e-mail] </div><div>Subject: Architecture-discuss Digest, Vol 30, Issue 6 </div><div>
</div>Send Architecture-discuss mailing list submissions to
[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/architecture-discuss
or, via email, send a message with subject or body 'help' to
[e-mail]

You can reach the person managing the list at
[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Architecture-discuss digest..."


Today's Topics:

   1. Re: Development of Internet Protocol "Five Fields" (IP-FF):
      Presentation (Alexey Eromenko)
   2. IPv6 (address) usability and tools [Re: Development of
      Internet Protocol "Five Fields"] (IP-FF): Presentation (Simon Leinen)
   3. On the value of ILNP and SNA - is it even needed ?
      (Alexey Eromenko)
   4. Re: IPv6 (address) usability and tools [Re: Development of
      Internet Protocol "Five Fields"] (IP-FF): Presentation
      (Alexey Eromenko)


----------------------------------------------------------------------

Message: 1
Date: Fri, 8 Jan 2016 04:53:13 +0200
From: Alexey Eromenko <[e-mail]>
To: Bob Briscoe <[e-mail]>
Cc: [e-mail]
Subject: Re: [arch-d] Development of Internet Protocol "Five Fields"
(IP-FF): Presentation
Message-ID:
<CAOJ6w=[e-mail]>
Content-Type: text/plain; charset="utf-8"

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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/attachments/20160108/e2d24a1a/attachment.html>

------------------------------

Message: 2
Date: Fri, 8 Jan 2016 14:48:58 +0100
From: Simon Leinen <[e-mail]>
To: Alexey Eromenko <[e-mail]>
Cc: [e-mail]
Subject: [arch-d] IPv6 (address) usability and tools [Re: Development
of Internet Protocol "Five Fields"] (IP-FF): Presentation
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1

Alexey Eromenko writes:
> On Thu, Jan 7, 2016 at 8:48 PM, Bob Briscoe <[e-mail]> wrote:
>     * 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.

No, obviously not in *every* way, since it is being used in the real world.

However, I agree there *are* usability problems, and I found Bob Briscoe's
"so what? - just a tools problem" a bit cavalier.  (I should say that this
was the only part of Bob's message I have a problem with - overall I find
it extremely well thought through and on the topic.)

Of course people can and should use hostnames and not bother with these
addresses at all.  Most end users already do.  But still, developers and
operators often use (and, worse, sometimes force other users to use)
literal IP addresses.  In some cases this is hard to avoid (e.g. an
operator debugging a routing issue and looking at prefixes in the routing
or BGP table), in other cases I don't quite understand myself why people
use literal addresses when they should be using hostnames.

Personally I don't think this is reason enough to throw out IPv6.

But we would do well to take this usability problem more seriously.  I'm
optimistic that much of this could be addressed, and yes, tools (including
better UIs) will play a major role.

So it may well be a tooling problem... but "JUST a tools problem"?
If tools were an easy problem, shouldn't we have solved it by now?

I'm not saying that no tools exist (for example, hostnames exist), but
there's definitely still a gap in that people find IPv6 hard to use -
maybe the tools are there but for some reason they aren't used.

Wouldn't (y)our time be better spent working on this: Trying to make the
fact that IPv6 addresses are "hard to transliterate, read etc" (with which
I agree) less relevant for those who currently feel the pain?

And who is it who's feeling that pain? I'm guessing that many people who
have to configure firewalls and access lists are in that group today.
Who else?
-- 
Simon.



------------------------------

Message: 3
Date: Fri, 8 Jan 2016 15:52:11 +0200
From: Alexey Eromenko <[e-mail]>
To: [e-mail]
Subject: [arch-d] On the value of ILNP and SNA - is it even needed ?
Message-ID:
<CAOJ6w=[e-mail]>
Content-Type: text/plain; charset="utf-8"

Identifier-Locator Network Protocol; ILNP, as defined in RFCs 6740-48

SNA: Sourceless Network Architecture
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-849.pdf

I have read those papers.
The idea looks an interesting one, but why should those protocols use a
bigger Layer 3 packet, and send "Identifier" in every packet?

Isn't it better and easier to just do all of this at Layer 4, like SCTP or
Multipath TCP do ?
The advantage is that this reduces overhead, because at Transport Layer
those IDs are transferred only during session establishment phase, as
opposed to every packet.
It looks to me, that the whole "Identifier" idea is really a "Transport
Layer" concept (with end-to-end meaning).

-- 
-Alexey Eromenko "Technologov"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/attachments/20160108/72aafbe4/attachment.html>

------------------------------

Message: 4
Date: Fri, 8 Jan 2016 16:01:43 +0200
From: Alexey Eromenko <[e-mail]>
To: Simon Leinen <[e-mail]>
Cc: [e-mail]
Subject: Re: [arch-d] IPv6 (address) usability and tools [Re:
Development of Internet Protocol "Five Fields"] (IP-FF): Presentation
Message-ID:
<CAOJ6w=[e-mail]>
Content-Type: text/plain; charset="utf-8"

>
>
> Wouldn't (y)our time be better spent working on this: Trying to make the
> fact that IPv6 addresses are "hard to transliterate, read etc" (with which

I agree) less relevant for those who currently feel the pain?
>
> I don't see a solution to this problem.


> And who is it who's feeling that pain? I'm guessing that many people who
> have to configure firewalls and access lists are in that group today.
> Who else?
>

Debugging stuff is slow with IPv6. This includes quick comparison of
addresses, of host portion and of network portion of two (or more) source
or destination addresses.
In IPv4, it is possible to visualize (average sized, corporate) network in
human brain.
Network consists not only of nodes (which DNS can fix), but also of address
ranges, multicast addresses, subnets, etc...

-- 
-Alexey Eromenko "Technologov"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/attachments/20160108/43b3ac66/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Architecture-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/architecture-discuss


------------------------------

End of Architecture-discuss Digest, Vol 30, Issue 6
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/attachments/20160108/eb46e9ea/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Architecture-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/architecture-discuss


------------------------------

End of Architecture-discuss Digest, Vol 30, Issue 7
***************************************************