Re: [mif] IRON as a multiple interface solution

["Templin, Fred L" <[e-mail]>]

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
[e-mail]  

> -----Original Message-----
> From: Hui Deng [mailto:[e-mail]] 
> Sent: Wednesday, December 21, 2011 2:17 AM
> To: Templin, Fred L; 'Andrew Sullivan'
> Cc: [e-mail]
> Subject: RE: [mif] IRON as a multiple interface solution
> 
> 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
> 
> > -----Original Message-----
> > From: Templin, Fred L [mailto:[e-mail]]
> > Sent: Wednesday, December 21, 2011 3:10 AM
> > To: Hui Deng; 'Andrew Sullivan'
> > Cc: [e-mail]
> > Subject: RE: [mif] IRON as a multiple interface solution
> > 
> > Hi Hui,
> > 
> > > -----Original Message-----
> > > From: Hui Deng [mailto:[e-mail]]
> > > Sent: Monday, December 19, 2011 10:23 PM
> > > To: Templin, Fred L; 'Andrew Sullivan'
> > > Cc: [e-mail]
> > > Subject: RE: [mif] IRON as a multiple interface solution
> > >
> > > Hi Fred
> > >
> > > There are multiple places discussing virtual interface(PMIP6,
> > > DSMIP6, 3GPP
> > > GTP, Connection Manager et al.),
> > 
> > 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.
> > 
> > 
> > > I don't know whether IETF is interested in documenting such
> > > implementation,
> > > 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
> > [e-mail]
> > 
> > > Thanks
> > >
> > > -Hui
> > > > -----Original Message-----
> > > > From: Templin, Fred L [mailto:[e-mail]]
> > > > Sent: Tuesday, December 20, 2011 1:44 AM
> > > > To: Hui Deng; 'Andrew Sullivan'
> > > > Cc: [e-mail]
> > > > Subject: RE: [mif] IRON as a multiple interface solution
> > > >
> > > > Hi Hui,
> > > >
> > > > > -----Original Message-----
> > > > > From: Hui Deng [mailto:[e-mail]]
> > > > > Sent: Thursday, December 15, 2011 4:23 AM
> > > > > To: Templin, Fred L; 'Andrew Sullivan'
> > > > > Cc: [e-mail]
> > > > > Subject: RE: [mif] IRON as a multiple interface solution
> > > > >
> > > > > Hi Fred,
> > > > >
> > > > > This new interface type is also a kind of virtual interface
> > > > > which has been
> > > > > mentioned in RFC 6418.
> > > >
> > > > 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
> > > > [e-mail]
> > > >
> > > > > -Hui
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Templin, Fred L [mailto:[e-mail]]
> > > > > > Sent: Saturday, December 03, 2011 12:56 AM
> > > > > > To: Hui Deng; 'Andrew Sullivan'
> > > > > > Cc: [e-mail]
> > > > > > Subject: RE: [mif] IRON as a multiple interface solution
> > > > > >
> > > > > > 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
> > > > > > [e-mail]
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hui Deng [mailto:[e-mail]]
> > > > > > > Sent: Friday, December 02, 2011 1:12 AM
> > > > > > > To: Templin, Fred L; 'Andrew Sullivan'
> > > > > > > Cc: [e-mail]
> > > > > > > Subject: RE: [mif] IRON as a multiple interface solution
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [e-mail] 
> [mailto:[e-mail]] On
> > > > > > > Behalf Of
> > > > > > > > Templin, Fred L
> > > > > > > > Sent: Friday, December 02, 2011 4:10 AM
> > > > > > > > To: Andrew Sullivan
> > > > > > > > Cc: [e-mail]
> > > > > > > > Subject: Re: [mif] IRON as a multiple interface solution
> > > > > > > >
> > > > > > > > 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
> > > > > > > > [e-mail]
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Andrew Sullivan [mailto:[e-mail]]
> > > > > > > > > Sent: Monday, November 28, 2011 10:11 AM
> > > > > > > > > To: Templin, Fred L
> > > > > > > > > Cc: Hui Deng; Andrew Sullivan; [e-mail]
> > > > > > > > > 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
> > > > > > > > > [e-mail]
> > > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > mif mailing list
> > > > > > > > [e-mail]
> > > > > > > > https://www.ietf.org/mailman/listinfo/mif
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> 
> 
>