Subject: Re: [mif] IRON as a multiple interface solution

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 1 Dec 2011 12:09:56 -0800

Hi Andrew,

I took the time to go off and look at the mif wg
documents. All of it is good work - and all of it
is compatible with IRON.

The mif documents talk about two primary classes of
interfaces: 1) ISP interfaces, and 2) VPN interfaces.
IRON introduces a third class of interface which
can be considered an "Internet interface".

While it is true that most ISP interfaces provide
access to the Internet, ISP interfaces have volatile
configuration information that can change, e.g., if
the ISP point of connection changes. Conversely, the
IRON Internet interface has non-volatile configuration
information that remains the same even if the ISP
connections change (e.g., if the node is mobile).

Since ISP interfaces may have access to private
namespaces, those interfaces (along with their
associated IP addresses) can be chosen for DNS
resolution and for accessing services within the
private namespace the same as described in the mif
documents. Since the IRON Internet interface has
a non-volatile configuration on the open Internet,
however, it provides a stable handle for default
communications with Internet-based correspondents.

Again, this is all very compatible with the mif
work, and fits like a glove with what IRON expects.

Thanks - Fred
[email-masked]  

> -----Original Message-----
> From: Andrew Sullivan [mailto:[email-masked]] 
> Sent: Monday, November 28, 2011 10:11 AM
> To: Templin, Fred L
> Cc: Hui Deng; Andrew Sullivan; [email-masked]
> Subject: Re: [mif] IRON as a multiple interface solution
> 
> On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote:
> > That said, IRON does not preclude the host from accessing
> > services within the underlying ISP networks. To do so,
> > however, the host would have to use its ISP-delegated
> > address(es) and not the VSP-delegated address.
> > 
> > Does this match your understanding?
> 
> The central problem, however, is that if you are looking up the
> address for a name, you don't obviously know where it is (i.e. you
> don't know what network you need to go to).  What I don't get in the
> IRON approach is how you cope with the fact that a user simply types
> some name into an application.  We can't hardly ask them which network
> they want to use to look up the name.  The MIF approach, as much as it
> makes me airsick, does address that issue.
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
>

---

From: "Hui Deng" <[email-masked]>
Date: Fri, 2 Dec 2011 17:12:00 +0800

Hi Fred

You are saying current MIF document is compatible with IRON.
And current MIF document has already solved MIF's issues, 
so guess that IRON is proposing something else like generic internet access
which is out of MIF.

Regards,

-Hui

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Templin, Fred L
> Sent: Friday, December 02, 2011 4:10 AM
> To: Andrew Sullivan
> Cc: [email-masked]
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Dec 2011 08:56:17 -0800

Hi Hui,

I am saying that IRON defines a new interface type
that would be one among possibly many interfaces of
a mif node. The properties of this interface type
include:

  - maintains stable network layer addresses even
    if ISP connections change
  - supports session continutity and fault tolerance
    as ISP connections change
  - avoids end user network renumbering when ISP
    connections change in case the mif node acts
    as a router

There is more to it than just this, but the IRON
interface is another mif node interface type and
therefore needs to be taken under consideration,
e.g., for interface selection, source address
selection, etc.

Thanks - Fred

> From: Hui Deng [mailto:[email-masked]] 
> Sent: Friday, December 02, 2011 1:12 AM
> To: Templin, Fred L; 'Andrew Sullivan'
> Cc: [email-masked]
> Subject: RE: [mif] IRON as a multiple interface solution
> 
> Hi Fred
>

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 15 Dec 2011 20:16:58 +0800

I agree that Andrew's argument does make sense. You can't tell which service
it belongs to just based on FQDN

-Hui

> Sent: Tuesday, November 29, 2011 2:11 AM
> To: Templin, Fred L
> Cc: [email-masked]

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 15 Dec 2011 20:23:00 +0800

Hi Fred,

This new interface type is also a kind of virtual interface which has been
mentioned in RFC 6418.

-Hui

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: Saturday, December 03, 2011 12:56 AM
> To: Hui Deng; 'Andrew Sullivan'
> Cc: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Dec 2011 09:44:00 -0800

Hi Hui, 

> Sent: Thursday, December 15, 2011 4:23 AM

Yes, I see where virtual interfaces are mentioned in
several places in RFC6418. However, that document talks
about the virtual interface *near-end* and does not talk
about the virtual link itself nor coordination with the
virtual interface *far-end(s)*.

RFC6418, Section 3.8 is consistent with what the IRON
virtual interface near end expects, but IRON goes to
the full extent of describing coordinations between
the near end and any prospective far-ends.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Dec 2011 09:44:49 -0800

