[mif] draft MIF minutes

[Hui Deng <[e-mail]>]

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