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.), 
I don't know whether IETF is interested in documenting such implementation, 
Internet Area maybe the right place to discuss it.

Thanks

-Hui
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> Sent: Tuesday, December 20, 2011 1:44 AM
> To: Hui Deng; 'Andrew Sullivan'
> Cc: mif@ietf.org
> Subject: RE: [mif] IRON as a multiple interface solution
> 
> Hi Hui,
> 
> > -----Original Message-----
> > From: Hui Deng [mailto:denghui@chinamobile.com]
> > Sent: Thursday, December 15, 2011 4:23 AM
> > To: Templin, Fred L; 'Andrew Sullivan'
> > Cc: mif@ietf.org
> > 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
> fred.l.templin@boeing.com
> 
> > -Hui
> >
> > > -----Original Message-----
> > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> > > Sent: Saturday, December 03, 2011 12:56 AM
> > > To: Hui Deng; 'Andrew Sullivan'
> > > Cc: mif@ietf.org
> > > 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
> > > fred.l.templin@boeing.com
> > >
> > > > -----Original Message-----
> > > > From: Hui Deng [mailto:denghui@chinamobile.com]
> > > > Sent: Friday, December 02, 2011 1:12 AM
> > > > To: Templin, Fred L; 'Andrew Sullivan'
> > > > Cc: mif@ietf.org
> > > > 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: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On
> > > > Behalf Of
> > > > > Templin, Fred L
> > > > > Sent: Friday, December 02, 2011 4:10 AM
> > > > > To: Andrew Sullivan
> > > > > Cc: mif@ietf.org
> > > > > 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
> > > > > fred.l.templin@boeing.com
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com]
> > > > > > Sent: Monday, November 28, 2011 10:11 AM
> > > > > > To: Templin, Fred L
> > > > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org
> > > > > > 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
> > > > > > ajs@anvilwalrusden.com
> > > > > >
> > > > > _______________________________________________
> > > > > mif mailing list
> > > > > mif@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/mif
> > > >
> > > >
> > > >
> >
> >
> >