Hi Hui,

I thought I had addressed Andrew's points in my
12/1/2011 post:

http://www.ietf.org/mail-archive/web/mif/current/msg01506.html

Does that post clarify things?

Thanks - Fred

> Sent: Thursday, December 15, 2011 4:17 AM
> To: 'Andrew Sullivan'; Templin, Fred L
> Cc: [email-masked]

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 20 Dec 2011 14:22:39 +0800

Hi Fred

There are multiple places discussing virtual interface(PMIP6, DSMIP6, 3GPP
GTP, Connection Manager et al.), 
I don't know whether IETF is interested in documenting such implementation, 
Internet Area maybe the right place to discuss it.

Thanks

-Hui
> Sent: Tuesday, December 20, 2011 1:44 AM

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 20 Dec 2011 14:54:44 +0800

Hi Fred,

>From your reply, it says that MIF DNS does resolve the issue compatible with
IRON, not a competing solution. 

If that is what you mean, that's fine. Thanks for discussion

-Hui

> Sent: Tuesday, December 20, 2011 1:45 AM

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Dec 2011 11:10:11 -0800

Hi Hui, 

> Sent: Monday, December 19, 2011 10:23 PM

Yes, virtual interfaces have been discussed in many contexts
for many, many years. But, the virtual interface described in
IRON is uniquely different.

The virtual interface described in IRON is an NBMA interface
that views other IRON nodes as on-link neighbors. Neighbor
coordinations such as neighbor/router discovery, NUD,
redirection, etc. are therefore supported.

IRON also uniquely solves the well known virtual interface
path MTU problem, and this is especially important for MIF
nodes that connect to diverse L2 media.

I have also already mentioned the ability to have a
persistent L3 configuration on the IRON virtual interface
even if the L3 configurations on the ISP interfaces change
dynamically. This provides significant benefits for mobility,
mobile networks, session survivability, etc. The document
also mentions several other compelling functions applicable
to MIF nodes that are enabled.

> Internet Area maybe the right place to discuss it.

IRON is not an implementation; it is an architecture.
Its functional components are VET, SEAL and AERO, which
deal with specific aspects of concern to the MIF problem
space. The four documents (IRON, VET, SEAL and AERO) go
together as a group.

Thanks - Fred

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 21 Dec 2011 18:17:06 +0800

Hi Fred

Current MIF is discussing 3GPP and BBF scenarios and problems,
If IRON is a new architecture, then it need to clarify which scenario and PS
that IRON is targeting at.

Thanks

-Hui

> Sent: Wednesday, December 21, 2011 3:10 AM

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Dec 2011 09:13:39 -0800

Hi Hui,

I'll look into the scenarios and PS, but I'll add
another thought before the holidays. IRON addresses
the commercial aviation use case, but people don't
seem to realize that modern airplanes are the
ultimate MIF nodes.

Airplanes today can have as many as 20 antennas. Not
all of them support IP links, but many do and more are
coming in the near future. Moreover, links come and go
according to phase of flight. At the gate, the plane
can expect WiFi and possibly wired-line links. In the
terminal maneuvering area there is WiMAX (and a coming
aviation derivative known as AeroMACS). Once airbore,
VHF, 3G/4G, SATCOM, etc. become available. And, SATCOM
and HF are often the only options available over the
oceans and polar regions.

So, the planes needs a way to manage this dynamically
changing collection of links and still be reachable
by correspondents such as airline operations and air
traffic control. IRON provides a means to do exactly
that, but its applicability extends far beyond just
the aviation domain and can address any MIF use cases
that I can imagine (including 3GPP and BBF). I will
explain this further after the holidays.

Thanks - Fred

> Sent: Wednesday, December 21, 2011 2:17 AM
> > > > > > > so guess that IRON is proposing something else 
> like generic
> > > > > > > internet access
> > > > > > > which is out of MIF.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > -Hui
> > > > > > >
> > > > > > > > From: [email-masked] 
> [mailto:[email-masked]] On
> > > > > > > Behalf Of
> > > > > > > > Templin, Fred L
> > > > > > > > > don't know what network you need to go to).  
> What I don't
> > > > > > > get in the
> > > > > > > > > IRON approach is how you cope with the fact 
> that a user
> > > > > > > simply types
> > > > > > > > > some name into an application.  We can't 
> hardly ask them
> > > > > > > which network
> > > > > > > > > they want to use to look up the name.  The 
> MIF approach,
> > > > > > > as much as it