Subject: Re: [rrg] moving towards recommendation: the current plan

From: [email-masked] (Noel Chiappa)
Date: Tue, 1 Dec 2009 18:07:39 -0500 (EST)

> From: Christian Vogt <[email-masked]>

    >> Here are some examples of things which are causing extra routing table
    >> entries to appear, which can be done without those extra entries if
    >> there is a identity/location binding layer

    > while your text is phrased in the context of network-based
    > identifier-locator separation ... similar arguments hold for a
    > host-based separation

Actually, my text made no reference to whether the separation was
network-based (i.e. done by (some) routers) or host-based (done by hosts).

When it comes to preferring network-based or host-based solutions, when
considering _architectural_ factors, I actually prefer the latter (because I
want to move functionality out of the network, to maximize long-term
flexibility). However, _engineering_ factors (e.g. the difficulty of changing
hosts) has long led me to conclude that _initial_ deployment has to be
network-based.

Note that I did say 'initially' - over time, I would like/expect to see the
functionality optionally migrate into hosts (i.e. hosts may, but are not
required to, include code which takes up the location/identity separation).
In particular, doing it in a host-based way gives the host more control, so
there's a positive incentive for the hosts to take this up.

However, I still think that engineering considerations favour network-based
for the initial deployment - and have since the 1980s; an advanced routing
system which I worked on back then used the same approach, and for exactly
the same reasons. The vast increase in the size of the host installed base
since then has only reinforced the case for starting with network-based
deployment.

	Noel

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 2 Dec 2009 09:49:52 -0800

> since then has only reinforced the case for starting with 

Noel,

I'd note that (most?) of the host based schemes for loc-id split seem to
add network middle boxes to aid in their initial deployment (hip-proxy,
shim6-proxy, et al).  So it seems reasonable to me to accept this and
start by optimizing for this case and move to the hosts over time.

-Darrel

---

From: [email-masked]
Date: Wed, 02 Dec 2009 14:34:37 -0500

Noel,
Network layer is the matter of the network. The fact that there exist IETF activities which want to handle network congestions by informing the sending hosts 
doesn't prove that hosts are the right peers of the network layer. The network is a shared resource. A host however can only act in egoistic manner. And there are many more issues which are not the business of the user. Multihoming: Ok, the user should have the capability to express his preferences. But it is not only up to him.
I cannot understand that there is a debate like this.
Heiner

Noel,

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

-----Ursprüngliche Mitteilung----- 
Von: Darrel Lewis (darlewis) <[email-masked]>
An: Noel Chiappa <[email-masked]>; [email-masked]
Verschickt: Mi., 2. Dez. 2009, 18:49
Thema: Re: [rrg] moving towards recommendation: the current plan

> However, I still think that engineering considerations favour 
 network-based
 for the initial deployment - and have since the 1980s; an 
 advanced routing
 system which I worked on back then used the same approach, 
 and for exactly
 the same reasons. The vast increase in the size of the host 
 installed base
 since then has only reinforced the case for starting with 
 network-based
 deployment.
 
Noel,
I'd note that (most?) of the host based schemes for loc-id split seem to
dd network middle boxes to aid in their initial deployment (hip-proxy,
him6-proxy, et al).  So it seems reasonable to me to accept this and
tart by optimizing for this case and move to the hosts over time.
-Darrel
______________________________________________
rg mailing list
[email-masked]
ttp://www.irtf.org/mailman/listinfo/rrg

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 03 Dec 2009 11:32:27 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Darrel
> Lewis (darlewis)
> 发送时间: 2009年12月3日 1:50
> 收件人: Noel Chiappa; [email-masked]
> 主题: Re: [rrg] moving towards recommendation: the current plan
> 
> 

Absolutely agree. Both network-based schemes and host-based schemes should
be considered since each will be suitable in different time frames.

draft-zhang-zhang-evolution-02.txt has outlined a route map for evolution.
Maybe host-based schemes can be considered by the authors to be appended as
step six or seven.

