[rrg] Inter-working of RRG proposals?

[Patrick Frejborg <[e-mail]>]

Hi all,

I have some thoughts that have bothered me for a longer time and I
would like to share my thoughts with this group. Since the ILNP
document are on their way to the review processes it might be an
appropriate time to put the thoughts on the table - another trigger is
the comment “Perhaps it's time to build LISP to ILNP inter-working and
roll”, http://www.ietf.org/mail-archive/web/ietf/current/msg72738.html
on the IETF discussion list. I believe it is doable.

But first things first:

Tony, many thanks for guiding me through the review processes! Without
your advices and patience I believe that my I-D never would have
reached RFC experimental status. Thank you, I really appreciate your
effort!

Here goes my brain dump:

Somewhere during the IRSG/IESG review process I stumbled on this paper:
ftp://ftp.cs.princeton.edu/techreports/2010/885.pdf
Read it with a conceptual view mindset; the technical details can be
build with tools from the RRG proposals (I discovered MPTCP on the
RRG, thus I consider it as part of the RRG “family”).

SCAFFOLD introduces a service identifier, that is, a session is
established from an endpoint to a service by a “late binding”– the
session is not directly established from an endpoint to another
endpoint, which we have proposed. Accessing endpoint-to-endpoint is so
retro at the moment; have a look on users’ behavior when you are e.g.
traveling by public transportation – this behavior, i.e. accessing
social media services, blogs, communication services etc. are
architectural requirements today that didn’t exist 15-20 years ago.
These requirements should be addressed somehow.

SCAFFOLD requires a transport protocol capable to move the session
from one resource to another resource in the data center – no need to
move the locator of the resource around in the data center, a service
identifier and a session identifier is used instead (no need for large
L2 nightmares in the DC). MPTCP is suitable for that. If other
transport protocols are used, ILNP can provide mobility services
between endpoints. MPTCP have restrictions due the size of the TCP
option, should MPTCP and ILNP co-operate so that e.g. nonce should
handle by ILNP when MPTCP move the session from one endpoint to
another?

In order to apply “late binding” a hierarchical addressing (locator)
scheme is needed. That can be found in hIPv4 (RFC 6306) but it
describes only a scheme for IPv4; the very same can be designed for
IPv6. The trick here is to create a locator scheme that has n times
larger address space than the data plane. Two times larger address
space should be enough for planet Tellus. And then we expose these
two-level locators to the endpoints so that they have alternative
paths to transport their data. It is like the road system; the drivers
are provided a road map so they can chose the most suitable path and
avoid road blocks/congestion points. The current architecture is like
the railroad system – the transport protocol of the endpoints has no
alternatives, it just gets on-board the train and hopes that railroad
operator do a proper job. And another bonus by having hierarchical
locators is a more scalable routing system in the DFZ.

How to get there? A CES solution is needed (LISP, IRON, Ivip), it will
definitely speed up the transition. But there are some challenges with
cache management and creating a tight dependency between control and
data plane at the xTRs could create other issues. You might get around
these challenges if e.g. LISP (which is the “root cause” behind hIPv4)
starts to integrate the other proposals discussed above. E.g. the
MPTCP WG is proposing a MPTCP proxy solution – is it possible to
integrate that with an ITR (and using hierarchical locator scheme with
a service identifier or a host identifier aka ILNP) to get around ETR
scaling issues at a content site by placing MPTCP proxies in front of
the servers? It is not a perfect solution; for sure there will be
scaling issues at the ITR, depending on how close it is located to the
initiators. But it is a very interesting transition mechanism.

I hope people can see the contours of a new architecture (for sure,
some will not prefer to see it all due to layer 10; religion). There
are unknown areas that needs to be explored but interesting use cases
can be found, that better addresses mobility and traffic engineering
between endpoints as well as accessing cloud based services than the
current architecture does.

The major building blocks can be found at RRG.

Happy Eastern!

Patrick