Subject: Re: [Mip4] Status update & Recharter effort

From: George Tsirtsis <[email-masked]>
Date: Fri, 6 Mar 2009 15:22:58 +0000

On Wed, Feb 11, 2009 at 5:04 PM, McCann Peter-A001034
<[email-masked]> wrote:
...
>
>
> Several new work items have come to our attention over the past
> few meeting cycles.  Here is a partial list of potential work items
> for mip4 going forward.  Please comment on which you would like to
> see and which you think should be excluded.
>
>
> draft-deng-mip4-host-configuration-00.txt
> draft-chakrabarti-mip4-mcbc-03.txt
>  These two items are related, because DHCP uses IP-layer broadcast
>  to deliver DHCPREQUEST messages.  I'd like to propose that we drop
>  the gen-ext draft and add these two.  Comments?
>
> draft-gundavelli-mip4-multiple-tunnel-support-00.txt
>  We've had some good discussion already on the mailing list and this
>  seems like a potentially useful extension.  Comments?
>

GT> If we take this up we should also consider
http://tools.ietf.org/html/draft-tsirtsis-mip4-flowmove-01 which is
expired but still relevant I think.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Mar 2009 23:29:13 +0100

Alexandru Petrescu a écrit :
> Antti Mäkelä a écrit :
>> On Wed, 11 Feb 2009, McCann Peter-A001034 wrote:
>> 
>>> draft-makela-mip4-nemo-haaro-03.txt This was presented at IETF-70
>>>  and it looks like there have been a couple of revisions since. 
>>> Is there interest in working on it? Other comments?
>> 
>> As the primary author :) I'll comment that I have been preparing 
>> for and will most likely (barring force majeure issues) start 
>> working towards my doctoral dissertation in the summer as soon as 
>> certain arrangements have been made. My topic will be covering the 
>> virtual operator model outlined in the first section of the draft. 
>> The work will be conducted as part of Finnish Future Internet 
>> project (http://futureinternet.fi/). Anyway, at least *I* will 
>> continue to have interest in developing this further - so I'm not 
>> just going to toss it to the WG and leave it at -00..as part of the
>>  work, there will be actual implementation coming up.
>> 
>> Whether the draft is of interest to the IETF is of course another 
>> matter, but I do remember hearing some encouraging comments from 
>> the audience in Vancouver that this thing might actually have a 
>> business case :)
> 
> This is certainly a draft worth following up closely, I can provide 
> comments on the mailing list as new versions come up.

(sorry I wasn't in the mip4 jabber room).

This nemo-haaro should be further pursued.  I could come back later with
further support but here goes the easiest.

I some times deal with IPv4 moving networks in vehicles, very often
connecting to a cell operator network.  That network is very dumb in
terms of IP mobility, although very high bandwidth.  The type of
services I'm considering offering to users involve continuous sessions.
  _If_ the operator offered this, and via short paths (not through HAs)
then I'd have much less work to do deploying home agents, designing
endpoint-based RO, etc.

That's why I do support all initiative which may some day lead to a cell
operator offering IP mobility, and RO, and for moving networks at the 
same time.

But of course it should be identified, or reminded, what kind of RO is
haaro, and how much applicability does it have to real deployments.

Alex

> Alex
> 
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> 
>> 
>> -- Mip4 mailing list: [email-masked] Web interface: 
>> https://www.ietf.org/mailman/listinfo/mip4 Charter page: 
>> http://www.ietf.org/html.charters/mip4-charter.html Supplemental 
>> site: http://www.mip4.org/
> 
> 
> -- Mip4 mailing list: [email-masked] Web interface: 
> https://www.ietf.org/mailman/listinfo/mip4 Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html Supplemental 
> site: http://www.mip4.org/
>

---

From: Antti Mäkelä <[email-masked]>
Date: Wed, 25 Mar 2009 09:51:59 +0200 (EET)

On Tue, 24 Mar 2009, Alexandru Petrescu wrote:

> operator offering IP mobility, and RO, and for moving networks at the same 
> time.

Hi,

   Thanks for support :)

   During the session (recharter discussion portion) there were some 
questions about on what's the use-case as it was still a bit unclear. Now, 
the use-case is right there in the first section of the draft for the 
explicit purpose of informing reader of that

