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.temp...@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:deng...@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.temp...@boeing.com > > > -Hui > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:fred.l.temp...@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.temp...@boeing.com > > > > > > > -----Original Message----- > > > > From: Hui Deng [mailto:deng...@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-boun...@ietf.org [mailto:mif-boun...@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.temp...@boeing.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Andrew Sullivan [mailto:a...@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 > > > > > > a...@anvilwalrusden.com > > > > > > > > > > > _______________________________________________ > > > > > mif mailing list > > > > > mif@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > > > > > > > > > > > _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