Xiaohu

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Dec 2009 11:44:26 -0500

> hosts) has long led me to conclude that _initial_ deployment has to be

Both, actually.  Endpoints are going to leap ahead in LIS because they
need it.  Particularly, mobile endpoints are going to want to optimize
their use of networks.  However, they still need to be able to
communicate with others that have not been upgraded, so they will need
rendezvous points.

> Note that I did say 'initially'

I think it will happen simultaneously.  It is already.

Noel Chiappa allegedly wrote on 12/03/2009 10:47 AM:
>     > From: Scott Brim <[email-masked]>
> 
>     > Do you think routing and addressing requires a session ID in every
>     > packet? If not, let the upper layers find their own solutions
> 
> In a clean, carefully integrated architecture I might agree with you
> (although robustness arguments, which often involve redundancy, might
> disagree). In something that's evolving over time, starting from something
> that's already got some 'bags on the side', there might be a certain value
> in carrying around the semi-duplicate info. But it is of course impossible
> to say specifically without examining the costs and benefits of a
> particular proposed design.

Noel, my question was whether routing and addressing in particular
require a session identifier in every packet.  I don't see this as a R&A
requirement.  It's something that could be added to the IP packet header
syntax, but not for the sake of routing and addressing -- they don't
care.  Right?

Joel M. Halpern allegedly wrote on 12/03/2009 10:57 AM:
> My own reaction to this question is similar.
> I can imagine an architecture and set of tools where the responsibility
> for the identification was either dynamic or an upper layer responsibility.
> However, I think that we may be better off, in trying to get to a better
> state, if the network / routing / lower layers provides a useful stable
> identifier.

Joel, you're talking about an identifier and identification functions
that can be supported in the network layer, so it's a whole-node
identifier.  We've been going over this for about a year or more and I
still argue from practicality.  A useful stable identifier for what?
Which functions would actually use it?

> One example is that this provides a hook on which to hang the various
> kinds of security mechanisms

A whole-node identifier can be used as input to a security association,
but so can a higher-layer identifier, and a whole-node identifier is
insufficient to support finer-grain functions.

, so that security is not tied to the
> locators.  (security tied to the locator seems to be a problem that we
> gave ourselves by not having anything else for it to be based on.)

Well, what I see a lot of is packets coming in from some address which
is then validated -- by some higher layer security exchange.  See above.

> Similarly, it seems to me that having such an identifier simplifies many
> of the problems of adding and subtracting locators from a site.  While
> one can structure all the changes in terms of old-set->new-set, it seems
> much more robust to think in terms of an identifier aquiring new locator
> information.  

All true since you just say "identifier" generically.  A whole-node
identifier ... one that can be managed by the network layer ... is
significantly less flexible than a group of higher-layer identifiers.

> This identification would seem to also be useful
> eventually in terms of policy management (which often loives at these
> layers), and related issues.

When I establish a security association with a management entity, I
don't talk to the whole node, I talk to the management entity within
that node.

We can dig up old mail if we need to and go through this all again.  My
main point in this thread was that routing and addressing, in
themselves, do not require a particular identifier to be in every packet.

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Dec 2009 11:57:52 -0500

No, routing and addressing do not, in and of themselves, require an 
identifier in every packet.
I had not understood your question as being focussed on the "in every 
packet" question.
I was trying to get at the quesiton of whether the routing and network 
system should have an identifier.  I think it should.  As far as I can 
tell, multiple aspects of the system would be cleaner and easier to work 
with if such an identifier exists (see below for what I would identify.)

As for "in every packet", no, of course the identifier does not have to 
appear in every packet.  In some systems, it naturally does.  In others, 
it doesn't.
I have no problem, for example, with an approach where stateful 
communication (such as TCP) sends the identifier in those packets which 
are related to establishing or updating the relationship (I.e. the TCP 
syn exchange and anything which updates the locator set), but otherwise 
uses other information in the packet (a locator plus carefully managed 
connection identifiers may be suitable in some approaches) to make 
things function.  (I am not sure how to handle things like UDP without 
putting the identifier in every packet.)