http://tools.ietf.org/html/draft-makela-mip4-nemo-haaro-03#page-4

   However, I'll reiterate the points in the draft here, what were my 
original drivers for writing the draft. Unlike Alexandru, I originally 
didn't consider mobile networks in "traditional" sense at all (e.g. cell 
phone networks). And hoping this might garner enough interest that the WG 
could still consider taking this in...

   My original use case was simply this:

   You have a
   - Small company (not too much money to invest in infrastructure) with 
several sites or
   - Medium sized or large company with perhaps a HQ and several small 
branch/sales offices that need reliable connectivity.

   Anyway: You wish to have reliable, private connectivity between each 
site.

   Options:

   - You can get a dedicated line for each site from your friendly ISP (T1, 
Frame Relay, ATM, MPLS, you know). Pro: Reliable, guaranteed SLAs. Con: 
Costs a LOT. $$$$ issue.
   - You can get a consumer-grade ADSL/Cable/etc from a consumer-grade ISP 
for peanuts a month and run VPN on top of that. Pro: Cheap. Con: No 
guarantee of service, can go down at any time.

   Now, following this train of thought: What if you could bundle several 
of these cheap connections together, running a VPN on top, so that there 
would be a switchover if a single connection goes down? Consumer-grade DSL 
might be flaky but hey, if you have 3 consumer-grade connections from 
separate providers, they probably won't ALL be down at once. Most of the 
time.

   Problem: You really cannot run multihoming on top of consumer-grade 
connections. Try getting an AS number and BGP peering working over such a 
link... not going to happen. Without routing protocol, well, since IP 
addresses of *any* endpoint can change dynamically, you'd need some 
central point constantly reconfiguring the VPNs, at least if you are 
running full mesh.

   Enter Mobile IP, and replace the gateway routers at customer sites with 
Mobile Routers connecting to a central Home Agent.

   We've already done this (way back in '07) in lab with Cisco Mobile 
Routers (Non-nemo proprietary, no route optimization). In case of 
last-mile link failure, the switchover is immediate - you lose a few 
packets. If the failure happens further upstream, you need to wait for RFC 
3519 keepalive to expire. However, even when running e.g. streaming 
application, you can just snap your fingers and the traffic comes in on 
the new connection. Problem sort of solved.

   New Problem: Once there's plenty of load, Home Agent becomes point of 
congestion since ALL traffic goes via the HA (star topology).

   Enter Route Optimization. Someone still needs to run that HA and provide 
it as a service. Enter "Virtual Operator ('ISP')". The HA is hosted at 
traditional High-Availability network. One HA can probably serve multiple 
customers.

   Business case: The local DSL/Cable/insert consumer connection providers 
who run bit-pipes can keep on selling bit-pipes. Each customer needs a 
few.
   Virtual Operator provides an overlay service that provides reliable 
site-to-site connectivity with cheap (consumer grade DSL cost times X) 
pricing. Bulk of the real load happens at the access operators networks. 
Home Agent handles mostly control traffic and few initial traffic flows 
before RO can kick in.

   Note that when I'm talking about customers, I mean corporations or 
similar entities (The ISP's customers). I'm not even mentioning *users*.

   What the draft provides: Means for Mobile Routers to discover other 
Mobile Routers (Since HA knows all MRs, it might as well relay that 
information to them), so they can establish direct MIP tunnels.

   Using this with a wireless network is obviously possibility. Cable/DSL 
are just the most traditional examples. In fact, the more technologies you 
can mash together the more independent the connections become (DSL from 
multiple operators probably goes through same wiring closet).

   So...if the above description manages to convice anyone that this might 
be a good idea to work on within the WG, would be nice :)

-- 
- Antti Mäkelä | Senior Network Architect | +358 2040 21613 -
- TeliaSonera Corporation -

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Mar 2009 16:44:42 +0100

