From tsirtsis@googlemail.com Sun Aug 16 02:41:09 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDF93A693B for ; Sun, 16 Aug 2009 02:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uIuSfrzAAKN for ; Sun, 16 Aug 2009 02:41:07 -0700 (PDT) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by core3.amsl.com (Postfix) with ESMTP id C43DA3A69F2 for ; Sun, 16 Aug 2009 02:41:05 -0700 (PDT) Received: by fxm22 with SMTP id 22so2100516fxm.9 for ; Sun, 16 Aug 2009 02:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bgiReZbNt3C93uoIFOteLKAeZSthw88QuKZypNK4Mec=; b=Jw0WmS46tNkzKAV2Umfxk98IZu6XzYmwZ9sz68lUxtYjt/5odTXqs3IplZh5bQzR4P OrqRd8AsS4j+7vSeVKuRKKIOdRdykIF1OSp9mYGUNYE0yv4uNjAKLB/jH+bbn/Lji+nc dOvQbtG6l1Q/n55qn08gwdudw6IelqIDHPK7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dp2pO2ozOvOtszB/I3HhcuwzFKL5rku5+JejziX4InqcOXY5CNuAs5/a3OsN1NNnG5 CAkTO5KyNgqeFsDduPuulGpif+NtExNy6Gz1y/Vp7AahAqOWVOUMTfLCXlFhDkYPn1N7 pzrSZ8SVoBbadVHVNZMo71lUMzmN+flWcjlL4= MIME-Version: 1.0 Received: by 10.239.177.73 with SMTP id u9mr221713hbf.127.1250415667253; Sun, 16 Aug 2009 02:41:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Aug 2009 10:41:07 +0100 Message-ID: From: George Tsirtsis To: mif Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [mif] AMSS/Brew Multi-interface handling X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 09:41:09 -0000 Hi all, I sent this to Margaret during the IETF meeting but I did not hear back from her. Maybe it got lost in the IETF noise so I thought I might as well forward this to the list. I hope it helps. George ---------- Forwarded message ---------- From: George Tsirtsis Date: Wed, Jul 29, 2009 at 9:58 AM Subject: AMSS/Brew Multi-interface handling To: mrw@sandstorm.net Hi Margaret, Here is a description of how multi-interface support is handled by Advanced Mobile Station Software (AMSS) that comes with Brew OS for all Qualcomm chipsets (e.g., MSM, Snapdragon etc). I hope this is helpful information for draft-mrw-mif-current-practices. Let me know if you have any questions. Regards George Tsirtsis (wearing a Qualcomm hat) ---------------------------------------------------------------------------= -------------------------- Multiple Interface Handling - Qualcomm AMSS/Brew Mobile Platform AMSS supports a concept of =E2=80=9Cnetpolicy=E2=80=9D which allows each ap= plication to specify the type of network connectivity desired. =C2=A0The netpolicy contains parameters such as access technology, IP version type and network profile. =C2=A0Access technology could be a specific technology type such as CDMA or WiFi or could be a group of technologies, such as ANY_Cellular or ANY_Wireless. =C2=A0IP version could be one of Ipv4, Ipv6 or Default. =C2=A0The network profile identifies a type of network domain or service within a certain network technology, such as 3GPP APN or Mobile IP Home Agent. =C2=A0It also specifies all the mandatory parameters required to connect to the domain such authentication credentials and other optional parameters such as QoS attributes. =C2=A0Network Profile is technology specific and set of parameters contained in the profile could vary for different technologies. Two models of network usage are supported. Applications requiring network connectivity specify an appropriate netpolicy in order to select the desired network. =C2=A0The netpolicy may match one or more network interfaces. =C2=A0AMSS system selection module selects the best interface out of the ones that match the netpolicy based on various criteria such as cost, speed or other provisioned rules. =C2=A0Application explicitly starts the selected network interface and, as a result, the application also gets bound to the corresponding network interface. =C2=A0All outbound packets from this application are always routed over this bound interface using the source address of the interface. Alternately, applications may rely on a separate connection manager to control (start/stop) the network interface. =C2=A0 =C2=A0In this method, applications are not necessarily bound to any one interface. =C2=A0All outbound packets from such applications are routed on one of the interfaces that match its netpolicy. =C2=A0The routing decision is made individually for each packet and =C2=A0selects the best interface based on the criteria described above and the destination address. =C2=A0 Source address is always that assigned to the interface used to transmit the packet. Note that all of the routing/interface selection decisions are based on the netpolicy and not just destination address to avoid overlapping private Ipv4 address issue. =C2=A0This also allows multiple (logical) interfaces to be configured with the same IP address, for example, to handle certain tunnelling scenarios. =C2=A0 Applications that do not specify a netpolicy are routed by AMSS to the best possible interface using the default netpolicy. =C2=A0Default netpolicy could be pre-defined or provisioned by the administrator or operator. =C2=A0Hence default interface could vary from device to device and also depends upon the available networks at any given time. AMSS allows each interface to be configured with its own set of DNS configuration parameters =E2=80=93 a list of DNS servers, domain names etc. Interface selected to make a DNS resolution is the one to which application making the DNS query is bound. =C2=A0Applications can also specify a different netpolicy as part of DNS request to select another interface for DNS resolution. =C2=A0Regardless, all the DNS queries are sent only over this selected interface using the DNS configuration from the interface. =C2=A0 DNS resolution is first attempted with the primary server configured in the interface. =C2=A0If a response is not received, the queries are sent to all the other servers configured in the interface in a sequential manner using a backoff mechanism. From mrw@sandstorm.net Sun Aug 16 07:04:54 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D923A6D06 for ; Sun, 16 Aug 2009 07:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThhRb9oeMmOV for ; Sun, 16 Aug 2009 07:04:53 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 7BBB028C0EA for ; Sun, 16 Aug 2009 07:04:08 -0700 (PDT) Received: from [10.36.0.42] (pool-173-76-25-94.bstnma.fios.verizon.net [173.76.25.94]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n7GE42qm006907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Aug 2009 10:04:02 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <424FB149-AE77-4F63-9C18-EF04B2A20937@sandstorm.net> From: Margaret Wasserman To: George Tsirtsis In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 16 Aug 2009 10:04:02 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: mif Subject: Re: [mif] AMSS/Brew Multi-interface handling X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 14:04:54 -0000 Hi George, Thanks for sending this! I'll add it to the next version of the draft. Margaret On Aug 16, 2009, at 5:41 AM, George Tsirtsis wrote: > Hi all, > > I sent this to Margaret during the IETF meeting but I did not hear > back from her. Maybe it got lost in the IETF noise so I thought I > might as well forward this to the list. > > I hope it helps. > > George > > ---------- Forwarded message ---------- > From: George Tsirtsis > Date: Wed, Jul 29, 2009 at 9:58 AM > Subject: AMSS/Brew Multi-interface handling > To: mrw@sandstorm.net > > > Hi Margaret, > > Here is a description of how multi-interface support is handled by > Advanced Mobile Station Software (AMSS) that comes with Brew OS for > all Qualcomm chipsets (e.g., MSM, Snapdragon etc). I hope this is > helpful information for draft-mrw-mif-current-practices. > > Let me know if you have any questions. > > Regards > George Tsirtsis (wearing a Qualcomm hat) > > = --------------------------------------------------------------------------= --------------------------- > > > Multiple Interface Handling - Qualcomm AMSS/Brew Mobile Platform > > AMSS supports a concept of =93netpolicy=94 which allows each = application > to specify the type of network connectivity desired. The netpolicy > contains parameters such as access technology, IP version type and > network profile. Access technology could be a specific technology > type such as CDMA or WiFi or could be a group of technologies, such as > ANY_Cellular or ANY_Wireless. IP version could be one of Ipv4, Ipv6 > or Default. The network profile identifies a type of network domain > or service within a certain network technology, such as 3GPP APN or > Mobile IP Home Agent. It also specifies all the mandatory parameters > required to connect to the domain such authentication credentials and > other optional parameters such as QoS attributes. Network Profile is > technology specific and set of parameters contained in the profile > could vary for different technologies. > > Two models of network usage are supported. > > Applications requiring network connectivity specify an appropriate > netpolicy in order to select the desired network. The netpolicy may > match one or more network interfaces. AMSS system selection module > selects the best interface out of the ones that match the netpolicy > based on various criteria such as cost, speed or other provisioned > rules. Application explicitly starts the selected network interface > and, as a result, the application also gets bound to the corresponding > network interface. All outbound packets from this application are > always routed over this bound interface using the source address of > the interface. > Alternately, applications may rely on a separate connection manager to > control (start/stop) the network interface. In this method, > applications are not necessarily bound to any one interface. All > outbound packets from such applications are routed on one of the > interfaces that match its netpolicy. The routing decision is made > individually for each packet and selects the best interface based on > the criteria described above and the destination address. Source > address is always that assigned to the interface used to transmit the > packet. > > Note that all of the routing/interface selection decisions are based > on the netpolicy and not just destination address to avoid overlapping > private Ipv4 address issue. This also allows multiple (logical) > interfaces to be configured with the same IP address, for example, to > handle certain tunnelling scenarios. Applications that do not > specify a netpolicy are routed by AMSS to the best possible interface > using the default netpolicy. Default netpolicy could be pre-defined > or provisioned by the administrator or operator. Hence default > interface could vary from device to device and also depends upon the > available networks at any given time. > AMSS allows each interface to be configured with its own set of DNS > configuration parameters =96 a list of DNS servers, domain names etc. > Interface selected to make a DNS resolution is the one to which > application making the DNS query is bound. Applications can also > specify a different netpolicy as part of DNS request to select another > interface for DNS resolution. Regardless, all the DNS queries are > sent only over this selected interface using the DNS configuration > from the interface. DNS resolution is first attempted with the > primary server configured in the interface. If a response is not > received, the queries are sent to all the other servers configured in > the interface in a sequential manner using a backoff mechanism. > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > From denghui02@hotmail.com Wed Aug 26 09:29:18 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0883A69AA for ; Wed, 26 Aug 2009 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.324 X-Spam-Level: *** X-Spam-Status: No, score=3.324 tagged_above=-999 required=5 tests=[AWL=-2.987, BAYES_20=-0.74, HTML_MESSAGE=0.001, MANGLED_PRBLMS=2.3, MANGLED_REALLY=2.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR7T6u9YSiG2 for ; Wed, 26 Aug 2009 09:29:12 -0700 (PDT) Received: from col0-omc2-s13.col0.hotmail.com (col0-omc2-s13.col0.hotmail.com [65.55.34.87]) by core3.amsl.com (Postfix) with ESMTP id ECE133A6EED for ; Wed, 26 Aug 2009 09:29:11 -0700 (PDT) Received: from COL118-W43 ([65.55.34.72]) by col0-omc2-s13.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 09:28:35 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_cf4f2cd0-ca99-4a12-85b2-e8955f26819e_" X-Originating-IP: [221.223.75.245] From: Hui Deng To: , Margaret Wasserman Date: Thu, 27 Aug 2009 00:28:35 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Aug 2009 16:28:35.0414 (UTC) FILETIME=[424BE760:01CA266A] Subject: [mif] draft MIF minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 16:29:18 -0000 --_cf4f2cd0-ca99-4a12-85b2-e8955f26819e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello, all Thanks Carl for taking the detail minutes, Please feel free to comment on it, Many thanks -Hui MIF Working Group Meeting (IETF 75) The MIF working group was held at IETF 75 Stockholm at 9:00am on Tuesday, July 28, 2009 in Room Large Stage. Chairs: Margaret Wasserman and Hui Deng 1. Preliminaries (5 mins Chairs) - Blue sheets - Note takers: Carl Williams - Jabber scribe: Aleksi Suhonen - Agenda Margaret: goes over the agenda. Said we will go over problem statement and that we will have good amount of time for it. Then the MIF best practices document which Margaret said she will do. Then the session will allow presentations that didn¡¯t get a chance to discuss during the BOF. ------------------------------------ 2. Problem Statement presented by Marc Blanchet (1 hour) http://www.ietf.org/proceedings/75/slides/mif-2.pdf http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-01.txt http://tools.ietf.org/html/draft-williams-mif-problem-scenarios-00 Marc stated that the context of this presentation is to go over the changes of the draft -00 version submitted in San Francisco with the recent changes now in -01 version that was submitted prior to Stockholm meeting. Marc began by going over the objective of the draft -01 revision. He said that the wording is much closer to the charter that was processed after San Francisco. Marc said that he integrated comments from the BOF, mailing list and spent time on each email so that the comments that he agreed were represented in the draft. Also, for this new version he attempted to have formal wording in particular on MIF definition. He also read the other drafts on other problem statements and he got the impression that people think of MIF differently. Therefore, the problem statement defines MIF what it is exactly. While it doesn¡¯t seem to be simple, but there are a few things that remained to be defined or agreed on. Marc says that he thinks it is appropriate to define that piece correctly so that we know what we are talking about and that we are all on the same page. Marc also stated that the goal of this the -01 version is to use consistent vocabulary throughout the draft. Definition is one of the open issues from Marc¡¯s point of view (may have more). Marc said he attempted to define a MIF host somewhat firmly. Marc stated that it is (*) a IPv4 and/or IPv6 compliant host (*) configured with more than one IP addresses (excluding loopback, link-local) (*) on one or more active interfaces, as presented to the IP stack (*) The interfaces may be logical, virtual or physical (*) The IP addresses may be from the same or from different address families, such as IPv4 and IPv6 (*) communications using these IP addresses may happen simultaneously and independently (*) while the MIF host may forward packets between its interfaces, forwarding packets is not taken into account in this definition. (*) The IP addresses come from more than one administrative domains. George: Asking if one or more active interfaces are presented to IP stack (or not presented to the IP stack) and one virtual interfaces. (multiple physical interfaces but a virtual interface that hides all of it). Is that MIF? Gabriel: I think that George¡¯s question was not whether there may be several logical or physical but that the total of those that there is only 1 seen by the IP stack ¨C is this MIF? I think that the answer it is not. Marc: no Gabriel: If something under IP hides it like for example in multi-technology handover that is not MIF. Margaret: I don¡¯t necessarily agree. The charter does say that we may have a node that has only 1 interface but that is attached to more than 1 domain and still may need some of the MIF stuff. We are talking about the properties of the solution that we aren¡¯t charter to talk about yet. I don¡¯t think that we want to rule out the possibility of that our solution might imply that for instance you had a device that say is attached to a Bluetooth link to your laptop but then your laptop has access to two different administrative domains and that device still may need to worry about two different sets of configuration information in terms of service location or reaching particular internet sites, etc. Sri: What is seen from the IP stack perspective is logically one interface assuming that those physical interfaces are under bridge mode. This is implementation dependent ¨C under what scenario I might be putting multiple interfaces 1 or 2 and putting logical virtual interface and abstracting both of them and both of them can have a bridge mode and I still may be using those physical interfaces as real interfaces too. So both are possible. George: Just to give a specific example in the IETF we have technologies that hide interfaces underneath it. Mobile IP, PMIP ¨C are technologies where we develop them where they look like layer 2. Not completely transparent to IP. In some cases these technologies takes IP interfaces and wraps them around another interface and presents that to the operating system. Maybe from this point of perspective that this is out of scope. We have to make a decision if it is out of scope. We have to decide if that is the case. Marc: That makes sense. Sri: How the interfaces are wrapped up ¨C at the end what is seen from an IP perspective I think that is the clear part of the definition. Margaret: I think that this is very open right now. It is one or more interfaces of any type. If a device has no interfaces at all then obviously it is not even a network node as we can¡¯t do much with it. I think that we want to keep this open because didn¡¯t want it to be the restrictive thing. We didn¡¯t want it to be like well it only has one physical interface so it is not MIF even though it has a VPN connection and a local network connection over the same Cisco interface. We are not talking about a host with two physical interfaces necessarily. There are plenty of cases where there is one physical interface but in sense two logical interfaces. The problem is that we are getting into terminology issues for particular implementations. Some people implement VPN as a logical interface whereas some people may implement it at a slightly higher level in the stack and you may still have a problem where you reach some services if you talk over your VPN and you can¡¯t reach those services if you talk over the global Internet. Gabriel: The important concept is visibility to the IP Stack. Visibility of what. There we have active interfaces. From this discussion it seems that it¡¯s not just the fact that they show up as completely separate active interfaces. But the fact that they show up in some sense of configuration related invisible to the IP stack - for example DNS. Even if they appear to have one active interface there may be other reasons why they are MIF ¨Cas long as they are visible to IP stack. Is this closer to what we are talking about. Margaret: I think so. George: So basically what you just said so the 3rd sub-bullet is actually what you mean and that is what I want to clarify. The 3rd sub-bullet says that ¡°on one or more active interfaces, as presented to the IP stack¡± and by this we exclude cases where something is done to the host that hides other interfaces that might exist. If you hide the other interfaces, then we don¡¯t have to do anything about those. And we only have to do something about those interfaces that are presented to the IP stack. Marc: So the wording is appropriate. Hui: I thinking that he is saying that you are excluding that case and he is recommending that you include that. Margaret: I don¡¯t know if there is a misunderstanding. One or more covers all possible cases. Zero is not interesting. There is 1 or there is more than 1. Marc: But presented to the IP stack. Margaret: Yes, the IP stack will always have at least one interface presented in any network node. Marc: But the point of George is that there are other multiple interfaces but not presented to the IP stack but we are not talking about those. We are only talking about interfaces presented to the IP stack. Margaret: Right. We are talking about IP node. I suppose if it had interfaces that don¡¯t run IP. One or more covers all cases as far as interfaces and then the next one as far as we know ¡°logical, virtual, physical¡± covers all the types of interfaces. We are saying it may be a device has only one interface it may be one logical interface presented to the IP stack like a bridged interface or something like that underneath it has two physical interfaces. Or it could be a complicated layering of interfaces and we don¡¯t require that two of them to be presented separately to the IP stack. It could be that two physical interfaces that are bridged into one logical interface and that is the only interface that the IP stack sees. Right Marc, potentially. Marc: That is what I understand. George can you clarify your point that I understood that is what is on the screen is what you agree. Lars: I think that what the disconnect is if you have multiple interfaces but that if there was something that would hide them ¨C that you only see one at the IP layer. But that there was some configuration information; for example, you see the two pieces of DNS information but you only saw one interface. Is this something that MIF would deal with or would we assume that whatever hides these interfaces would also aggregate the different configuration information correctly so that if you see one interface you can assume that you don¡¯t have MIF? SRI: There are multiple cases. Let¡¯s take an example there is eth0 and eth1 and on top of that I created a virtual interface V0. In what scenarios are eth0 and eth1 hidden from stack and what is presented to the stack is V0. In another scenario same configuration I am also using the physical interfaces and at this point I have 3 interfaces eth0, eth1, and V0. In this second case all three interfaces are presented to the stack. So we should clearly allow both of these scenarios. So when the interfaces are hidden it is in the first scenario and not the second scenario. So what we mean by hidden we must be very careful here. Marc: I think that the current wording says your second scenario you see three interfaces and the first scenario you see one interface. That is my understanding of the wording. Comment: I wonder if there is ambiguity in the wording ¡°presented to the IP stack¡±. If we say presented to the ¡°IP layer¡± or presented ¡°by the IP layer to higher layers¡± I think this may be clearer. Margaret: We have a lot of ambiguity in the world. You could say add layer 2 interfaces and then someone would say ¡°what about VLAN¡±. There are no words you can use where we all agree means the same thing. I thought that ¡°presented to the IP stack¡± is clear that it meant was presented to the bottom of the IP stack but it seems that you don¡¯t think that¡¯s clear. Comment: Presented from the bottom to the IP layer. Gabriel: I agree on number 3 bullet which is definitely MIF. What I was trying to say was maybe that is not everything that is all MIF. What we really mean and I don¡¯t think we have a good word for it not just interfaces but configuration stuff that belongs to different domains or separate network regions or something. And the IP stack has to deal with these separate configuration pieces like different DNS servers or whatever. It may not show up as something as an interface logical or whatever. It may not necessarily have to show up as something like that. The granularity may not be that large. Marc: In other words you are saying that we should not talk about interfaces. Gabriel: I think that what we are talking about is different configuration information that pertains to different networks or different domains (some word needed here). Margaret: Maybe we can call it different administrative domains or configuration domains or provisioning domains or something like that. Gabriel: Provisioning domains imply that someone is doing for you. Margaret: We explicitly included in our charter the idea of a node that has one interface. But the simplest case it has an Ethernet interface that is presented all the way up the stack as a single interface it only has one but that interface may be the way that the node connects to more than one configuration domain. That node may still have more than one IP address; it may still have more than one default router; it may need to use different DNS servers to get domain names in those different administrative domains. It may have services that it wants to reach that can only be reached using one of them so it needs to be sure to use the right outgoing source address at default gateway information to reach that service even if it only has one physical interface. During the charter discussion which happened after we choose the name of the group the decision was made that this would be in scope for this working group to consider. George: Maybe the solution to this is indeed to move away from terms like ¡°interface¡± and ¡°IP stack¡±. Instead to focus on the minimal set of information that makes a single uninteresting device ¨C what is that set of information? Set of information can be presented in many different ways: virtual ones, different configuration for different domains, etc. What is that ¨C the default router, the IP address or both of them or different dns as well? Marc: Agreement that we should remove the concept of the interface as we¡¯ve been talking about. Margaret: Says that Jari has comment on jabber that she will read: ¡°I think it is crucial what is visible to IP. Some L2 schemes hide everything from IP, and I don't think that is a topic for MIF. However, it is possible that even if you see one virtual interface from IP perspective, IP sees multiple routers/prefixes that represent different domains. This would reveal some of the substructure of the virtual interface.¡± Margaret: I think that he is referring to the same scenario as I am where you have one virtual interface but you have for instance two different routers. Margaret: Someone else on jabber is suggesting that a MIF host is a host that connected to a different number of multiple domains. Marc: That is another bullet. It appears that we are moving toward removing the concept of interface. Margaret: We have generalized the concept of an interface to include all possibilities so I suppose we might as well just remove it. The only possibility that we don¡¯t include anymore is no interface. Sri: Don¡¯t know what the issue is. Third bullet is ok. Don¡¯t know why get rid of ¡°interface¡± from definition. It is fine. Margaret: Thinks that marc should continue on with slides. Marc continued on with the presentation. Gabriel: On the last bullet where you say ¡°The IP addresses come from more than one administrative domains¡± - where you say ¡°more than one¡± I think this starts to captures my point. My other point is that I don¡¯t think you have to limit it to IP addresses. You can have one IP address but you may have different configurations of services for example. You have more than one domain in which to access those services. It may not be tied to interface ¨C it is tied to something configuration at least. Marc: But not an interface. Gabriel: That is part of it but it is deeper ¨C it is finer granularity than interface. I think when we say interfaces we say oh that are how we handle blobs of configuration. Even if the interfaces weren¡¯t there we could still handle blobs of configuration. I think that the final bullet is starting to get to that. Marc: Your proposal is more than one. George: Does that mean that you might have two interfaces on the same domain that is not MIF anymore? Margaret: It depends on what you mean by MIF. To say something is like MIF ¨C MIF doesn¡¯t exist. We are trying to develop a solution for the case where a single host is connected via one or more IP interfaces to more than one administrative domains. I think that is the problem that we are trying to focus on here. It is only in need of a solution if there are specific configuration information associated with those domains that is different or if you can reach different services over those two domains. So there is some reason you will need to actively choose between them. If you have two interfaces and they both go out to the global Internet that might be a multi-interface host but it is not clear whether if that host has a problem today ¨C I am not sure. Marc: It is like a table. We have interfaces and administrative domains. Maybe we are targeting two boxes in this table which is two interfaces and one administrative domain or one interface and more than one administrative domain. Would this make sense? Lars: How does host tell if different administrative domain. Is it different and if you can¡¯t tell is this MIF. Marc: I don¡¯t think that the purpose of the definition is that the host knows this but it is more for defining the use case so we know which use case we are working on. Lars: how do I know if I am connecting to different administrative domains? The MIF mechanisms ¨C whatever they will be ¨C are in effect or I just won¡¯t do it. Marc: I agree with your point. Someone on the mailing list said that the idea of more than one administrative domain actually to withdraw any misconfiguration of the network operator ¨C we don¡¯t want to talk about people who configure their network incorrectly. The idea is to remove some of the use cases that we don¡¯t want to talk about. Lars: I understand that you want to limit the charter and you have identified some of the scenarios you want to support. My point is that I am not sure that the host knows when it is one of those scenarios and when it isn¡¯t. Marc: I agree with you. Margaret: Part of the solution or at least some discussion of the analysis will be how the node does know. I don¡¯t think it matters how many domains your connected to if you only have one IP address and you only have one default router and you only know one DNS server obviously you don¡¯t need a solution. If you know of multiple of those you need to know I guess ¨C if you know of two DNS servers than you kind of need to know are these 2 DNS servers the backup of the same one or are they 2 DNS servers offered by different providers where different services might be available by looking them up in the two different service. I think it is tricky to know if you have one physical interface and 2 DNS servers configured which one of those cases it is without some additional information like if you got 2 DNS servers and one of those you got from DHCP and one you got through some pdp provisioning because your some kind of cellular interface ¨C then obviously you know their different domains. But if you get them from the same domain DHCP server then you might have to might have to make the default assumption that it is one domain unless you have some other knowledge that it is more than one domain. Lars: You need to have a mechanism that it is more than one. Teemu Savolainen: Are they always different administrative domains or same administrative domains. Gabriel: It might be more than 1 administrative configuration blobs than administrative domains. I agree that the hard part is in knowing that these configuration blobs are different and you have to deal with them separately. Maybe that is part of the problem that we have to identify here ¨C how you tell that these are administratively different configuration blobs. Marc went on with his presentation: Marc said that the change in the symptom section now has a technical abstract for each scenario. Marc went over a few other minor modifications. Marc stated that he will include Section 3 of draft-williams-mif-problems-scenarios-00.txt for next -02 release. Marc requested that the working group accept this draft as a working group document. Margaret asked the working group how many read the draft. Many people raised their hands. Then she asked how many people accept the document. Numerous members raised their hands. Margaret says that this a pretty good show of hands. Margaret asked is there anyone who doesn¡¯t think that we should accept the document as a working group item. No one raised their hands. It was decided to publish it as a MIF working group document. --------------------------------- 3. MIF Current Practices (Margaret Wasserman, 15 min) http://www.ietf.org/proceedings/75/slides/mif-1.pdf http://www.ietf.org/internet-drafts/draft-mrw-mif-current-practices-02.txt Margaret went over new revisions to the MIF current practices. Margaret says that it is not been updated since BOF. She will go over revisions she has for the document. Margaret went over the goals of the document. Margaret stated that the goal of this document is to collect information about existing implementations that are already out there dealing with this problem and how they deal with having multiple physical or virtual interfaces or how they deal with having multiple sets of configuration information. And then after we collect the information to generalize or categorize those solutions to understand what the current practices are in the field in this type of situation and then to identify gaps that require further improvements. Margaret said that we may find that the combinations of what is already out there is sufficient and then what we want to do is just to write a document that says when you have these type of solutions the best current practice is to do X, Y and Z. Or that we may find that there is a lot of stuff out there that has promising solutions in this space but that there are still holes that aren¡¯t really solved in real world implementations today. We don¡¯t know which ones of those situations it is going to be in until we get all this information together. Margaret said that not everything has been realized in the current version of document. Right now it is just cataloging existing implementations and starting to do sub-categorization. Little tricky in writing this document ahead of reaching consensus on what should be in this document. Margaret stated that the current systems she has provided analysis on are: - Nokia S60 - MSFT windows Mobile 2003 - Blackberry - Google Android - Arena Connection Manager - MSFT vista - MSFT windows server - Linux and BSD operating systems - Apple MAC OS X Margaret says that there were 2 general approaches: First, applications (or user) choose a ¡°connection¡± among available choices Margaret says this is more common in mobile/cell phone environment. She stated that all configurations stored on a per-connection basis and that after initial selection, all communication (including DNS, if any) uses the indicated connection. Margaret noted that a ¡°connection manager¡± may be provided. The second approach Margaret mentioned is that DNS, address selection and interface selection are performed separately. Margaret stated that this is more common in general-purpose operating systems. Margaret stated that DNS invoked by application, remote address chose from list returned, local address chosen to match, packets sent to default gateway. She stated that a DNS server list, default gateway (& other routes, if any) are stored on a per-system basis. Margaret stated that in those cases of the general operating systems one of the solutions that people are using in order to reach one set of services from one interface and another set of services from another interface use this Split-DNS concept. Margaret says that current implementations fall into two groups: (1) DNS server list configured on per-host basis; (2) DNS server list configured on a per-interface basis. Margaret states different OSes use server addresses from lists in different orders/combinations. Margaret says that in all cases, DNS queries are sent using a source address and outbound interfaces selected by the IP stack. For example, the address and interface are not tied to the interface on which the DNS configuration was received. Margaret said that for interface selection hosts fall into different categories. Margaret stated that it is really hard to categorize because if you read the draft you will see that every single one of them does things differently. Margaret stated that for interface selection you select an outbound interface and next hop destination as a multi-step process. Margaret said that what typically happens you get a destination address from the application ¨C in most cases hosts are getting one destination address from the application even if the DNS returns multiple addresses. In some cases they may receive a list of possible addresses. So you get one or more destination addresses and if that the destination address is on a local link, address resolution (i.e. ARP) is performed on the corresponding interface, and the packet is sent directly to the destination. Routing table gets used if not on local link. Many times you will have problems with this. Margaret pointed out that if I am on two networks: one of the is the global network 192.x.x and the other one is the VPN network 10.2.1.X and that I want to go to net 13 ¨C if I do a longest match lookup it is going to match net 10 interface and that is not what I want. So a lot of these longest match lookups are moderated by a lot of other knowledge like the net 10 addresses or the local addresses. But if you are not using some type of local addressing and you are just using two sets of global addresses on your two links you can get a case where your best match lookups have you sending traffic out of an interface that can¡¯t reach the place you are trying to go even though your interface with a shorter match can reach where you are trying to go. This is where the MIF problem comes in. Margaret stated that maybe you don¡¯t even have a routing table. Many nodes only have a routing table if they received an ICMP redirect ¨C so you are going to fall back to your default route and then you are going to look at your default router list which is another complex process that nodes do differently. Margaret stated that default router list configuration fall into two groups: (1) per-host default router lists; (2) per-interface default router lists. Margaret stated that in general the default router with the lowest metric is chosen for outbound traffic. Margaret stated that all this is pretty arbitrary in terms of that these nodes have no idea when they are choosing the default router which is going to become the destination to which they are going to send these packets ¨C what interface they are going to send these packets out. They don¡¯t know when they are choosing the default router anything about how they found this service. Margaret pointed out the example if the node had two interfaces A and B and the node got a DNS server from interface A and I looked up this service over interface A if the address that I am using is not in my routing table and I fall back to my default router as a top router in my router list is interface B then I am going to send the packet that way without any knowledge that interface A might be a better choice. Comment: In a number of scenarios all interfaces are not equal; they may not have equal costs; they may not have preference to security; etc¡­ these factors you need to consider you when you do the selection. Margaret: In the implementations document so far these things are not taken into account. There are cases where the user is asked but what reasoning the user uses in their brain I can¡¯t vouch for. Inside the applications there doesn¡¯t seem to be a way in any of the ones we cataloged so far for the user to insert any sort of policy that says I want some to be preferred over others. Margaret went on to say that packets would be sent out of the interface of the default router that has been selected via this kind-of arbitrary process. The destination address if it is even considered in picking the default router list. Margaret said that in the previous example we talked about longest match ¨C but that cases of most hosts sit out there with no entry in there routing table except the default router and they fall right back to the default router they picked one without regard to the how the source addresses they can use on that interface relate to the destination address that they are trying to get to. Margaret went over Address selection. Margaret stated that the destination address section in almost all cases will be chosen by the application based on DNS lookup results or some type of application-level configuration. Margaret stated that source address selection may be done by the application. If not, implementations vary in what they choose: (1) first address on the outgoing interface (most common); (2) more complex selection mechanisms that involve choosing the best match for the destination address, such as RFC 3484. Margaret stated that we have a situation where you can see that if you use the IETF standards a lot of stuff is not coordinated. Margaret explained that you have a node; you have an application running on that node; that application chooses a destination address ¨C passes it into the stack; a complex routing mechanism is used often in resulting in an arbitrary default router selection which is then to select the outbound interface; the source address often chosen without really any concern as to the destination address it used but merely to match the outbound interface. You often get cases where a node could reach a particular service or a particular address but does not reach that address because it sends traffic out the wrong interface. Margaret stated that moving forward she needs more information on more implementations; Margaret says that most mobile nodes do better than this in practice. Here the application is fully pre-provisioned of where it wants to go. That results in better user experience but is probable not practical for ordinary internet applications as a solution. But if people have good solutions or different solutions to these problems either in that cellular provisioning area or in DNS, default router, source address selection area it would be great to hear about them. Margaret also stated that she needs to group implementations and provide more consistent information about them. Margaret concluded by stating that common solutions section needs to be expanded. She let everyone know that if anyone is familiar with an implementation that is not included, try to send text to her. Margaret said if you are familiar with an implementation that is not included, please send text. Comment: You mention two generic approaches. My question is once connection selection is established than MIF is not an issue after connection? Margaret: Again, I have a really difficult problem with the use of MIF as a proper noun because there is no solution that exists. And I think that we would like our solution if it exist someday to apply to mobile nodes as well as other nodes as you have increasing convergence between those devices so you got a device with a 3G interface and a 802.11 interface and it would be good if that type of device could benefit from whatever solution we come up with here. So I don¡¯t want to rule that out of scope if that is what you are asking. Margaret followed up by saying that let us not assumed that just because it is called a ¡°connection manager¡± that it is a really cool and sophisticated thing. Margaret stated that in many cases what this connection manager does is to display a dialogue box and ask the user what interface to use. In other cases it decides behind the scenes very often using things like you are using the application you got from your cellular provider so use the cellular interface. It is not like it is making some highly skilled carefully tuned policy decision. Margaret stated that if you have only one connected interface and only have one connected administrative domain it has nothing to do with MIF. Right now they are constraining it as they don¡¯t have an answer to the multi-interface case. They are only bringing up one interface at a time. They are asking the user which one to bring up. Margaret said she hopes that we can do something much better than that. And it will apply to those devices but I agree that if you already decided to bring up one interface then you don¡¯t need MIF. George: Connection Managers become increasingly more intelligent over time. Also my question is should this document also get into soft interfaces? Things that are happening because you have software on top that created different situations. Margaret: It may be the case that they change the default behavior in which case they would get another entry. I want be concrete here and list specific information about specific implementations. So if there is one of those types of things that you know about and can categorized or give us any insight into its behavior with respect to the things that are mentioned in this document then you should write it up and we will give it a new section. George states that he has information of how multi-interface support is handled by Advanced Mobile Station Software (AMSS) that comes with Brew OS for all Qualcomm chipsets (e.g., MSM, Snapdragon etc). He feels it might be helpful information to the current practices draft for MIF. He will send the information out to the MIF alias. Someone raised about including ICE. Margaret responded by saying that she doesn¡¯t know if it applies here but if someone does know about it and if they want to write up how it addresses these questions; how it addresses the problems in the MIF problem statement; Margaret would be happy to include it in the next revision of the draft. Lars: ICE is an application layer of your respective protocol or library that wants to have a functioning IP connectivity over multiple then it will figure out which to use for the application. Don¡¯t be too clever here. Don¡¯t try to solve this problem for the applications. Just make sure IP path configuration that you are getting is correct ¨C that actually works. Leave the rest to things like ICE. Another example of something ¨C in the transport area we are having a bof on multi-path TCP. It is not clear that we are going to do any work in the IETF but if we do that would lead to TCP wanting to send packets along different paths over the network. Obviously MIF would be something that makes that those paths work but if you hide them from ICE then you are not doing any good. You are taking control away from the application higher layer. Margaret: Says she would argue what we are doing now in the world is interfering with those sorts of things. Not because it is too clever ¨C I am not sure that is the right thing ¨C but because it often throws away configuration information or obscures the ability for upper layers to know what influence or anything about how the packets are going to be routed. And you could have the situation where you are trying to use two different destination addresses to try to go two different directions ¨C you don¡¯t go two different directions because you go out the default gateway. Lars: I agree that what is currently deployed is not good. I hope that whatever MIF comes up with will makes things better and not worse in a different way or not fit. Margaret: One of the things that I think is pretty clear that we need in a solution is a way that the applications can actually specify not just destination and source address to use but what interface to use. And possible what default router to use. How they do that whether it comes from a list that was collected in a different layer ¨C I don¡¯t really understand all the parts of it. Right now that is not what you get. Right now what you get is you want to go to a particular destination and you send it down and where they packet gets sent is decided by a process that can¡¯t really be controlled by the application layer or the transport layer. I think of DNS as an application so I am not trying to leave transport out. Things above IP are really not getting a chance to really control that. Gabriel: During the BOF we had slides on that point (going back to what Lars said). We listed a bunch of things at the IETF that deals with multiple interfaces, multiple sets of configuration objects, stuff like that... There were a number of IETF work (SHIM6, etc) that were noted and it was stated that there was some overlap and that this should not interfere with that. Margaret: If someone wants to write-up some of these things we can include them in the current practice draft. Even if we create a different section that says ¡°things that need to interact with this stuff¡±¡­. Hui asked the working group how many people read the draft. Hui then asked how many people think that this document should be adopted as working group. A fair number of people read the draft. Many people thought that the draft should be adopted as a working group document. The chairs stated that there are three drafts that aren¡¯t part of the charter but that they will provide time to cover. ------------------------------------ 4. MIF Analysis and Scenarios (Yong-Guen Hong, 15 min) http://www.ietf.org/proceedings/75/slides/mif-4.pdf http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-01 Yong-Guen stated that the goal of the draft is to identify problems of MIF with the focus on real routing issues. He stated that there is relation between network interface and destination address. There is consideration for asymmetric routing path. Yong-Guen also stated that the goal of this draft is to describe usage scenarios of multiple interfaces. Those are in two categories: A host with single interface to multiple networks and a host with multiple interfaces to multiple networks. Yong-Guen presentation and draft goes into details on these two areas ¨C problems and the scenarios. Yong-Guen slides detail very specific scenarios cases that were presented in his draft. Margaret asked how many people have read this draft. Margaret cited that a few raised their hands. Margaret asked if people thought it would be useful to add these type of usage scenarios to our problem statement? Question at MIC. Gabriel: Why is layer 2 scenarios ¨C multiple layer 2 you have in your scenario list. Why is that relevant to MIF? I think that this was out of scope ¨C these scenarios. Margaret: I am open to the possibility that perhaps this scenario exist whereby you have one l3 interface and 2 layer 2 interfaces and you are getting configuration information from 2 different domains. But don¡¯t know if this is possible but open to idea. Jonne Soininen: I agree with Gabriel that these scenarios are really not needed here because these l2 interfaces don¡¯t configure the IP stack. The case we are talking about it does look like one interface all of the time. You always just have one IP address and API of the IP stack doesn¡¯t see a change. Margaret: There is one administrative domain even though there are two layer 2 interfaces here. Jonne: Yes. The IP stack doesn¡¯t know that there are multiple layer 2s. It looks at it as there is one layer 2. Will Ivancic (NASA): Marc mentioned that there is a plan to incorporate the scenario section of Carl Williams¡¯ draft. I think that is a more generalized set of scenarios and is useful to include. Margaret stated that the next presentation is on MIF Security. ------------------------------------ 5. MIF Security Considerations (Nam-Seok Ko, 15 min) http://www.ietf.org/proceedings/75/slides/mif-3.pdf http://www.ietf.org/internet-drafts/ draft-ko-mif-security-considerations-00.txt Nam-Seok stated that the goal was to review over security considerations for MIF. Nam-Seok went over three slides of various security considerations for MIF in his presentation. Nam-Seok stated that this was a preliminary look at security analysis for MIF and that he only wanted to get the discussion on security. Nam-Seok wanted feedback on the issue of security for MIF. There was discussion on some of the requirements in particular on the requirement of unwanted injection of configuration objects targeted to specific interface(s) to other interfaces. Margaret: If the MIF solution is something like a configuration policy manager, it might be the case that there is a way to inject and even read a configuration for your own domain but not for some for somebody¡¯s else domain. Gabriel: Unless you have access rights or something. Margaret: Then that security requirement may be a very good requirement. Gabriel: It has to be re-worded in terms of access rights or administrative rights. Margaret: Until we know whether the solution has a concept of different administrators who may have different rights I think it is really hard to write the right security wording around that. I don¡¯t think we know enough about the solution to know what the parties are. For security considerations you have the things you want to protect and you have all the parties and you know which parties get access to what and what you want to protect from whom and I think that we don¡¯t know yet much about the solution to populate that table. Nam-Seok: This is a very early straw-man attempt at identifying some security issues just to get some preliminary discussion going. Margaret: I think that it is great to start thinking about security right away. And I think that as things start to evolve we will know more about what this document needs to say. I think that it is going to be really important as we do the analysis document that we include in that some understanding of ¨C that is going to be gap analysis ¨C what I think what will be missing is any idea of separating security domains and different access controls for different domains and so forth and this will come into play. Gabriel: Perhaps an initial first stab would be just the threat model. And leave all the language of requirements ¨C thou shall do, etc¡­ - out of the document. As we probable don¡¯t understand it until we have a threat model. That would be a necessary first step. Margaret: I think so. Margaret stated that we have one more presentation by Teemu. Margaret stated that we ran out of time during BOF for Teemu to present so now he has the opportunity. ------------------------------------ 6. MIF DNS Server Selection (Teemu Savolainen, 15 min) http://www.ietf.org/proceedings/75/slides/mif-5.pdf http://www.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-selection-00.txt Teemu spoke of Split-DNS and what Split-DNS is. Teemu says that the host receives recursive DNS server addresses from multiple network interfaces, but some of the DNS servers may serve information other do not. Teemu stated that some have unique information not available on others. For example, IP addresses for private FQDNs. Teemu stated that some serve different information for the same query. He provided an example FQDN results in different IP addresses from different interface¡¯s name servers, and even worse, same FQDN may result in IP addresses of completely different network entities/services. Teemu went over what a MIF host should be able to accomplish. He stated to send queries to DNS server able to answer properly and to use resolved IP addresses on the interface they work on. Teemu pointed out problems. For example, how to select right DNS server? Also, the source/destination address selection algorithms are not suitable, as no destination IP addresses are available. He also pointed out that the ¡°second interface¡¯s¡± DNS server might be able to serve even if ¡°first interface¡¯s¡± DNS server returned negative reply. Teemu then went over solution approaches. He said that avoid setting-up split-DNS (avoid creation of the problem). He also stated that BIND applications to specific interfaces. Finally, Teemu stated we need to come up with optimized DNS resolution algorithm. He proceeded with a slide on possibilities for the algorithm. Teemu says that MIF is chartered to work on problem statement, existing practices and analysis. Teemu asked how many people are interested on this problem? George: I think that split-DNS issue is water under the bridge. We can not avoid split-DNS ¨C it is everywhere. All of our companies do it. I am not an DNS expert but I don¡¯t even think that there is a way when you get a DNS address to know it is split-DNS or not? Is that correct? Teemu: yes. George: The other thing is if it is split, split in which domains. Marc: Regarding the 2nd slide, do you think what you wrote and what is in draft is correctly represented in the problem statement draft? Are those problems clearly defined in the problem statement draft? Teemu: I think so. Marc: I want to make sure that we capture the problem. Lars: I like it because it is an example of what MIF needs to work through and this is one tricky area that we understand pretty well. So getting the DNS information correctly. Having said that it is more complicated than you currently described. It is pretty complicated to determine which proper DNS server you should be resolving to and I don¡¯t know if that problem can be solved. ------------------------------ 7. Questions & Next Steps (Chairs, 10 min) Margaret: Thanks to everyone. We made a lot of progress in terms of what we are working on. _________________________________________________________________ Share your memories online with anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1 --_cf4f2cd0-ca99-4a12-85b2-e8955f26819e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hello, all
 
Thanks Carl for taking the detail minutes,
Please feel free to comment on it,
 
Many thanks
 
-Hui
 
MIF Working Group Meeting (IETF 75)
 
The MIF working group was held at IETF 75 Stockholm at 9:00am
on Tuesday, July 28, 2009 in Room Large Stage.
 
Chairs: 
Margaret Wasserman and Hui Deng
1. Preliminaries                (5 mins Chairs)
   - Blue sheets
   - Note takers: Carl Williams
   - Jabber scribe: Aleksi Suhonen
   - Agenda 
 
Margaret: goes over the agenda. Said we will go over problem statement
and that we will have good amount of time for it.  Then the MIF best
practices document which Margaret said she will do.  Then the session
will allow presentations that didn¡¯t get a chance to discuss
during the BOF.
------------------------------------
 
2. Problem Statement presented by Marc Blanchet (1 hour)
http://www.ietf.org/proceedings/75/slides/mif-2.pdf
http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-01.txt
http://tools.ietf.org/html/draft-williams-mif-problem-scenarios-00
 
Marc stated that the context of this presentation is to go over
the changes of the draft -00 version submitted in San Francisco
with the recent changes now in -01 version that was submitted
prior to Stockholm meeting. 
 
Marc began by going over the objective of the draft -01 revision.
He said that the wording is much closer to the charter that was
processed after San Francisco. 
 
Marc said that he integrated comments from the BOF, mailing list
and spent time on each email so that the comments that he agreed
were represented in the draft.  Also, for this new version he
attempted to have formal wording in particular on MIF definition. 
He also read the other drafts on other problem statements and he
got the impression that people think of MIF differently.  Therefore,
the problem statement defines MIF what it is exactly.  While it
doesn¡¯t seem to be simple, but there are a few things that remained
to be defined or agreed on.  Marc says that he thinks it is
appropriate to define that piece correctly so that we know what we
are talking about and that we are all on the same page. 
 
Marc also stated that the goal of this the -01 version is to use
consistent vocabulary throughout the draft. 
Definition is one of the open issues from Marc¡¯s point of view
(may have more).  Marc said he attempted to define a MIF host
somewhat firmly.  Marc stated that it is
      (*) a IPv4 and/or IPv6 compliant host
      (*) configured with more than one IP addresses
          (excluding loopback, link-local)
      (*) on one or more active interfaces, as presented to the IP stack
      (*) The interfaces may be logical, virtual or physical
      (*) The IP addresses may be from the same or from different
          address families, such as IPv4 and IPv6
      (*) communications using these IP addresses may happen
          simultaneously and independ ently
      (*) while the MIF host may forward packets between its
          interfaces, forwarding packets is not taken into account
          in this definition.
      (*) The IP addresses come from more than one administrative domains.

George: Asking if one or more active interfaces are presented
to IP stack (or not presented to the IP stack) and one virtual
interfaces.  (multiple physical interfaces but a virtual
interface that hides all of it).  Is that MIF?
 
Gabriel:  I think that George¡¯s question was not whether there
may be several logical or physical but that the total of those
that there is only 1 seen by the IP stack ¨C is this MIF?  I
think that the answer it is not.
 
Marc:  no
 
Gabriel:  If something under IP hides it like for example in
 multi-technology handover that is not MIF.
 
Margaret:  I don¡¯t necessarily agree.  The charter does say that
we may have a node that has only 1 interface but that is attached
to more than 1 domain and still may need some of the MIF stuff.
We are talking about the properties of the solution that we aren¡¯t
charter to talk about yet. I don¡¯t think that we want to rule out
the possibility of that our solution might imply that for instance
you had a device that say is attached to a Bluetooth link to your
laptop but then your laptop has access to two different
administrative domains and that device still may need to worry about
two different sets of configuration information in terms of service
location or reaching particular internet sites, etc.

Sri:  What is seen from the IP stack perspective is logically one
interface assuming that those physical interfaces are under bridge
mode. This is implementation dependent ¨C under what scenario I might
be putting multiple interfaces 1 or 2 and putting logical virtual
interface and abstracting both of them and both of them can have a
bridge mode and I still may be using those physical interfaces as
real interfaces too.  So both are possible.
 
George:  Just to give a specific example in the IETF we have
technologies that hide interfaces underneath it.  Mobile IP, PMIP ¨C
are technologies where we develop them where they look like layer 2.
Not completely transparent to IP.  In some cases these technologies
takes IP interfaces and wraps them around another interface and
presents that to the operating system.  Maybe from this point of
perspective that this is out of scope.  We have to make a decision
if it is out of scope.  We have to decide if that is the case.
 
Marc:  That makes sense. 
 
Sri:  How the interfaces are wrapped up ¨C at the end what is seen
from an IP perspective I think that is the clear part of the definition.
Margaret:  I think that this is very open right now. It is one or
more interfaces of any type.  If a device has no interfaces at all
then obviously it is not even a network node as we can¡¯t do much
with it.  I think that we want to keep this open because didn¡¯t
want it to be the restrictive thing.  We didn¡¯t want it to be like
well it only has one physical interface so it is not MIF even
though it has a VPN connection and a local network connection over
the same Cisco interface.  We are not talking about a host with two
physical interfaces necessarily. There are plenty of cases where
there is one physical interface but in sense two logical interfaces.
The problem is that we are getting into terminology issues for
particular implementations.  Some people implement VPN as a logical
interface whereas some people may implement it at a slightly higher
level in the stack and you may still have a prob lem where you reach
some services if you talk over your VPN and you can¡¯t reach those
services if you talk over the global Internet. 
 
Gabriel:  The important concept is visibility to the IP Stack. 
Visibility of what.  There we have active interfaces.  From this
discussion it seems that it¡¯s not just the fact that they show up
as completely separate active interfaces.  But the fact that they
show up in some sense of configuration related invisible to the IP
stack - for example DNS. Even if they appear to have one active
interface there may be other reasons why they are MIF ¨Cas long as
they are visible to IP stack.  Is this closer to what we are talking
about.
 
Margaret:  I think so.
 
George:  So basically what you just said so the 3rd sub-bullet is
actually what you mean and that is what I want to clarify.  The 3rd
sub-bullet says that ¡°on one or more active interfaces, as presented
to the IP stack¡± and by this we exclude cases where something is
done to the host that hides other interfaces that might exist.  If
you hide the other interfaces, then we don¡¯t have to do anything
about those. And we only have to do something about those interfaces
that are presented to the IP stack. 
 
Marc:  So the wording is appropriate.
 
Hui:  I thinking that he is saying that you are excluding that case
and he is recommending that you include that.
 
Margaret:  I don¡¯t know if there is a misunderstanding.  One or more
covers all possible cases.  Zero is not interesting.  There is 1 or
there is more than 1.
 
Marc:  But presented to the IP stack.
 
Margaret:  Yes, the IP stack will always have at least one interface
presented in any network node.
 
Marc:  But the point of George is that there are other multiple
interfaces but not presented to the IP stack but we are not talking
about those.  We are only talking about interfaces presented to the
IP stack.
 
Margaret:  Right. We are talking about IP node.  I suppose if it had
interfaces that don¡¯t run IP.  One or more covers all cases as far as
interfaces and then the next one as far as we know ¡°logical, virtual,
physical¡± covers all the types of interfaces.  We are saying it may
be a device has only one interface it may be one logical interface
presented to the IP stack like a bridged interface or something like
that underneath it has two physical interfaces.  Or it could be a
complicated layering of interfaces and we don¡¯t require that two of
them to be presented separately to the IP stack. It could be that
two physical interfaces that are bridged into one logical interface
and that is the only interface that the IP stack sees. Right Marc,
potentially.
 
Marc:  That is what I understand. George can you clarify your point
that I understood that is what is on the screen is what you agree.
 
Lars:  I think that what the disconnect is if you have multiple
interfaces but that if there was something that would hide them ¨C
that you only see one at the IP layer.  But that there was some
configuration information; for example, you see the two pieces of
DNS information but you only saw one interface.  Is this something
that MIF would deal with or would we assume that whatever hides
these interfaces would also aggregate the different configuration
information correctly so that if you see one interface you can
assume that you don¡¯t have MIF? 
 
SRI:  There are multiple cases.  Let¡¯s take an example there is eth0
and eth1 and on top of that I created a virtual interface V0.  In
what scenarios are eth0 and eth1 hidden from stack and what is
presented to the stack is V0.  In another scenario same configuration
I am also using the physical interfaces and at this point I have 3
interfaces eth0, eth1, and V0.  In this second case all three
interfaces are presented to the stack.  So we should clearly allow
both of these scenarios.  So when the interfaces are hidden it is
in the first scenario and not the second scenario. So what we mean
by hidden we must be very careful here.
 
Marc:  I think that the current wording says your second scenario
you see three interfaces and the first scenario you see one
interface.  That is my understanding of the wording. 
 
Comment: I wonder if there is ambiguity in the wording ¡°presented
to the IP stack¡±.  If we say presented to the ¡°IP layer¡± or
presented ¡°by the IP layer to higher layers¡±  I think this may
be clearer. 

Margaret:  We have a lot of ambiguity in the world.  You could say
add layer 2 interfaces and then someone would say ¡°what about VLAN¡±.
There are no words you can use where we all agree means the same
thing.  I thought that ¡°presented to the IP stack¡± is clear that
it meant was presented to the bottom of the IP stack but it seems
that you don¡¯t think that¡¯s clear.
 
Comment:  Presented from the bottom to the IP layer.
 
Gabriel:  I agree on number 3 bullet which is definitely MIF.  What
I was trying to say was maybe that is not everything that is all MIF.
What we really mean and I don¡¯t think we have a good word for it not
just interfaces but configuration stuff that belongs to different
domains or separate network regions or something.  And the IP stack
has to deal with these separate configuration pieces like different
DNS servers or whatever.  It may not show up as something as an
interface logical or whatever.  It may not necessarily have to show
up as something like that.  The granularity may not be that large.
 
Marc:  In other words you are saying that we should not talk about
interfaces.
 
Gabriel:  I think that what we are talking about is different
configuration information that pertains to different networks or
different domains (some word needed here).
 
Margaret:  Maybe we can call it different administrative domains or
configuration domains or provisioning domains or something like that.
 
Gabriel:  Provisioning domains imply that someone is doing for you. 
 
Margaret:  We explicitly included in our charter the idea of a node
that has one interface.  But the simplest case it has an Ethernet
interface that is presented all the way up the stack as a single
interface it only has one but that interface may be the way that
the node connects to more than one configuration domain.  That node
may still have more than one IP address; it may still have more than
one default router; it may need to use different DNS servers to get
domain names in those different administrative domains. It may have
services that it wants to reach that can only be reached using one
of them so it needs to be sure to use the right outgoing source
address at default gateway information to reach that service even
if it only has one physical interface.  During the charter discussion
which happened after we choose the name of the group the decision was
made that this would be in scope for this working gr oup to consider. 

George:  Maybe the solution to this is indeed to move away from terms
like ¡°interface¡± and ¡°IP stack¡±.   Instead to focus on the minimal
set of information that makes a single uninteresting device ¨C what
is that set of information?   Set of information can be presented in
many different ways: virtual ones, different configuration for
different domains, etc.  What is that ¨C the default router, the IP
address or both of them or different dns as well? 
 
Marc:  Agreement that we should remove the concept of the interface
as we¡¯ve been talking about.
 
Margaret:  Says that Jari has comment on jabber that she will read:
¡°I think it is crucial what is visible to IP. Some L2 schemes hide
everything from IP, and I don't think that is a topic for MIF.
However, it is possible that even if you see one virtual interface
from IP perspective, IP sees multiple routers/prefixes that represent
different domains. This would reveal some of the substructure of
the virtual interface.¡±
 
Margaret:  I think that he is referring to the same scenario as I am
where you have one virtual interface but you have for instance two
different routers.
 
Margaret:  Someone else on jabber is suggesting that a MIF host is a
host that connected to a different number of multiple domains.
 
Marc:  That is another bullet.  It appears that we are moving toward
removing the concept of interface.
 
Margaret:  We have generalized the concept of an interface to
include all possibilities so I suppose we might as well just remove
it.  The only possibility that we don¡¯t include anymore is no interface.  
 
Sri:  Don¡¯t know what the issue is.  Third bullet is ok.  Don¡¯t
know why get rid of ¡°interface¡± from definition.  It is fine.
 
Margaret:  Thinks that marc should continue on with slides.
 
Marc continued on with the presentation. 
 
Gabriel:  On the last bullet where you say ¡°The IP addresses come
from more than one administrative domains¡±  - where you say ¡°more
than one¡± I think this starts to captures my point.   My other
point is that I don¡¯t think you have to limit it to IP addresses. 
You can have one IP address but you may have different
configurations of services for example.  You have more than one
domain in which to access those services.  It may not be tied to
interface ¨C it is tied to something configuration at least.
 
Marc:  But not an interface.
 
Gabriel:  That is part of it but it is deeper ¨C it is finer
granularity than interface.  I think when we say interfaces we say
oh that are how we handle blobs of configuration.   Even if the
interfaces weren¡¯t there we could still handle blobs of
configuration. I think that the final bullet is starting to get to that. 
 
Marc:  Your proposal is more than one.
 
George: Does that mean that you might have two interfaces on the
same domain that is not MIF anymore? 
 
Margaret:  It depends on what you mean by MIF.  To say something is
like MIF ¨C MIF doesn¡¯t exist.   We are trying to develop a solution
for the case where a single host is connected via one or more IP
interfaces to more than one administrative domains.  I think that is
the problem that we are trying to focus on here. It is only in need
of a solution if there are specific configuration information
associated with those domains that is different or if you can reach
different services over those two domains.  So there is some reason
you will need to actively choose between them.  If you have two
interfaces and they both go out to the global Internet that might be
a multi-interface host but it is not clear whether if that host has
a problem today ¨C I am not sure.
 
Marc:  It is like a table.  We have interfaces and administrative
domains.  Maybe we are targeting two boxes in this table which is
two interfaces and one administrative domain or one interface and
more than one administrative domain.  Would this make sense?
 
Lars:  How does host tell if different administrative domain.  Is it
different and if you can¡¯t tell is this MIF.
 
Marc:  I don¡¯t think that the purpose of the definition is that the
host knows this but it is more for defining the use case so we know
which use case we are working on.
 
Lars:  how do I know if I am connecting to different administrative
domains?  The MIF mechanisms ¨C whatever they will be ¨C are in effect
or I just won¡¯t do it.
 
Marc:  I agree with your point.  Someone on the mailing list said
that the idea of more than one administrative domain actually to
withdraw any misconfiguration of the network operator ¨C we don¡¯t
want to talk about people who configure their network incorrectly. 
The idea is to remove some of the use cases that we don¡¯t want to
talk about. 
 
Lars:  I understand that you want to limit the charter and you have
identified some of the scenarios you want to support.  My point is
that I am not sure that the host knows when it is one of those
scenarios and when it isn¡¯t. 
 
Marc:  I agree with you.
 
Margaret:  Part of the solution or at least some discussion of the
analysis will be how the node does know.   I don¡¯t think it matters
how many domains your connected to if you only have one IP address
and you only have one default router and you only know one DNS server
obviously you don¡¯t need a solution.   If you know of multiple of
those you need to know I guess ¨C if you know of two DNS servers
than you kind of need to know are these 2 DNS servers the backup
of the same one or are they 2 DNS servers offered by different
providers where different services might be available by looking
them up in the two different service.  I think it is tricky to know
if you have one physical interface and 2 DNS servers configured
which one of those cases it is without some additional information
like if you got 2 DNS servers and one of those you got from DHCP and
one you got through some pdp provisioning because your some kind of
cellular interface ¨C then obviously you know their different
domains.  But if you get them from the same domain DHCP server then
you might have to might have to make the default assumption that it
is one domain unless you have some other knowledge that it is more
than one domain. 
 
Lars:  You need to have a mechanism that it is more than one.
 
Teemu Savolainen:  Are they always different administrative domains
or same administrative domains. 
 
Gabriel:   It might be more than 1 administrative configuration
blobs than administrative domains.  I agree that the hard part is in
knowing that these configuration blobs are different and you have to
deal with them separately.  Maybe that is part of the problem that
we have to identify here ¨C how you tell that these are
administratively different configuration blobs.
 
Marc went on with his presentation:  Marc said that the change in the
symptom section now has a technical abstract for each scenario.  Marc
went over a few other minor modifications.  Marc stated that he will
include Section 3 of draft-williams-mif-problems-scenarios-00.txt for
next -02 release. 
 
Marc requested that the working group accept this draft as a working
group document.
 
Margaret asked the working group how many read the draft.  Many
people raised their hands.  Then she asked how many people accept the
document.  Numerous members raised their hands.  Margaret says that
this a pretty good show of hands.   Margaret asked is there anyone
who doesn¡¯t think that we should accept the document as a working
group item.  No one raised their hands.  It was decided to publish
it as a MIF working group document.
---------------------------------
3.  MIF Current Practices (Margaret Wasserman, 15 min)
http://www.ietf.org/proceedings/75/slides/mif-1.pdf
http://www.ietf.org/internet-drafts/draft-mrw-mif-current-practices-02.txt

Margaret went over new revisions to the MIF current practices. 

Margaret says that it is not been updated since BOF.  She will go
over revisions she has for the document. Margaret went over the
goals of the document. 
 
Margaret stated that the goal of this document is to collect
information about existing implementations that are already out there
dealing with this problem and how they deal with having multiple
physical or virtual interfaces or how they deal with having multiple
sets of configuration information.  And then after we collect the
information to generalize or categorize those solutions to understand
what the current practices are in the field in this type of situation
and then to identify gaps that require further improvements.  Margaret
said that we may find that the combinations of what is already out
there is sufficient and then what we want to do is just to write a
document that says when you have these type of solutions the best
current practice is to do X, Y and Z.  Or that we may find that there
is a lot of stuff out there that has promising solutions in this space
but that there are still holes that aren¡¯t rea lly solved in real world
implementations today.   We don¡¯t know which ones of those situations
it is going to be in until we get all this information together. 
 
Margaret said that not everything has been realized in the current
version of document. Right now it is just cataloging existing
implementations and starting to do sub-categorization.  Little
tricky in writing this document ahead of reaching consensus on what
should be in this document.
 
Margaret stated that the current systems she has provided analysis
on are:
  - Nokia S60
 - MSFT windows Mobile 2003
 - Blackberry
 - Google Android
 - Arena Connection Manager
 - MSFT vista
 - MSFT windows server
 - Linux and BSD operating systems
 - Apple MAC OS X

Margaret says that there were 2 general approaches:
First, applications (or user) choose a ¡°connection¡± among available
choices Margaret says this is more common in mobile/cell phone
environment.  She stated that all configurations stored on a
per-connection basis and that after initial selection, all
communication (including DNS, if any) uses the indicated connection.

Margaret noted that a ¡°connection manager¡± may be provided. 
The second approach Margaret mentioned is that DNS, address selection
and interface selection are performed separately.  Margaret stated
that this is more common in general-purpose operating systems. 

Margaret stated that DNS invoked by application, remote address chose
from list returned, local address chosen to match, packets sent to
default gateway.  She stated that a DNS server list, default gateway
(& other routes, if any) are stored on a per-system basis.
 
Margaret stated that in those cases of the general operating systems
one of the solutions that people are using in order to reach one set
of services from one interface and another set of services from
another interface use this Split-DNS concept. 
 
Margaret says that current implementations fall into two groups: (1)
DNS server list configured on per-host basis; (2) DNS server list
configured on a per-interface basis.  Margaret states different OSes
use server addresses from lists in different orders/combinations.

Margaret says that in all cases, DNS queries are sent using a source
address and outbound interfaces selected by the IP stack. 
For example, the address and interface are not tied to the interface
on which the DNS configuration was received.
 
Margaret said that for interface selection hosts fall into different
categories.  Margaret stated that it is really hard to categorize
because if you read the draft you will see that every single one of
them does things differently.
 
Margaret stated that for interface selection you select an outbound
interface and next hop destination as a multi-step process.  Margaret
said that what typically happens you get a destination address from
the application ¨C in most cases hosts are getting one destination
address from the application even if the DNS returns multiple
addresses.  In some cases they may receive a list of possible
addresses.  So you get one or more destination addresses and if that
the destination address is on a local link, address resolution
(i.e. ARP) is performed on the corresponding interface, and the
packet is sent directly to the destination.  Routing table gets used
if not on local link.
Many times you will have problems with this.  Margaret pointed out
that if I am on two networks: one of the is the global network
192.x.x and the other one is the VPN network 10.2.1.X and that I want
to go to net 13 ¨C if I do a longest match lookup it is going to
match net 10 interface and that is not what I want.  So a lot of
these longest match lookups are moderated by a lot of other knowledge
like the net 10 addresses or the local addresses.  But if you are not
using some type of local addressing and you are just using two sets
of global addresses on your two links you can get a case where your
best match lookups have you sending traffic out of an interface that
can¡¯t reach the place you are trying to go even though your interface
with a shorter match can reach where you are trying to go.   This is
where the MIF problem comes in.  
 
Margaret stated that maybe you don¡¯t even have a routing table.  Many
nodes only have a routing table if they received an ICMP redirect ¨C
so you are going to fall back to your default route and then you are
going to look at your default router list which is another complex
process that nodes do differently.   Margaret stated that default
router list configuration fall into two groups:  (1) per-host default
router lists; (2) per-interface default router lists.  Margaret
stated that in general the default router with the lowest metric is
chosen for outbound traffic. 
 
Margaret stated that all this is pretty arbitrary in terms of that
these nodes have no idea when they are choosing the default router
which is going to become the destination to which they are going to
send these packets ¨C what interface they are going to send these
packets out.  They don¡¯t know when they are choosing the default
router anything about how they found this service.  Margaret pointed
out the example if the node had two interfaces A and B and the node
got a DNS server from interface A and I looked up this service over
interface A if the address that I am using is not in my routing table
and I fall back to my default router as a top router in my router
list is interface B then I am going to send the packet that way
without any knowledge that interface A might be a better choice.
Comment:  In a number of scenarios all interfaces are not equal;
they may not have equal costs; they may not have preference to
security; etc¡­ these factors you need to consider you when you
do the selection.
 
Margaret:  In the implementations document so far these things are
not taken into account.  There are cases where the user is asked
but what reasoning the user uses in their brain I can¡¯t vouch for.
Inside the applications there doesn¡¯t seem to be a way in any of
the ones we cataloged so far for the user to insert any sort of
policy that says I want some to be preferred over others.
Margaret went on to say that packets would be sent out of the
interface of the default router that has been selected via this
kind-of arbitrary process.  The destination address if it is even
considered in picking the default router list.  Margaret said that
in the previous example we talked about longest match ¨C but that
cases of most hosts sit out there with no entry in there routing
table except the default router and they fall right back to the
default router they picked one without regard to the how the source
addresses they can use on that interface relate to the destination
address that they are trying to get to. 

Margaret went over Address selection.  Margaret stated that the
destination address section in almost all cases will be chosen by
the application based on DNS lookup results or some type of
application-level configuration.  Margaret stated that source
address selection may be done by the application.  If not,
implementations vary in what they choose: (1) first address on the
outgoing interface (most common); (2) more complex selection
mechanisms that involve choosing the best match for the destination
address, such as RFC 3484.
 
Margaret stated that we have a situation where you can see that if
you use the IETF standards a lot of stuff is not coordinated. 

Margaret explained that you have a node; you have an application
running on that node; that application chooses a destination address
¨C passes it into the stack; a complex routing mechanism is used
often in resulting in an arbitrary default router selection which
is then to select the outbound interface; the source address often
chosen without really any concern as to the destination address it
used but merely to match the outbound interface.  You often get
cases where a node could reach a particular service or a particular
address but does not reach that address because it sends traffic out
the wrong interface.  
 
Margaret stated that moving forward she needs more information on
more implementations; Margaret says that most mobile nodes do better
than this in practice.  Here the application is fully pre-provisioned
of where it wants to go.  That results in better user experience but
is probable not practical for ordinary internet applications as a
solution.  But if people have good solutions or different solutions
to these problems either in that cellular provisioning area or in
DNS, default router, source address selection area it would be great
to hear about them.  Margaret also stated that she needs to group
implementations and provide more consistent information about them. 

Margaret concluded by stating that common solutions section needs to
be expanded.  She let everyone know that if anyone is familiar with
an implementation that is not included, try to send text to her.
 
Margaret said if you are familiar with an implementation that is not
included, please send text. 

Comment:  You mention two generic approaches.  My question is once
connection selection is established than MIF is not an issue after
connection?
 
Margaret: Again, I have a really difficult problem with the use of
MIF as a proper noun because there is no solution that exists. And
I think that we would like our solution if it exist someday to apply
to mobile nodes as well as other nodes as you have increasing
convergence between those devices so you got a device with a 3G
interface and a 802.11 interface and it would be good if that type
of device could benefit from whatever solution we come up with here.
So I don¡¯t want to rule that out of scope if that is what you are asking.
 
Margaret followed up by saying that let us not assumed that just because
it is called a ¡°connection manager¡± that it is a really cool and
sophisticated thing.  Margaret stated that in many cases what this
connection manager does is to display a dialogue box and ask the user
what interface to use.  In other cases it decides behind the scenes
very often using things like you are using the application you got from
your cellular provider so use the cellular interface.  It is not like
it is making some highly skilled carefully tuned policy decision. 
 
Margaret stated that if you have only one connected interface and only
have one connected administrative domain it has nothing to do with MIF. 

Right now they are constraining it as they don¡¯t have an answer to the
multi-interface case.  They are only bringing up one interface at a
time.  They are asking the user which one to bring up.  Margaret said
she hopes that we can do something much better than that.  And it
will apply to those devices but I agree that if you already decided
to bring up one interface then you don¡¯t need MIF.
 
George:  Connection Managers become increasingly more intelligent
over time.  Also my question is should this document also get into
soft interfaces?  Things that are happening because you have
software on top that created different situations. 
 
Margaret:  It may be the case that they change the default behavior
in which case they would get another entry.  I want be concrete here
and list specific information about specific implementations. So if
there is one of those types of things that you know about and can
categorized or give us any insight into its behavior with respect
to the things that are mentioned in this document then you should
write it up and we will give it a new section. 
 
George states that he has information of how multi-interface support
is handled by Advanced Mobile Station Software (AMSS) that comes
with Brew OS for all Qualcomm chipsets (e.g., MSM, Snapdragon etc).
 He feels it might be helpful information to the current practices
 draft for MIF.  He will send the information out to the MIF alias.
Someone raised about including ICE.
 
Margaret responded by saying that she doesn¡¯t know if it applies
here but if someone does know about it and if they want to write
up how it addresses these questions; how it addresses the problems
in the MIF problem statement; Margaret would be happy to include
it in the next revision of the draft.
 
Lars:  ICE is an application layer of your respective protocol or
library that wants to have a functioning IP connectivity over
multiple then it will figure out which to use for the application.
Don¡¯t be too clever here.  Don¡¯t try to solve this problem for the
applications.  Just make sure IP path configuration that you are
getting is correct ¨C that actually works.  Leave the rest to things
like ICE.  Another example of something ¨C in the transport area we
are having a bof on multi-path TCP.  It is not clear that we are
going to do any work in the IETF but if we do that would lead to TCP
wanting to send packets along different paths over the network. 
Obviously MIF would be something that makes that those paths work
but if you hide them from ICE then you are not doing any good. 
You are taking control away from the application higher layer.
 
Margaret:  Says she would argue what we are doing now in the world
is interfering with those sorts of things.  Not because it is too
clever ¨C I am not sure that is the right thing ¨C but because it
often throws away configuration information or obscures the ability
for upper layers to know what influence or anything about how the
packets are going to be routed.  And you could have the situation
where you are trying to use two different destination addresses to
try to go two different directions ¨C you don¡¯t go two different
directions because you go out the default gateway.
Lars: I agree that what is currently deployed is not good.  I hope
that whatever MIF comes up with will makes things better and not
worse in a different way or not fit.
 
Margaret:  One of the things that I think is pretty clear that we
need in a solution is a way that the applications can actually
specify not just destination and source address to use but what
interface to use.  And possible what default router to use.  How
they do that whether it comes from a list that was collected in a
different layer ¨C I don¡¯t really understand all the parts of it. 
Right now that is not what you get.  Right now what you get is you
want to go to a particular destination and you send it down and
where they packet gets sent is decided by a process that can¡¯t really
be controlled by the application layer or the transport layer.  I
think of DNS as an application so I am not trying to leave transport
out.  Things above IP are really not getting a chance to really
control that. 
 
Gabriel:  During the BOF we had slides on that point (going back
to what Lars said).  We listed a bunch of things at the IETF that
deals with multiple interfaces, multiple sets of configuration
objects, stuff like that... There were a number of IETF work
(SHIM6, etc) that were noted and it was stated that there was some
overlap and that this should not interfere with that.  
 
Margaret:  If someone wants to write-up some of these things we can
include them in the current practice draft.  Even if we create a
different section that says ¡°things that need to interact with this
stuff¡±¡­.
 
Hui asked the working group how many people read the draft.  Hui then
asked how many people think that this document should be adopted as
working group.  A fair number of people read the draft.  Many people
thought that the draft should be adopted as a working group document.
The chairs stated that there are three drafts that aren¡¯t part of the
charter but that they will provide time to cover.
------------------------------------
4. MIF Analysis and Scenarios (Yong-Guen Hong, 15 min)
http://www.ietf.org/proceedings/75/slides/mif-4.pdf       
http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-01
Yong-Guen stated that the goal of the draft is to identify problems
of MIF with the focus on real routing issues.  He stated that there
is relation between network interface and destination address.  
There is consideration for asymmetric routing path. 
 
Yong-Guen also stated that the goal of this draft is to describe
usage scenarios of multiple interfaces.  Those are in two categories:
A host with single interface to multiple networks and a host with
multiple interfaces to multiple networks.
 
Yong-Guen presentation and draft goes into details on these two
areas ¨C problems and the scenarios.  Yong-Guen slides detail very
specific scenarios cases that were presented in his draft.
 
Margaret asked how many people have read this draft.   Margaret
cited that a few raised their hands.  Margaret asked if people
thought it would be useful to add these type of usage scenarios
to our problem statement? 
 
Question at MIC. 
 
Gabriel:  Why is layer 2 scenarios ¨C multiple layer 2 you have in
your scenario list.  Why is that relevant to MIF?  I think that this
 was out of scope ¨C these scenarios.
 
Margaret:  I am open to the possibility that perhaps this scenario
exist whereby you have one l3 interface and 2 layer 2 interfaces and
you are getting configuration information from 2 different domains.
But don¡¯t know if this is possible but open to idea.
 
Jonne Soininen:  I agree with Gabriel that these scenarios are really
not needed here because these l2 interfaces don¡¯t configure the IP
stack.  The case we are talking about it does look like one interface
all of the time.  You always just have one IP address and  API of
the IP stack doesn¡¯t see a change.
 
Margaret:  There is one administrative domain even though there are
two layer 2 interfaces here.
Jonne: Yes.  The IP stack doesn¡¯t know that there are multiple layer
2s.  It looks at it as there is one layer 2.  
Will Ivancic (NASA): Marc mentioned that there is a plan to
incorporate the scenario section of Carl Williams¡¯ draft.  I think
that is a more generalized set of scenarios and is useful to include.

Margaret stated that the next presentation is on MIF Security.
------------------------------------
5. MIF Security Considerations (Nam-Seok Ko, 15 min)
http://www.ietf.org/proceedings/75/slides/mif-3.pdf       
http://www.ietf.org/internet-drafts/ draft-ko-mif-security-considerations-00.txt
Nam-Seok stated that the goal was to review over security
considerations for MIF.
Nam-Seok went over three slides of various security considerations
for MIF in his presentation.  Nam-Seok stated that this was a
preliminary look at security analysis for MIF and that he only
wanted to get the discussion on security.
Nam-Seok wanted feedback on the issue of security for MIF.
There was discussion on some of the requirements in particular on
the requirement of unwanted injection of configuration objects
targeted to specific interface(s) to other interfaces.
 
Margaret: If the MIF solution is something like a configuration
policy manager, it might be the case that there is a way to inject
 and even read a configuration for your own domain but not for
 some for somebody¡¯s else domain.
 
Gabriel:  Unless you have access rights or something.
 
Margaret:  Then that security requirement may be a very good requirement. 
Gabriel:  It has to be re-worded in terms of access rights or administrative rights. 
 
Margaret:  Until we know whether the solution has a concept of
different administrators who may have different rights I think it is
 really hard to write the right security wording around that.  I
 don¡¯t think we know enough about the solution to know what the
 parties are.  For security considerations you have the things you
 want to protect and you have all the parties and you know which
 parties get access to what and what you want to protect from whom
 and I think that we don¡¯t know yet much about the solution to
 populate that  table. 
 
Nam-Seok:  This is a very early straw-man attempt at identifying some
security issues just to get some preliminary discussion going.
 
Margaret:  I think that it is great to start thinking about security
right away.  And I think that as things start to evolve we will know
more about what this document needs to say.  I think that it is going
to be really important as we do the analysis document that we include
in that some understanding of ¨C that is going to be gap analysis ¨C
what I think what will be missing is any idea of separating security
domains and different access controls for different domains and so
forth and this will come into play. 
 
Gabriel:  Perhaps an initial first stab would be just the threat model.
And leave all the language of requirements ¨C thou shall do, etc¡­ - out
of the document. As we probable don¡¯t understand it until we have a
threat model.  That would be a necessary first step.
 
Margaret:  I think so.

Margaret stated that we have one more presentation by Teemu.  Margaret
stated that we ran out of time during BOF for Teemu to present so now
he has the opportunity.
------------------------------------
6.  MIF DNS Server Selection (Teemu Savolainen, 15 min)           
http://www.ietf.org/proceedings/75/slides/mif-5.pdf       
http://www.ietf.org/internet-drafts/draft-savolainen-mif-dns-server-selection-00.txt
Teemu spoke of Split-DNS and what Split-DNS is.  Teemu says that the
host receives recursive DNS server addresses from multiple network
interfaces, but some of the DNS servers may serve information other
do not.  Teemu stated that some have unique information not available
on others.  For example, IP addresses for private FQDNs.  Teemu stated
that some serve different information for the same query.  He provided
an ex ample FQDN results in different IP addresses from different
interface¡¯s name servers, and even worse, same FQDN may result in IP
addresses of completely different network entities/services. 
 
Teemu went over what a MIF host should be able to accomplish.  He
stated to send queries to DNS server able to answer properly and to
use resolved IP addresses on the interface they work on. 
 
Teemu pointed out problems.  For example, how to select right DNS
server?  Also, the source/destination address selection algorithms
are not suitable, as no destination IP addresses are available. He
also pointed out that the ¡°second interface¡¯s¡± DNS server might be
able to serve even if ¡°first interface¡¯s¡± DNS server returned
negative reply.
 
Teemu then went over solution approaches.  He said that avoid
setting-up split-DNS (avoid creation of the problem).  He also stated
that BIND applications to specific interfaces.  Finally, Teemu stated
we need to come up with optimized DNS resolution algorithm.  He
proceeded with a slide on possibilities for the algorithm.

Teemu says that MIF is chartered to work on problem statement,
existing practices and analysis.  Teemu asked how many people are
interested on this problem?   
 
George:  I think that split-DNS issue is water under the bridge. 
We can not avoid split-DNS ¨C it is everywhere.  All of our companies
do it.  I am not an DNS expert but I don¡¯t even think that there is
a way when you get a DNS address to know it is split-DNS or not? 
Is that correct? 
 
Teemu:  yes.
 
George:  The other thing is if it is split, split in which domains.  
Marc:  Regarding the 2nd slide, do you think what you wrote and
what is in draft is correctly represented in the problem statement
draft?  Are those problems clearly defined in the problem statement
draft?
 
Teemu: I think so. 
 
Marc: I want to make sure that we capture the problem.
 
Lars:  I like it because it is an example of what MIF needs to work
through and this is one tricky area that we understand pretty well.
So getting the DNS information correctly.  Having said that it is
more complicated than you currently described.  It is pretty
complicated to determine which proper DNS server you should be
resolving to and I don¡¯t know if that problem can be solved. 
------------------------------
7. Questions & Next Steps (Chairs, 10 min)
Margaret:  Thanks to everyone.  We made a lot of progress in terms
of what we are working on. 


Share your memories online with anyone you want anyone you want. --_cf4f2cd0-ca99-4a12-85b2-e8955f26819e_-- From pierrick.seite@orange-ftgroup.com Fri Aug 28 01:50:28 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2402128C13B for ; Fri, 28 Aug 2009 01:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6mTdsoxiYzi for ; Fri, 28 Aug 2009 01:50:26 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 2F5313A6F30 for ; Fri, 28 Aug 2009 01:50:25 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:50:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 10:50:28 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462487848@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4A71BC9E.40709@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] definition of a MIF host Thread-Index: AcoRKuo0faeMBpO/RfycNyRnKXwAaQWiKiVw References: <4A71BC9E.40709@viagenie.ca> From: To: , X-OriginalArrivalTime: 28 Aug 2009 08:50:30.0076 (UTC) FILETIME=[9895A7C0:01CA27BC] Cc: mif@ietf.org Subject: Re: [mif] definition of a MIF host X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 08:50:28 -0000 Bonjour, D=E9sol=E9 pour la r=E9ponse tr=E8s tardive mais j'=E9tais en cong=E9 = apr=E8s l'IETF. En fait, la definition du "MIF host" est d=E9j=E0 compatible avec la = d=E9finition monami6. La probl=E9matique MIF intervient d=E9s que = plusieurs adresses IP sont utilis=E9es: Extrait de la section 2: A MIF host is defined as: o a [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host o configured with more than one IP addresses (excluding loopback, link-local) Je pense donc qu'une r=E9f=E9rence au draft monami6 pourrait suffire. Je = propose de modifier la section " 3.3. Mobility and other IP protocols" = comme suit: This document assumes hosts only implementing [RFC1122] for IPv4 and = [RFC4294] for IPv6, and not using any kind of new transport protocols. = If definition of MIF host presents similarities with multihomed nodes = [ietf-monami6-multihoming-motivation-scenario], it is not required for = the host to support additional IP mobility or multihoming protocols, = such as SHIM6, SCTP, Mobile IP, HIP, RRG, LISP or else. Moreover, the = peer of the connection is also not required to use these mechanisms. Autre possibilit=E9: modifier la section 2: A MIF host is defined as: o a [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host o as per [ietf-monami6-multihoming-motivation-scenario], a MIF host = is configured with more than one IP addresses (excluding loopback, = link-local)=20 =20 Commentaires? A+ Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de Marc > Blanchet > Envoy=E9=A0: jeudi 30 juillet 2009 17:31 > =C0=A0: Nicolas Montavont > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] definition of a MIF host >=20 > - thanks. it is in fact very good input. the monami6 definition is > however a bit v6 specific (eg. prefixes advertised on the link) where > mif shall be af agnostic. I'll adapt it for mif. >=20 > Marc. >=20 > Nicolas Montavont a =E9crit : > > Hi, > > > > (I'm only starting to follow this group, so I hope my question was = not > > discussed before...) > > > > I'd like to come back on the discussion on a MIF host as defined in > > draft-blanchet-mif-problem-statement-00. > > > > In the former WG Monami6, we worked on the following document: > > > > http://tools.ietf.org/id/draft-ietf-monami6-multihoming-motivation- > scenario-03.txt > > > > > > where we also proposed a definition for a multihomed node. We came = up > > with the following definitions: > > > > Interface > > > > A node's point of attachment to a link (as defined in [5]) > > > > Multihomed Node > > > > A node (either a host or a router) is multihomed when it has > > several global IPv6 addresses to choose between, i.e. in the > > following cases when it is either: > > > > * multi-prefixed: multiple prefixes are advertised on the = link(s) > > the node is attached to, or. > > > > * multi-interfaced: the node has multiple interfaces to = choose > > between, on the same link or not. > > > > Basically it says that a node is multi-homed as soon as it has = multiple > > addresses of the same scope, from which it can choose to send data > > packets. What was good IMHO in this definition, is that it is = concise > > and does not try to cover all cases where you can end up in that = case. > > > > So for the purpose of draft-blanchet-mif-problem-statement-00, I = would > > suggest to keep the definition very short, and then have examples in > > another section that show how a host can be multi-homed / MIF = (several > > interfaces, several administrative domains, etc). > > > > In the same sense, I think that the bullet "Communications using = these > > IP addresses may happen simultaneous and independently." should not = be > > in the definition, but again, in some explanations of scenarios. > > > > Regards, > > Nicolas > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > DTN news service: http://reeves.viagenie.ca >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From pierrick.seite@orange-ftgroup.com Fri Aug 28 02:39:12 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA103A6B1F for ; Fri, 28 Aug 2009 02:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_20=-0.74, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4vEbZfxNU8y for ; Fri, 28 Aug 2009 02:39:11 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id A97F428C141 for ; Fri, 28 Aug 2009 02:39:10 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 11:39:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 11:39:15 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462487876@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462487848@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] definition of a MIF host Thread-Index: AcoRKuo0faeMBpO/RfycNyRnKXwAaQWiKiVwAAOfTvA= References: <4A71BC9E.40709@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C462487848@ftrdmel0.rd.francetelecom.fr> From: Cc: X-OriginalArrivalTime: 28 Aug 2009 09:39:16.0249 (UTC) FILETIME=[68B83890:01CA27C3] Subject: Re: [mif] definition of a MIF host X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 09:39:12 -0000 Hi, Sorry for this email in French sent by error to the ML... The subject is = how to refer to monami6 host in MIF definition. I wished to get = consensus with Nicolas and Marc before notifying the ML... BR, Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > pierrick.seite@orange-ftgroup.com > Envoy=E9=A0: vendredi 28 ao=FBt 2009 10:50 > =C0=A0: marc.blanchet@viagenie.ca; ietf@montavont.net > Cc=A0: mif@ietf.org > Objet=A0: Re: [mif] definition of a MIF host >=20 > Bonjour, >=20 > D=E9sol=E9 pour la r=E9ponse tr=E8s tardive mais j'=E9tais en cong=E9 = apr=E8s l'IETF. >=20 > En fait, la definition du "MIF host" est d=E9j=E0 compatible avec la > d=E9finition monami6. La probl=E9matique MIF intervient d=E9s que = plusieurs > adresses IP sont utilis=E9es: >=20 > Extrait de la section 2: >=20 > A MIF host is defined as: > o a [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host > o configured with more than one IP addresses (excluding loopback, > link-local) >=20 > Je pense donc qu'une r=E9f=E9rence au draft monami6 pourrait suffire. = Je > propose de modifier la section " 3.3. Mobility and other IP protocols" > comme suit: >=20 > This document assumes hosts only implementing [RFC1122] for IPv4 and > [RFC4294] for IPv6, and not using any kind of new transport protocols. = If > definition of MIF host presents similarities with multihomed nodes = [ietf- > monami6-multihoming-motivation-scenario], it is not required for the = host > to support additional IP mobility or multihoming protocols, such as = SHIM6, > SCTP, Mobile IP, HIP, RRG, LISP or else. Moreover, the peer of the > connection is also not required to use these mechanisms. >=20 > Autre possibilit=E9: modifier la section 2: >=20 > A MIF host is defined as: > o a [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host > o as per [ietf-monami6-multihoming-motivation-scenario], a MIF = host is > configured with more than one IP addresses (excluding loopback, link- > local) >=20 >=20 > Commentaires? >=20 > A+ > Pierrick >=20 > > -----Message d'origine----- > > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Marc > > Blanchet > > Envoy=E9=A0: jeudi 30 juillet 2009 17:31 > > =C0=A0: Nicolas Montavont > > Cc=A0: mif@ietf.org > > Objet=A0: Re: [mif] definition of a MIF host > > > > - thanks. it is in fact very good input. the monami6 definition is > > however a bit v6 specific (eg. prefixes advertised on the link) = where > > mif shall be af agnostic. I'll adapt it for mif. > > > > Marc. > > > > Nicolas Montavont a =E9crit : > > > Hi, > > > > > > (I'm only starting to follow this group, so I hope my question was = not > > > discussed before...) > > > > > > I'd like to come back on the discussion on a MIF host as defined = in > > > draft-blanchet-mif-problem-statement-00. > > > > > > In the former WG Monami6, we worked on the following document: > > > > > > = http://tools.ietf.org/id/draft-ietf-monami6-multihoming-motivation- > > scenario-03.txt > > > > > > > > > where we also proposed a definition for a multihomed node. We came = up > > > with the following definitions: > > > > > > Interface > > > > > > A node's point of attachment to a link (as defined in [5]) > > > > > > Multihomed Node > > > > > > A node (either a host or a router) is multihomed when it has > > > several global IPv6 addresses to choose between, i.e. in the > > > following cases when it is either: > > > > > > * multi-prefixed: multiple prefixes are advertised on the > link(s) > > > the node is attached to, or. > > > > > > * multi-interfaced: the node has multiple interfaces to = choose > > > between, on the same link or not. > > > > > > Basically it says that a node is multi-homed as soon as it has > multiple > > > addresses of the same scope, from which it can choose to send data > > > packets. What was good IMHO in this definition, is that it is = concise > > > and does not try to cover all cases where you can end up in that = case. > > > > > > So for the purpose of draft-blanchet-mif-problem-statement-00, I = would > > > suggest to keep the definition very short, and then have examples = in > > > another section that show how a host can be multi-homed / MIF = (several > > > interfaces, several administrative domains, etc). > > > > > > In the same sense, I think that the bullet "Communications using = these > > > IP addresses may happen simultaneous and independently." should = not be > > > in the definition, but again, in some explanations of scenarios. > > > > > > Regards, > > > Nicolas > > > _______________________________________________ > > > mif mailing list > > > mif@ietf.org > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > > DTN news service: http://reeves.viagenie.ca > > > > _______________________________________________ > > 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 From Scott.Brim@gmail.com Fri Aug 28 05:51:44 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D383A7147 for ; Fri, 28 Aug 2009 05:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU5iktFT26Zt for ; Fri, 28 Aug 2009 05:51:44 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BC0BD3A6C26 for ; Fri, 28 Aug 2009 05:51:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAAxwl0pAZnmf/2dsb2JhbACRZ64ahxqRRYQZBQ X-IronPort-AV: E=Sophos;i="4.44,291,1249257600"; d="scan'208";a="55910971" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Aug 2009 12:51:50 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7SCpoEU019786 for ; Fri, 28 Aug 2009 08:51:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7SCpoWc025075 for ; Fri, 28 Aug 2009 12:51:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 08:51:49 -0400 Received: from cisco.com ([10.86.255.4]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 08:51:49 -0400 Date: Fri, 28 Aug 2009 08:51:40 -0400 From: Scott Brim To: mif@ietf.org Message-ID: <20090828125140.GG50226@cisco.com> Mail-Followup-To: Scott Brim , mif@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 28 Aug 2009 12:51:49.0533 (UTC) FILETIME=[4F0374D0:01CA27DE] Authentication-Results: rtp-dkim-2; header.From=Scott.Brim@gmail.com; dkim=neutral Subject: Re: [mif] definition of a MIF host X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 12:51:44 -0000 Excerpts from Nicolas Montavont on Thu, Jul 30, 2009 01:58:35PM +0200: > In the same sense, I think that the bullet "Communications using > these IP addresses may happen simultaneous and independently." > should not be in the definition, but again, in some explanations of > scenarios. Everything you say is fine with me except this. This sentence does not refer to actual simultaneous/independent use, which could go in scenarios. Rather it says "may happen", i.e. the endpoint has arranged to be _capable_ of using multiple addresses simultaneously and independently -- through enabling and configuring interfaces. When that is done, the MIF problem arises. If addresses are only used sequentially, there need not be a MIF problem. So this sentence describes an essential part of the problem, and I think it should be retained. Scott From Scott.Brim@gmail.com Fri Aug 28 05:57:24 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363FF3A6F69 for ; Fri, 28 Aug 2009 05:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZERVj4OsLFY for ; Fri, 28 Aug 2009 05:57:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 71C473A6F20 for ; Fri, 28 Aug 2009 05:57:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAL9wl0qrR7PD/2dsb2JhbACRZ64dhxqRRYQZBYFU X-IronPort-AV: E=Sophos;i="4.44,291,1249257600"; d="scan'208";a="377229256" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2009 12:57:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7SCvUIn026555 for ; Fri, 28 Aug 2009 05:57:30 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7SCvUIP028151 for ; Fri, 28 Aug 2009 12:57:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 08:57:30 -0400 Received: from cisco.com ([10.86.255.4]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 08:57:29 -0400 Date: Fri, 28 Aug 2009 08:57:25 -0400 From: Scott Brim To: mif@ietf.org Message-ID: <20090828125725.GH50226@cisco.com> Mail-Followup-To: Scott Brim , mif@ietf.org References: <4A71BC9E.40709@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C462487848@ftrdmel0.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462487848@ftrdmel0.rd.francetelecom.fr> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 28 Aug 2009 12:57:29.0568 (UTC) FILETIME=[19B0AE00:01CA27DF] Authentication-Results: sj-dkim-3; header.From=Scott.Brim@gmail.com; dkim=neutral Subject: Re: [mif] definition of a MIF host X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 12:57:24 -0000 Excerpts from pierrick.seite@orange-ftgroup.com on Fri, Aug 28, 2009 10:50:28AM +0200: > En fait, la definition du "MIF host" est déjà compatible avec la définition monami6. La problématique MIF intervient dés que plusieurs adresses IP sont utilisées: > > Extrait de la section 2: > > A MIF host is defined as: > o a [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host > o configured with more than one IP addresses (excluding loopback, > link-local) > > Je pense donc qu'une référence au draft monami6 pourrait suffire. Je propose de modifier la section " 3.3. Mobility and other IP protocols" comme suit: > > This document assumes hosts only implementing [RFC1122] for IPv4 and [RFC4294] for IPv6, and not using any kind of new transport protocols. If definition of MIF host presents similarities with multihomed nodes [ietf-monami6-multihoming-motivation-scenario], it is not required for the host to support additional IP mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP, HIP, RRG, LISP or else. Moreover, the peer of the connection is also not required to use these mechanisms. > > Autre possibilité: modifier la section 2: > > A MIF host is defined as: > o a [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host > o as per [ietf-monami6-multihoming-motivation-scenario], a MIF host is configured with more than one IP addresses (excluding loopback, link-local) > > > Commentaires? IMHO MIF scope is not just mobile, so it's better to adopt and generalize the text for MIF. Scott From pierrick.seite@orange-ftgroup.com Fri Aug 28 06:36:19 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3660F3A6F1C for ; Fri, 28 Aug 2009 06:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=1.176, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VpGHUnWxtUa for ; Fri, 28 Aug 2009 06:36:18 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 215A33A6E30 for ; Fri, 28 Aug 2009 06:36:17 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 15:36:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Aug 2009 15:36:22 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462487951@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <20090828125725.GH50226@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] definition of a MIF host Thread-Index: Acon3xzSOiQszswrS0GDuum5jptgpgABTyww References: <4A71BC9E.40709@viagenie.ca><843DA8228A1BA74CA31FB4E111A5C462487848@ftrdmel0.rd.francetelecom.fr> <20090828125725.GH50226@cisco.com> From: To: , X-OriginalArrivalTime: 28 Aug 2009 13:36:23.0520 (UTC) FILETIME=[88D57E00:01CA27E4] Subject: Re: [mif] definition of a MIF host X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 13:36:19 -0000 >=20 > IMHO MIF scope is not just mobile, so it's better to adopt and > generalize the text for MIF. Agreed. That's the idea. >=20 > Scott > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From caozhenpku@gmail.com Sun Aug 30 01:20:52 2009 Return-Path: X-Original-To: mif@core3.amsl.com Delivered-To: mif@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0223A6952 for ; Sun, 30 Aug 2009 01:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w5DXmRbwWu9 for ; Sun, 30 Aug 2009 01:20:52 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 2C07F3A67A7 for ; Sun, 30 Aug 2009 01:20:48 -0700 (PDT) Received: by vws7 with SMTP id 7so2187697vws.29 for ; Sun, 30 Aug 2009 01:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ehtGDDArzrtp0hbgkm6fyTjmi4OZPcrV/8gDJQ67q4Q=; b=RISa16gVHmeo234+flwws8u1SbW0klBqpiFZjJVbWhEyYlTZnbejxx+HEZdFchfD28 7NLgcpzKZBEQty8SYYqDSpz7kFyEB2u7epHmOEtMxWe82lADGR9TaHKwhjFAFr4q3kni dtGkAD3xRpQxokSsVbFZ3rptOAPZMXiPCu23o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Z/0e9tSWI7SnR9+FLwLgxQJ19hCek1rjPEbcBrtiafCV9ShiZtvSjrwuyUYMCMbVqO Ki/hY/hLTXmD5MGTp8IRBuexK96t663lW+ApnYEFG918BuZz/4qs22eDEdwj+BUtEzGL YUbHaTD3I5tSwkdPU0+japvpCfhoav1sjeQKs= MIME-Version: 1.0 Received: by 10.220.114.142 with SMTP id e14mr4060091vcq.83.1251620454298; Sun, 30 Aug 2009 01:20:54 -0700 (PDT) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462487951@ftrdmel0.rd.francetelecom.fr> References: <4A71BC9E.40709@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C462487848@ftrdmel0.rd.francetelecom.fr> <20090828125725.GH50226@cisco.com> <843DA8228A1BA74CA31FB4E111A5C462487951@ftrdmel0.rd.francetelecom.fr> Date: Sun, 30 Aug 2009 16:20:54 +0800 Message-ID: From: Zhen Cao To: pierrick.seite@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: mif@ietf.org Subject: Re: [mif] definition of a MIF host X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 08:20:53 -0000 But there is a conflict between "generalization" and "specification". There were many email discussions that would like to generalize the scope of this WG, but it seems when we try to generalize the problem, it becomes not so specific. Anyway, I would like to know how do you want to generalize the text. Thanks and regards, Zhen On Fri, Aug 28, 2009 at 9:36 PM, wrote: > > >> >> IMHO MIF scope is not just mobile, so it's better to adopt and >> generalize the text for MIF. > > Agreed. That's the idea. > >> >> Scott >> _______________________________________________ >> 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 >