Subject: Re: [rrg] Last call: Design goals

From: [email-masked]
Date: Wed, 27 Oct 2010 04:44:29 EDT

In einer eMail vom 26.10.2010 20:40:46 Westeuropäische Sommerzeit schreibt  
[email-masked]:

I was  also a little bit shocked - since I have proposed hIPv4  -when  I
noticed that hierarchical routing is a bad choice...
You should see TARA's advantages wrt hipv4. As routing occurs based on the  
dest. TARA-locator, the dest address may be what so ever: IPv4, IPv6,  HIP

But  after studying a bunch of Compact Routing papers I discovered that
when CR  researchers are discussing hierarchical routing they are
actually  discussing CIDR, i.e. routing tables are kept under control
by aggregating  and summarizing prefixes - and a global flat address
space is used. With  this concept there will be stretch issues, the
more compact RT the the more  likely it is to have a high stretch value
for a session. If I got it all  wrong I ask kindly the CR researchers
to correct me, thanks.

Think  this is not the hierarchical routing TARA  is proposing, think
TARA  falls into Landmark Routing category -there are papers available
on-line  and I also found one  draft
http://tools.ietf.org/html/draft-ietf-manet-lanmar-05:

Well, I am not a friend of DV :-)
 
Heiner

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 28 Oct 2010 09:59:23 +0300

> dest. TARA-locator, the dest address may be what so ever: IPv4, IPv6, HIP
Hi Heiner,

I see the advantages but I think the routing protocol is not the issue
here - IMHO, it is the old fashioned transport protocol lacking a
session layer mechanisms that is causing the pollution at the DFZ. So
one approach is to
a) add a session layer mechanism (such as HIP, ILNP, NBS) to the
current transport protocols
b) the routing architecture is changed slightly so that it better
serves the needs of  multipath transport protocols, used with or
without HIP, ILNP, NBS mechanisms
c) LISP is also creating a sort of session layer, but is handled by
the network devices instead of the endpoints - it is a good starting
point (and needed) since it will speed up the migration phase - but
sooner or later the endpoints' stack  will be upgraded.

Note that this approach doesn't exclude an upgrade of the routing
protocol either - an upgrade can be carried out if there is incentives
for it.

IMHO, the root cause for our problems is the lack of a session layer
in the TCP/IP stack

Patrick

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 29 Oct 2010 21:53:55 +0900

Hi, Patrick,

I'd agree with your session layer argument. The first thing the IETF should
acknowledge and have to do is to add the session layer to the current
Internet architecture.

All other patch works can be stalled before we're done with the session
layer.

Is there any champion who could bring this issue to the full awareness and
acceptance by the IETF?

On Thu, Oct 28, 2010 at 3:59 PM, Patrick Frejborg <[email-masked]>wrote:

> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

-- 
DY

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 29 Oct 2010 19:22:02 +0300

Hi Dy,

I think the session layer thing is already happening, at least at the
research level - it seems that separating identifier and locator is
just another wording for adding a session layer to the stack.
RPC is considered to be defined at the session layer - when updating a
mapping database without the end user commanding it to update or when
piggybacking existing transport protocols to update locator, aren't
these typical RPC stylish actions?

Have a look on all proposals at RRG report, include also HIP - every
proposal have some RPC stylish actions that are executed at a certain
situation.

It is interesting though, that the lack of a session layer generates
that much stress on the routing system.

Patrick

---

From: Tony Li <[email-masked]>
Date: Fri, 29 Oct 2010 10:02:24 -0700

> proposal have some RPC stylish actions that are executed at a certain

I suggest you also look at multi-path TCP, which is very much akin to establishing a session layer.

> that much stress on the routing system.

When there is a bug (or complete void) in one layer of the system, then the adjacent layers will be stressed to compensate, as the net need will not evaporate.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 30 Oct 2010 10:00:16 +0900

Hi, Patrick,

Yes, a lot of LIS solutions as well as MPTCP and SCTP can be regarded as
session-like solutions.

But, I'd like to see a more firm and precise definition of a 'legal' session
layer adopted so that each proposals have to cook their own versions of
session-like functionality.

If a more rigorous session layer should be introduced, much of the works we
see now could be saved and people could concentrate more on more concrete
and deeper topics at hand.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Sat, 30 Oct 2010 10:01:22 +0900

so that each proposals DON'T have to cook

On Sat, Oct 30, 2010 at 10:00 AM, Dae Young KIM <[email-masked]> wrote:

> But, I'd like to see a more firm and precise definition of a 'legal'
> session layer adopted so that each proposals have to cook their own versions
> of session-like functionality.
>

-- 
DY