As for what I want to identify, I tend to think that the identifier 
should correspond not to the physical node, but to the logical stack 
construct.  A logical set of protocol machinery, stacked from the 
network layer up.  A physical machine may have multiple of these.  And 
in some cases, a single one of these may be operating across physical 
boundaries, if the coupling works right.
While I have considered writing up a document on just this, I didn't 
bother because it does not seem it would provide any actual value to the 
research group in reaching a conclusion on what to recommend.

Yours,
Joel M. Halpern

Scott Brim wrote:
...
> Which functions would actually use it?
...

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Dec 2009 13:18:42 -0500

Joel M. Halpern allegedly wrote on 12/03/2009 11:57 AM:
> identifier in every packet. I had not understood your question as
> being focussed on the "in every packet" question. I was trying to get
> at the quesiton of whether the routing and network system should have
> an identifier.  I think it should.  As far as I can tell, multiple
> aspects of the system would be cleaner and easier to work with if
> such an identifier exists (see below for what I would identify.)

Yes but if your favorite identifier is a stack name ("logical stack
construct"), how can it be handled by the network layer -- except as an
opaque bucket?  The state the identifier is associated with is only in
and used by the communication endpoints.  When you say the network
layer, are you including DNS lookups in that?

> (I am not sure
> how to handle things like UDP without putting the identifier in every
> packet.)

UDP isn't much of a transport protocol, so usually things related to
additional endpoint state are handled above it.

> network layer up.  A physical machine may have multiple of these.
> And in some cases, a single one of these may be operating across
> physical boundaries, if the coupling works right. 

Right :-).  As we've said before, I have no problem with the concept,
just doubting whether we need a new namespace.  And ...

> While I have
> considered writing up a document on just this, I didn't bother
> because it does not seem it would provide any actual value to the 

... that might complement the point I was trying to make before, that
routing and addressing don't care how identifiers are used.

Thanks ... Scott

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 06:19:55 +0900

On Fri, Dec 4, 2009 at 1:57 AM, Joel M. Halpern <[email-masked]> wrote:

> As for what I want to identify, I tend to think that the identifier should
> correspond not to the physical node, but to the logical stack construct.  A
> logical set of protocol machinery, stacked from the network layer up.  A
> physical machine may have multiple of these.  And in some cases, a single
> one of these may be operating across physical boundaries, if the coupling
> works right.
>

This is a model I could understand. In old terms, which many of this
community might not like, this 'logical stack' id is once used to be call
'node address'. And this exactly 'node address' is used to identify that
logical stack construct (from network layer up through transport up to the
app layer) AND, what is more important, is also used for 'routing'. Stating
again, one id, called 'node address' is used both for identifying a node AND
routing.

So, in this model, there's no two separate things like ID and Locator.

Whereas... the 'physical address', or in Internet terms 'PoA address', is in
fact the Layer 2 address, or MAC address.

So, you

       - identify a (logical and physical) node by a 'node address'
       - do you L3 routing based on this 'node address'
       - in passing through sub-network or L2 network, you map this 'node
address' to 'L2 or MAC' address.

The flaw that the Internet had was to regard the IP address as the PoA
address. No. IP address should be the 'node address'. That is, if you have
to choose one of the two roles that IP address was thought to assume, i.e.
ID and Locator, it should be the 'ID' part we have to preserve. The name
'ID', though, is not the correct one, since in this (new but in fact old)
model, this 'ID' is also used as L2 routing. Therefore, the correct name
should be 'node address'.

Then what to do with the PoA part of IP address we gave up above? That PoA
part will exactly be the role of sub-network or L2 (or MAC) address.

So, to me, IP address is fine as it is now, only that I use IP address as
pure L3 'node address'. Or put it more correctly, 'sub-network independent
internetworking' node address.

