Subject: Re: [Int-area] Steps to make the IntArea WG more productive

From: "t.petch" <[email-masked]>
Date: Thu, 2 Jun 2011 11:09:38 +0200

---- Original Message ----- 
From: "Scott Brim" <[email-masked]>
To: "Templin, Fred L" <[email-masked]>
Cc: "Internet Area" <[email-masked]>
Sent: Tuesday, May 31, 2011 10:29 PM
Subject: Re: [Int-area] Steps to make the IntArea WG more productive

Fred: since you already have an RFC, what I am looking for is whether
there is a need for agenda time.  If nobody on this list -- where the
truly interested parties are to be found -- expresses disagreement or
confusion, then there is no reason to go over it again.

Could those who are interested in this topic please look at the points
below and respond by the end of the week, saying whether they have the
same understanding as Fred, or they disagree, or they need
clarification?  Please be as specific as possible.

Scott

I think that this deserves more time and attention.

I tracked the RRG list and the 20 or so possible future architectures
that were discussed there and this seemed one of the ones that was
more likely to succeed technically.  LISP has the manufacturer drive 
behind it while the recommendation that was produced in the RFC2b -
well, to quote
"The group did not reach consensus on this
recommendation, thus the recommendation reflects the decision of the
co-chairs. The group did reach consensus that the overall document
should be published."
which I do not see as a ringing endorsement.

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:-)

Tom Petch

... Scott

On Tue, May 31, 2011 at 14:49, Templin, Fred L
<[email-masked]> wrote:
> Hi Scott,
>
> OK. I think there may be insufficient understanding on
> the following points (and possibly others):
>
> 1) IRON is about managing tunnels between mobile clients
> and fixed servers. When the tunnel uses security, the
> system becomes one of managing mobile VPNs much in the
> same way as for MOBIKE:
>
> http://www.ietf.org/id/draft-templin-ironmike-01.txt
>
>
> IRON goes beyond the basic MOBIKE model to specify how
> the servers form a full/partial mesh between themselves
> so that clients can be tracked even if they move from
> server to server. Clients can be either a mobile router
> or a mobile host. An example use case is for mobile or
> nomadic devices connecting to a home enterprise network
> by locating a nearby VPN gateway, then changing to a new
> VPN gateway due to mobility events as necessary.
>
> 2) IRON is about suppressing routing scaling in the DFZ:
>
> http://www.rfc-editor.org/rfc/rfc6179.txt
>
> IRON networks advertise only highly-aggregated prefixes
> in the DFZ and delegate more-specific prefixes to IRON
> clients. The full/partial mesh of IRON servers provide
> the means for maintaining generally shortest path
> routing to mobile clients within the overlay network.
>
> 3) IRON is about route optimization:
>
> http://www.ietf.org/id/draft-templin-aero-00.txt
>
> When IRON client A wishes to connect to IRON client B,
> A first sends its initial packets through its own
> server S(A). S(A) then forwards the packets to B's
> server S(B). A is then redirected to S(B) so that
> subsequent packets do not need to flow through S(A).
>
> 4) IRON is about multiple interfaces. Consider an airplane
> that connects to the ground via multiple wireless links.
> IRON configures a mobile VPN over the multiple available
> links such that the VPN connection survives even if the
> underlying link states fluctuate.
>
> 5) IRON is a means for an ISP to provide overlay network
> services to its client customers:
>
> http://www.ietf.org/id/draft-templin-iron-pm-01.txt
>
> A typical example would be for an ISP to delegate fully
> native IPv6 prefixes to client customers, then provide
> an overlay network routing system that connects clients
> to correspondents both within the ISP's overlay network
> as well as within the public Internet.
>
> Again, this is a partial list but should be sufficient
> to initiate discussion. What would you like to see in
> terms of next steps?
>
> Thanks - Fred
> [email-masked]
>
>> -----Original Message-----
>> From: Scott Brim [mailto:[email-masked]]
>> Sent: Friday, May 27, 2011 3:06 PM
>> To: Templin, Fred L
>> Cc: Internet Area
>> Subject: Re: [Int-area] Steps to make the IntArea WG more productive
>>
>> Hi Fred. Sorry for being late. I started the week with a 103.8F
>> (39.9C) fever. That's all gone but I'm still moving slowly.
>>
>> > While the IRON architecture has already been published as RFC6179, I
>> > do not believe there is yet a sufficiently wide understanding of the
>> > technology such that it would qualify under your criterion of "items
>> > where proponents are having difficulty explaining concepts in mail,
>> > and for which presentation would help".
>>
>> If I understand correctly, you're saying there was discussion, but the
>> discussion didn't hit a wall, a failure of communication, and
>> you didn't
>> have trouble explaining things. What
>> happened? Did it die out? Did people believe they understood the
>> points, but you didn't believe?
>>
>> I suggest that you list the points where you think there is
>> insufficient understanding, and we start there.
>>
>> OK?
>>
>> ...Scott
>>
>
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area