Subject: [Int-area] IRON issue discussion

From: Scott Brim <[email-masked]>
Date: Thu, 2 Jun 2011 10:08:45 -0400

First, I've changed the subject (but kept the threading).

Second, on this specific issue -- discussion of IRON topics to see if
there are any that canNOT be clarified on the mailing list, and thus
need agenda time -- Tom, you say

> I think that what is wrong with Fred's list is point 1); a technical nicety
> that slows the reader down from getting to points 2) etc, which are
> critical:-)

If I understand correctly, you understand IRON, but you think others
might have trouble understanding it, and you are suggesting some
rewrites?  No agenda time needed?

If there are in fact points you disagree with or believe need
clarifying, could you make them explicit?

Thanks ... Scott

---

From: "t.petch" <[email-masked]>
Date: Thu, 2 Jun 2011 16:56:52 +0200

----- Original Message -----
From: "Scott Brim" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Templin, Fred L" <[email-masked]>; "Internet Area"
<[email-masked]>
Sent: Thursday, June 02, 2011 4:08 PM

> clarifying, could you make them explicit?

Mangling my metaphors, build a better mouse trap and nothing happens.
I believe that this 'mouse trap' deserves a wider hearing than it got on
RRG list and agenda time would give it that.  I believe I understand it
but more discussion would probably throw up some misunderstandings
on my part (I always intended to submit a review on the RRG list which
is the way to see if I understand it or not but, with hindsight,
never gave that work enough priority).

I saw three good things on the RRG list and this was one of them
(err ... the RRG Recommendation was not:-)

Tom Petch

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Jun 2011 09:06:57 -0700

> Mangling my metaphors, build a better mouse trap and nothing happens.

I'd like to jump in here.

IRON has some very useful components, many that are well designed and 
can help others avoid re-inventing the wheel. That's the primary utility 
to INTAREA, IMO - the whole system seems to compete in the space that 
the L3VPN groups are playing (among others), and it's not clear there's 
a single winner in that space (backbone providers will likely continue 
to want VPN and PPVPN solutions).