Whereas the physical address you mentioned is to me, either

     - subnetwork address or
     - L2 address or
     - MAC address

depending on what underlying service is available to my 'internetworking'
sublayer.

The whole confusion of the Internet has ever started to define IP address as
PoA address. No, it should be 'node address'. And there's no such thing as
PoA address, but subnetwork or L2 address.

I don't propose to throw away IP address. Rather keep it but use it only in
the context of the 'node address' (which term this community has associated
with ID).

Mostly, I like your idea of separation. Only that, your ID should not be a
new creation, but the IP address be used as ID, or more exactly, node
address. And leave everything else to the underlying layer's job or
property.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 06:24:13 +0900

> layer, are you including DNS lookups in that?

It will be handled by the network layer as it's routing address. For, to me,
this ID and the node address and the 'internetwork' routing address are the
one and the same thing.

And yes, I get this node address from the DNS lookup. And in that way, the
current IP address is my node address(= id = intenetworking addr), but not
the PoA address.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Dec 2009 16:32:22 -0500

You seem to have made a leap in reading my note that I did not intend.
At least in the model I was attempting to describe, the stack ID is NOT 
used by the routing system for reachability, and not normally used by 
the packet forwarding system for forwarding.

(If one has a design in which the stack ID appears in eveyr packet, and 
if one has other constraints that lead one to want to, one might choose 
to do last hope resolution using the stack ID instead of the locator. 
But that is, usually, a detail that can be worked out.  It does affect 
what locators need to name.)

Yours,
Joel

Dae Young KIM wrote:
> On Fri, Dec 4, 2009 at 1:57 AM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> community might not like, this 'logical stack' id is once used to be 
> call 'node address'. And this exactly 'node address' is used to identify 
> that logical stack construct (from network layer up through transport up 
> to the app layer) AND, what is more important, is also used for 
> 'routing'. Stating again, one id, called 'node address' is used both for 
> identifying a node AND routing.
> 
> Whereas... the 'physical address', or in Internet terms 'PoA address', 
> is in fact the Layer 2 address, or MAC address.
> 
> So, you
> 
>        - in passing through sub-network or L2 network, you map this 
> 'node address' to 'L2 or MAC' address.
> 
> address. No. IP address should be the 'node address'. That is, if you 
> have to choose one of the two roles that IP address was thought to 
> assume, i.e. ID and Locator, it should be the 'ID' part we have to 
> preserve. The name 'ID', though, is not the correct one, since in this 
> (new but in fact old) model, this 'ID' is also used as L2 routing. 
> Therefore, the correct name should be 'node address'.
> 
> Then what to do with the PoA part of IP address we gave up above? That 
> PoA part will exactly be the role of sub-network or L2 (or MAC) address.
> 
> So, to me, IP address is fine as it is now, only that I use IP address 
> as pure L3 'node address'. Or put it more correctly, 'sub-network 
> independent internetworking' node address.
> 
> depending on what underlying service is available to my 
> 'internetworking' sublayer.
> 
> The whole confusion of the Internet has ever started to define IP 
> address as PoA address. No, it should be 'node address'. And there's no 
> such thing as PoA address, but subnetwork or L2 address.
> 
> I don't propose to throw away IP address. Rather keep it but use it only 
> in the context of the 'node address' (which term this community has 
> associated with ID).
> 
> Mostly, I like your idea of separation. Only that, your ID should not be 
> a new creation, but the IP address be used as ID, or more exactly, node

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Dec 2009 16:36:36 -0500

> what locators need to name.)

Right, it can be used by both identification functions and location
functions.

---

From: Christian Vogt <[email-masked]>
Date: Sat, 5 Dec 2009 22:08:53 -0800

Branched from thread "moving towards recommendation: the current plan".

On Dec 1, 2009, Noel Chiappa wrote:

> considering _architectural_ factors, I actually prefer the latter
> (because I want to move functionality out of the network, to maximize
> long-term flexibility). However, _engineering_ factors (e.g. the
> difficulty of changing hosts) has long led me to conclude that _initial_
> deployment has to be network-based.

We often take it that host changes are harder than network changes.  But
is this assumption actually valid?  There is, in fact, substantial
evidence that it is not.  Consider IP version 6, which was deployed in
operating systems well before operators deployed it in their networks.

Also from an economic standpoint, host changes appear easier than
network changes:  Given the small number of operating systems used by
the majority of hosts, and given the highly automated methods to update
these operating systems, changes to one of the main operating systems
quickly affect a large number of hosts, hence at a small cost per host.
Network upgrades are slower and more expensive.

Furthermore, for the same reason that network operators would tend to
defer changes, operating system vendors may be eager to adopt them. This
happens when the change must be bilateral to yield a benefit -- as is
the case with multi-homing support, which we are discussing here.
Network operators gain no immediate benefit by adopting a network-based
multi-homing mechanism early on, because the remote part of the
mechanism does not exist initially.  Operating system vendors, on the
contrary, can distinguish their product from competition based on the
new multi-homing support, as the multi-homing support improves
communications between their operating system relative to the operating
systems without multi-homing support.

Thus, in my personal opinion, host-based multi-homing support will have 
a faster impact than any corresponding network-based support.

- Christian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Dec 2009 09:30:45 +1300

I was thinking about commenting on this point too, but Christian
beat me to it.

We *can* propagate changes to the numerically significant host
operating systems. It takes years, so any solution based on this
must be one with a completely incremental deployment model. One
view of the IPv6 deployment problem is that it depends on *both*
incremental deployment to all hosts *and* centralised deployment
by operators. That's the worst case, but seems inevitable for
an actual change of the IP packet format.

So, I think that tells us that a solution that requires host stack
changes only, *or* infrastructure changes only, but not both,
is deployable.

Personally, I wouldn't expect something called "routing research
group" to propose a strategy based 100% on host changes and 0% on
changes to the routing system. But we could conceivably propose
something based on changes to both, and that would surely be
a big mistake.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Mon, 7 Dec 2009 13:06:29 -0500

> something based on changes to both, and that would surely be

Right.  And best of all is to start at both ends and work toward
something good.  Do something in endpoints that helps them accomplish
their goals without depending on the network.  Do something in the
network that has the ability to help scale routing and addressing even
assuming hosts don't change, BUT is designed so that as the hosts DO
change that ability can be abandoned, and the whole system can become
more streamlined.

---

From: Shane Amante <[email-masked]>
Date: Mon, 7 Dec 2009 12:48:35 -0700

Scott,

> change that ability can be abandoned, and the whole system can become

I *very* much agree with all of the above points!  Specifically, it's critical that we develop both types of solutions as different networks/domains are going to be vastly different in terms budget, staff, priorities and size/scale.  For example, those with large size/scale may have a significant amount of 'legacy' equipment they have to maintain "as is" (or it would take [much] longer to 'upgrade' it in some form), therefore they're likely to start with a network-based solution.  OTOH, those networks that are green-field, planning/obligated to do host O/S upgrades and/or small(er) networks may choose to start with a host-based solution.

An analogy from a security standpoint is that hopefully most administrators realize that host-based firewall solutions are superior (particularly for laptops, etc. that roam outside a corporate firewall)[1]; however, 'legacy systems' may not [ever, or initially] support host-based firewall solutions, therefore a network-based firewall is necessary to provide protection to them ...

The bottom-line is various networks (and, hosts in them) are continually evolving *and* are evolving at different time-scales.

-shane

[1] This would be analogous to host-based ID/Loc split solutions, assuming they provide adequate mobility.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 07 Dec 2009 15:11:45 -0500

I like the picture painted below of synergistic, incremental, flexbile 
deployment of improved behavior.

However, this two-ended incentive relates to one of the things that 
concerns me about the current paths of this work.

