Subject: [RRG] Feasibility of transport based approaches?

From: <[email-masked]>
Date: Sun, 18 May 2008 19:07:57 +0300

Hello (if there is anybody? Has been quite silent recently.)

Recently we have been discussing (e.g. RRG process clarification
discussion) about how to classify different approaches.

> branching structure:
> 	- Map-n-encap
> 	- Translation
> 	- Transport

Is there a "Transport" based proposal on the table? I know that Mark
Handly's work has been referred earlier, but is it really meeting the
design goals? Particularly I am curious to see how a transport (or a
solution that is in the end points) can possibly solve the routing
scalability problem that is in the core of the network. How is the
number of the routing entries going to be decreased with transport level
solution? I can clearly see that multihoming is be solved but not the
primary goal of scalability. Any thoughts? 

If there is not idea how the scalability is improved then it looks to me
that "transport" solutions are not addressing the problem space and we
can drop them at least until there is a proposal that also addresses the
scalability part.

Regards 
Hannu

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 18 May 2008 11:26:49 -0700

% How is the number of the routing entries going to be decreased
% with transport level solution?
%
%  I can clearly see that multihoming is be solved but not the
% primary goal of scalability. Any thoughts?

At present, most of the scalability issue with the routing system is
CREATED  by the extra more-specific prefixes that are carried in the
DFZ to enable site multii-homing.[1]

So any multi-homing approach that does NOT require those
more-specific prefixes to continue within the DFZ *greatly* improves
the scalability of the DFZ routing system.

So a transport-based approach, which you agree can solve the
multi-homing issue, obviously therefore CAN greatly improve
the scalability of the deploying routing system.

Separately, the Routing RG charter does not list "scalability" as
THE primary goal.  Instead, the charter is clear that there are several
equally weighted goals, including but not limited to scalability and
multi-homing.  For example, the charter lists "mobility" as a goal
equal with those first two.

Yours,

Ran Atkinson
[email-masked]

[1] There are some other reasons that a few of the more specific
prefixes might exist.  However, published analyses of the actual routing
tables indicate those other reasons are NOT a major source of
DFZ RIB/FIB entropy at present.

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 18 May 2008 21:57:36 +0200

Hi Hannu,

[email-masked] escribió:
> number of the routing entries going to be decreased with transport 
> level solution? I can clearly see that multihoming is be solved but 
> not the primary goal of scalability. Any thoughts?
>
I guess that in a transport based approach, the routing system 
scalability is provided by the usage of multiple PA address blocks as in 
any other proposal that i have seen so far.

However, the difference is that the multipla addresses are managed at 
the transport layer. This has potential advantages. For instance, 
transport protocols can react to congestion. So, doing a transport 
based  solution could provide  soem TE capabilities in an autmatica 
manner i.e. those more specifics injected in the routing table to route 
around congsted paths could be automatically avoided.

Regards, marcelo

> If there is not idea how the scalability is improved then it looks to 
> me that "transport" solutions are not addressing the problem space and 
> we can drop them at least until there is a proposal that also 
> addresses the scalability part.
>
> Regards
> Hannu
>

---

From: "Tony Li" <[email-masked]>
Date: Sun, 18 May 2008 14:08:10 -0700

Ran,

|Separately, the Routing RG charter does not list "scalability" as
|THE primary goal.  Instead, the charter is clear that there are several
|equally weighted goals, including but not limited to scalability and
|multi-homing.  For example, the charter lists "mobility" as a goal
|equal with those first two.

I think that this reads a bit more into the charter than is there.  You are
correct, scalability is not listed as THE primary goal and instead lists a
number of goals.  However, the charter is not explicit in giving them equal
weighting.  Rather, it is silent on the issue, giving us the freedom
(necessary, IMHO) to balance the various and sometimes conflicting goals.

Regards,
Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 May 2008 15:09:45 +1200

Hannu,

SCTP is probably the model to look at. In shim6, we concluded
that since SCTP is locator-agile for a given connection, it's
basically pointless and probably harmful to run both shim6
and SCTP on the same packet stream - so SCTP needs to be able to
tell the network layer to disable shim6 for an SCTP socket.

I think we'll find the same here - since SCTP is locator-agile,
it would solve the PA-based multihoming problem nicely without any
kind of dynamic EID-RLOC mapping in the routing system.
(Like shim6, it takes control of path selection out of the routing
system.)

Of course, there is the small problem that the network actually
uses TCP and UDP, but that is intrinsic to any transport based
solution.

    Brian