The larger challenge, IMO, is that the IETF is a place where reinventing 
the wheel is the norm, if not often the goal ;-(

A useful way forward might be a short presentation that highlights the 
components of IRON, and where each addresses a key issue important to 
INTAREA. The entire system as a whole may be relevant, but the parts 
need to be understood and appreciated first, IMO.

Joe

---

From: Scott Brim <[email-masked]>
Date: Sat, 11 Jun 2011 19:17:18 -0400

Folks, speaking for myself:

Regarding IRON, I heard support for discussion but very little
actual discussion.  It kind of died at the starting gate.  Right now I don't
see why IRON should have agenda time until there is clear disagreement
or confusion.

Tom said

> on my part

and Joe said

> A useful way forward might be a short presentation that highlights
> the components of IRON, and where each addresses a key issue
> important to INTAREA. The entire system as a whole may be relevant,
> but the parts need to be understood and appreciated first, IMO.

Both of these wishes could be satisfied by mail from Fred, referring
to sections of the already published RFC.  No?  At least we should try.

Scott

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jun 2011 18:51:45 -0700

Hi Scott,

Thanks for your message. I will go back and respond to the
earlier list messages.

Fred
[email-masked] 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott Brim
> Sent: Saturday, June 11, 2011 4:17 PM
> To: Internet Area
> Subject: Re: [Int-area] IRON issue discussion
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jun 2011 19:12:12 -0700

Hi Tom,

> From: t.petch [mailto:[email-masked]] 
> Sent: Thursday, June 02, 2011 7:57 AM
> To: Scott Brim
> Cc: Templin, Fred L; Internet Area
> Subject: Re: IRON issue discussion
> 

Thanks for your note. Let me try a more high-level description
of the IRON system and see if it serves to clarify or confuse:

The IRON system comprises a virtual overlay network set up
by a provider (perhaps an ISP or a hosting service company)
with the objective of providing network address/prefix
services to client customers. The provider's deployment
includes tunnel endpoint servers and relays that connect
the virtual overlay network to the rest of the public
Internet. The clients can be either routers or hosts, and
can be either mobile or fixed. They connect to a nearby
IRON server via a either VPN (when security is needed) or
a plaintext IP-in-IP tunnel.  

In this system, the client gets to use a stable IP address
or prefix even if it moves between different IRON servers,
but the IRON relays only advertise one or a few short IP
prefixes into the global Internet routing system. The
servers and relays engage in a routing protocol instance
(perhaps using iBGP) to track the association of clients
with servers.

Clients only move to new servers if they travel significant
distances; hence the client-to-server mobility can take
place over very coarse timescales (tens of seconds or
even longer). On the other hand, clients quickly inform
their current server of a change in locator address which
can happen on very short timescales (seconds or less).
Clients can further be redirected to a server that is
closer to the final destination as a form of route
optimization. That function is now covered in more detail
in 'draft-templin-aero'.

That's about it in terms of the overall architecture. The
part that gets more detailed is how the clients select good
servers and quickly inform them of any locator address
changes due to mobility or multihoming. This is the part
where I saw commonalities with MOBIKE, but there are also
commonalities with other tunneling systems like tunnel
broker and ISATAP.  

> (err ... the RRG Recommendation was not:-)

Thanks, and I agree with your assessment!

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jun 2011 19:22:52 -0700

Hi Joe, 

> [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Thursday, June 02, 2011 9:07 AM
> To: t.petch
> Cc: Internet Area

Thanks for setting this background. Yes, there are
commonalities with other tunneling systems, but IRON
goes further than some of the others to discuss
considerations such as mobility, multi-homing, route
optimization and others. It considers both the high
level architecture of the system as well as the nuts
and bolts that hold it together. 

> need to be understood and appreciated first, IMO.

There are certainly parts that could be discussed in
more detail which I think would be helpful in educating
both the community and myself regarding Internetworking
aspects of an IRON system. For example:

  - how the clients discover and connect to nearby servers
  - how clients inform servers of locator addresses changes
  - when and how to invoke route optimization
  - can route optimization be used in the presence of
    VPN tunnels
  - many others

Even though this work came from the RRG, IMHO these tunnel
management issues are more INTAREA-related. Are these the
kinds of things that might be worth discussing futher?

Thanks - Fred

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Jun 2011 22:18:47 -0700

Hi, Fred (et al.),

> Hi Joe,
...
> kinds of things that might be worth discussing futher?

I think it would be useful to consider some bite-sized pieces of IRON 
for presentation to the IntArea. The entire architecture is useful 
independently, but may be too complex to present at an IETF meeting.

Joe

---

From: Bob Hinden <[email-masked]>
Date: Wed, 15 Jun 2011 10:51:25 +0300

Fred,

This sounds a lot like Mobile IPv6 with the extension that the client can change home agents if the client get's too far away from where the the home agent is.  I am sure the details are different, but the functionality sounds similar.

Bob

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 15 Jun 2011 08:18:40 -0700

Hi Bob, 

> From: Bob Hinden [mailto:[email-masked]] 
> Sent: Wednesday, June 15, 2011 12:51 AM
> To: Templin, Fred L
> Cc: Bob Hinden; t.petch; Scott Brim; Internet Area
> This sounds a lot like Mobile IPv6 with the extension that 
> the client can change home agents if the client get's too far 
> away from where the the home agent is.  I am sure the details 
> are different, but the functionality sounds similar.

Yes, the IRON server does act as a mobility anchor point
for the client. In some sense, IRON takes the viewpoint
that the client is always away from home and needs to be
reached via its current server in order to receive inbound
traffic. For outbound traffic, however, the client can be
redirected to the server of the final destination (assuming
the final destination also uses IRON).

The client can then move to a new server over a coarse-
grained timescale and only if it moves a significant
distance away from its current server. On the other hand,
the client should quickly inform its current server of any
changes in link-layer connectivity within a fine-grained
timescale.

To sum up, IRON includes a self-contained mobility
management system that handles mobile hosts and/or
networks without the need for adjunct mechanisms.

Thanks - Fred