On the one hand, we are looking at a variety of tunneling mechanisms 
designed to relive the PI pressure on the core.
One of the other important goals of most of these proposals is that they 
remove the difficulty of multihoming and changing providers (thus 
providing an incentive for enterprise cooperation / deployment.)

Meanwhile, other sides of our house are looking at interesting ideas 
such as TCP Multipath support.  These techniques work most simply when 
the tcp sender and receiver have visibility to the attachment addresses 
of the site to the Internet, and the ability to select which one is used.
All of the network based tunneling techniques I can see seem to have the 
property that in providing for multihoming and the ability to change 
providers, they remove exactly the visibility that our other hand is 
trying to utilize.

There seems to be a systemic disconnect.

Yours,
Joel

---

From: Shane Amante <[email-masked]>
Date: Mon, 7 Dec 2009 13:48:12 -0700

Joel,

On Dec 7, 2009, at 13:11 MST, Joel M. Halpern wrote:
> I like the picture painted below of synergistic, incremental, flexbile deployment of improved behavior.
> 
> However, this two-ended incentive relates to one of the things that concerns me about the current paths of this work.
> 
> On the one hand, we are looking at a variety of tunneling mechanisms designed to relive the PI pressure on the core.
> One of the other important goals of most of these proposals is that they remove the difficulty of multihoming and changing providers (thus providing an incentive for enterprise cooperation / deployment.)
> 
> Meanwhile, other sides of our house are looking at interesting ideas such as TCP Multipath support.  These techniques work most simply when the tcp sender and receiver have visibility to the attachment addresses of the site to the Internet, and the ability to select which one is used.
> All of the network based tunneling techniques I can see seem to have the property that in providing for multihoming and the ability to change providers, they remove exactly the visibility that our other hand is trying to utilize.
> 

Valid point.  However, in various places in the IETF the above problem has been addressed by "Applicability Statements" and/or "Applicability Documents" that should articulate when certain mechanisms can be used together (or not).  For example, MP-TCP may advise that it should only be used in the context of host-based multi-homing solutions, since MP-TCP doesn't benefit from network-based multi-homing solutions.

-shane

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 8 Dec 2009 13:34:54 +0200

On Mon, Dec 7, 2009 at 10:11 PM, Joel M. Halpern <[email-masked]> wrote:
> remove the difficulty of multihoming and changing providers (thus providing
> an incentive for enterprise cooperation / deployment.)
>
> Meanwhile, other sides of our house are looking at interesting ideas such as
> TCP Multipath support.  These techniques work most simply when the tcp
> sender and receiver have visibility to the attachment addresses of the site
> to the Internet, and the ability to select which one is used.
> providers, they remove exactly the visibility that our other hand is trying
> to utilize.
>

Joel,

think they are not that far away from each other.
I'm under time constraints so I jump directly into an example.

You could easily add xTRs to the hIPv4 framework by adding a RLOC
block to an ALOC realm, i.e. the ALOC realm would advertise two
prefixes to the DFZ
- the ALOC prefix used by the LSRs
- an aggregate of the RLOC block, the RLOC prefixes are assigned to
the xTRs belonging to the ALOC realm

So when a packet arrives to an ITR it need to do the following
- if the packet carries a hIPv4 header the endpoint has been upgraded
and take cares of itself, normal forwarding upon the destination IP
address
- if the packet carries an IPv4 header and the destination is found in
the RIB, normal forwarding upon the destination IP address
- if the packet carries an IPv4 header and not found in the RIB, send
the packet down to the ALT network and once a reply is received create
a cache entry and send it over the tunnel

And don't see this two approaches competing with each other, if the
endpoints gets upgraded do we really need to use the tunnel solution -
why not assemble the packet in such why that a non-overlay solution
can be used instead?

