Re: [mif] IRON as a multiple interface solution

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

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