Antti Mäkelä a écrit :
>> This nemo-haaro should be further pursued.  I could come back later
>>  with further support but here goes the easiest.
>> 
>>  connecting to a cell operator network.  That network is very dumb 
>> in terms of IP mobility, although very high bandwidth.  The type of
>>  services I'm considering offering to users involve continuous 
>> sessions. _If_ the operator offered this, and via short paths (not 
>> through HAs) then I'd have much less work to do deploying home 
>> agents, designing endpoint-based RO, etc.
>> 
>> That's why I do support all initiative which may some day lead to a
>>  cell operator offering IP mobility, and RO, and for moving
>> networks at the same time.
> 
> Hi,
> 
> Thanks for support :)
> 
> questions about on what's the use-case as it was still a bit unclear.
>  Now, the use-case is right there in the first section of the draft 
> for the explicit purpose of informing reader of that
> 

That section's use-case - multi-homed fixed sites - is not relevant for
the vehicular mobile router experimentations I'm considering.

> original drivers for writing the draft. Unlike Alexandru, I 
> originally didn't consider mobile networks in "traditional" sense at 
> all (e.g. cell phone networks). And hoping this might garner enough 
> interest that the WG could still consider taking this in...
> 
> You have a - Small company (not too much money to invest in 
> infrastructure) with several sites or - Medium sized or large company
>  with perhaps a HQ and several small branch/sales offices that need 
> reliable connectivity.
> 
> - You can get a dedicated line for each site from your friendly ISP 
> (T1, Frame Relay, ATM, MPLS, you know). Pro: Reliable, guaranteed 
> SLAs. Con: Costs a LOT. $$$$ issue. - You can get a consumer-grade 
> ADSL/Cable/etc from a consumer-grade ISP for peanuts a month and run 
> VPN on top of that. Pro: Cheap. Con: No guarantee of service, can go 
> down at any time.
> 
> Now, following this train of thought: What if you could bundle 
> several of these cheap connections together, running a VPN on top, so
>  that there would be a switchover if a single connection goes down? 
> Consumer-grade DSL might be flaky but hey, if you have 3 
> consumer-grade connections from separate providers, they probably 
> won't ALL be down at once. Most of the time.
> 
> connections. Try getting an AS number and BGP peering working over 
> such a link... not going to happen. Without routing protocol, well, 
> since IP addresses of *any* endpoint can change dynamically, you'd 
> need some central point constantly reconfiguring the VPNs, at least 
> if you are running full mesh.
> 
> Enter Mobile IP, and replace the gateway routers at customer sites 
> with Mobile Routers connecting to a central Home Agent.
> 
> packets. If the failure happens further upstream, you need to wait 
> for RFC 3519 keepalive to expire. However, even when running e.g. 
> streaming application, you can just snap your fingers and the traffic
>  comes in on the new connection. Problem sort of solved.
> 
> Enter Route Optimization. Someone still needs to run that HA and 
> provide it as a service. Enter "Virtual Operator ('ISP')". The HA is 
> hosted at traditional High-Availability network. One HA can probably 
> serve multiple customers.
> 
> Business case: The local DSL/Cable/insert consumer connection 
> providers who run bit-pipes can keep on selling bit-pipes. Each 
> customer needs a few. Virtual Operator provides an overlay service 
> that provides reliable site-to-site connectivity with cheap (consumer
>  grade DSL cost times X) pricing. Bulk of the real load happens at
> the access operators networks. Home Agent handles mostly control
> traffic and few initial traffic flows before RO can kick in.
> 
> Using this with a wireless network is obviously possibility. 
> Cable/DSL are just the most traditional examples. In fact, the more 
> technologies you can mash together the more independent the 
> connections become (DSL from multiple operators probably goes through
>  same wiring closet).
> 
> So...if the above description manages to convice anyone that this 
> might be a good idea to work on within the WG, would be nice :)

The motivation of using Mobile IP with sites where BGP would be used
traditionally but couldn't because no AS number for a little
ADSL consumer - makes some sense to me.  This could be discussed further.

For me it's difficult to advertise the use of Mobile IP protocol for
sites which aren't moving.  Maybe one day, when a definition of
'mobility' encompassing something else than a device handing over from
one base station to another becomes more accepted.

And, at the same time, it may happen that an RO scheme designed for MIP
for fixed sites may be re-used for MIP for mobile devices - (like the
DHCP method designed earlier for workstations is largely used for PDAs
today.)

Another motivation for MIP4 RO could be the easiness of using a Mobile
Router in a moving entity, running both MIP4 and MIP6, and RO for MIP6
and RO for MIP4 - without having to implement a complex DSMIPv6 or
DSMIPv4 RO.

Alex