The only drawback by staying in the tunneling solution is that the
IP-address space needs to be globally unique (unless you do some kind
of DNS caching on the ITR, but I'm not eager to go there). If more
addresses is needed, the endpoints need to be upgraded anyway - choice
here is to move on to IPv6 or have hierarchy in the IPv4 space.

By synchronizing both groups in the house we will have two options,
routing hierarchy can be achieved by upgrading both network devices
and endpoints - but we don't need to wait on all endpoints before the
routing hierarchy can be put in place . And there exist a blueprint
how to take the architecture to the next level, it doesn't stop at the
network layer.

I might have missed something, haven't had time to check every corner case.

-- patte

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 9 Dec 2009 03:58:34 +0200

Hi all,

Sorry for spamming the list with a presentation but it was the fastest
and easiest way to show my findings when I checked the corner cases if
both camps are integrated into one framework.

When e.g. LISP is used between two endpoints, there is nothing new
When hIPv4 is used between two endpoints, that is described in my
draft and nothing new

Two new use cases needs to be checked, i.e.
1) legacy client with an ITR in front establishing a session to a
hIPv4 enabled server
2) a hIPv4 client establishes a session to a legacy server with an ETR in front

To better understand I need to explain some syntax, please don't throw
stones on me because it has been a hot topic for while :-)
- endpoint locator, ELOC = endpoint identifier, EID in LISP
- RLOC, as defined in LISP
- ALOC, as defined in hIPv4
So three types of locators are needed, but in the Map-server and DNS
either ALOC or RLOC is used at a time for an entry - depending upon
the status of the site, are the endpoints upgraded to hIPv4 or not.

And the xTRs could also act as MPTCP proxies :-)

This is an early brain dump, so give it hard times - but it seems to
be possible to integrated both into one framework and then the
Internet citizens do have a choice to upgrade what suits them best.

Comments?

-- patte
On Mon, Dec 7, 2009 at 10:11 PM, Joel M. Halpern <[email-masked]> wrote:
>> I *very* much agree with all of the above points!  Specifically, it's
>> critical that we develop both types of solutions as different
>> networks/domains are going to be vastly different in terms budget, staff,
>> priorities and size/scale.  For example, those with large size/scale may
>> have a significant amount of 'legacy' equipment they have to maintain "as
>> is" (or it would take [much] longer to 'upgrade' it in some form), therefore
>> they're likely to start with a network-based solution.  OTOH, those networks
>> that are green-field, planning/obligated to do host O/S upgrades and/or
>> small(er) networks may choose to start with a host-based solution.
>>
>> An analogy from a security standpoint is that hopefully most
>> administrators realize that host-based firewall solutions are superior
>> (particularly for laptops, etc. that roam outside a corporate firewall)[1];
>> however, 'legacy systems' may not [ever, or initially] support host-based
>> firewall solutions, therefore a network-based firewall is necessary to
>> provide protection to them ...
>>
>> The bottom-line is various networks (and, hosts in them) are continually
>> evolving *and* are evolving at different time-scales.
>>
>> -shane
>>

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 9 Dec 2009 11:59:11 +0200

Hi all,

played around a little bit with this and had to update the
presentation...throwing another early brain dump on the table...

The reason is - what if the ALT network is the current DFZ????

Then early adapters could start to build their own ALOC realms, find
peering partners and once in place start to move their customers from
DFZ to their ALOC realm. This would give the early adapters an
advantage, once they have completed their transition of customers they
control the size of their RIB and do not need to pay for a possible
upgrade of FIBs in the DFZ zone.
The ALOC realm might be build by introducing another address-family or
by using MPLS VPN L3 address-family during the transition phase.

The DFZ would slowly implode - which I think is the main goal :-)

I hope the RRG-team can consider this approach during the evaluation
of proposals - unfortunately I have no time to update my draft at the
moment, sorry.

-- patte

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 10 Dec 2009 19:52:50 +0200

Hi,

after one nights sleep and looking on it again I noticed a flaw in the
diagrams. The MPTCP subflow can not be initiated/terminated on
different ITRs/ETRs, it must be assembled/disassembled on the same
endpoint (xTR).

-- patte