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