Subject: [mif] Next steps on draft-ietf-mif-problem-statement-07.txt

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Aug 2010 02:41:46 +1200

We discussed this document today on the IESG call. Two major comments 
were made. First, Lars Eggert made the point that the document's 
explanation of interface choice based on interface characteristics 
(Problem 3.2 in Section 5) is far too simplistic. Interface speed, for 
instance, is just one factor among many, and that in reality, 
congestion, path characteristics and perhaps even application traffic 
patterns would have to be taken into account; most likely you would not 
know what kind of characteristics you can get before actually using the 
interface for the task at hand. Interface selection in order to optimize 
application performance is a very hard problem, perhaps unsolvable in 
the general case.

Second, Ralph Droms made the point that not all problems associated with 
the multiple interfaces are merely due to merging node-scoped 
information. Overlapping address space on different interfaces is a 
fundamental problem that cannot be solved through better host 
configuration mechanisms, for instance. The document currently focuses 
mostly on the configuration part of the problem today.

We also talked quite a bit about what the next steps for resolving these 
issues are. My opinion is that the document would be most useful when it 
describes the full scope of the problem. It would be particularly 
valuable to describe the fundamental issues, as that may help us 
understand potential limits of solutions. Here's what I would suggest 
that we do:

1. Go through the document and expand/correct it to describe both the 
configuration merging problem and other fundamental issues around 
multiple interfaces (such as address or name space overlap).

2. Change the parts of the document that talk aboout interface selection 
based on characteristics, and point out that for proper selection, many 
factors have to be considered.

3. Go through the document and make a clearer statement about what 
problems it discusses are hard. For instance, Section 6 says: 
"Therefore, there is a need to define the appropriate behavior of an IP 
stack and possibly define protocols to manage these cases." This needs 
to be expanded in order to explain what issues are solvable through 
configuration object management, and what issues remain as fundamentally 
hard problems (address space overlap, knowing what throughput the path 
from one interface will give you, etc).

These changes are extensive, but in my opinion doable. I am sending the 
document back to the working group in order to make the next revision, 
and we will be doing a new WGLC/IETF Last Call when the revision is ready.

Thoughts? Comments? Does this plan work for everyone?

Jari

Ralph's Discuss:

> I have a fundamental problem with the way in which this document characterizes the problems resulting from the simultaneous use of multiple interfaces as all resulting from receiving different configuration objects from different administrative domains.  In my opinion, some of the example problems in the document are a result of other problems inherent with the simlutaneous use of multiple interfaces.  This distinction is important because , again in my opinion, there are mif problems which cannot be solved by changes to the configuration behavior in the host.
>
> For example, in section 4.1, the symptom:
>
>    4.  S1 or S2 has been used to resolve "a.private.example.com" to an
>        [RFC1918] address.  Both N1 and N2 are [RFC1918] addressed
>        networks.  IPv4 source address selection may face challenges, as
>        due address overlapping the source/destination IP addresses do
>        not necessarily provide enough information for making proper
>        address selection decisions.
>
> is inherent in having interfaces connected to networks using overlapping address spaces, and cannot be solved by improvements to the configuration behavior.
>
> Similarly in section 4.1:
>
>    5.  H1 has resolved an FQDN to locally valid IP address when
>        connected to N1.  After movement from N1 to N2, the host tries to
>        connect to the same IP address as earlier, but as the address was
>        only locally valid, connection setup fails.  Similarly, H1 may
>        have received NXDOMAIN for an FQDN when connected to N1.  After
>        movement from N1 to N2, the host should not assume the FQDN
>        continues to be nonexistent.
>
> How is this problem caused by configuration objects from different domains?
>
>   

> I see two ways to address my concern: either be explicit in limiting the problem statement and mif deliverables to those problems that can be solved with proper handling of configuration information from multiple admin domains or extend the scope of this document to include any problems that may result from the disparate environments (IP reachability, DNS resolution, QoS) to which interfaces are attached.
>   

Lars' Discuss:

> Section 3., paragraph 1:
>   
>> >        2.  Interfaces of a MIF host can provide different
>> >            characteristics (e.g. round-trip time, least cost, better
>> >            bandwidth, etc....).  So, user, applications or network
>> >            provider may wish to influence routing to take benefit of
>> >            this heterogeneity.  However, with current host
>> >            implementations, neither the Type-of-Service nor path
>> >            characteristics can be taken into account in the routing
>> >            table.
>>     
>
>   DISCUSS: I don't think MIF can solve this problem. Yes, interfaces are
>   the first hops into *paths* of different characteristics, but what
>   service quality an application sees across a path depends on the
>   destination, the transport protocol in use and the communication
>   patterns of the application. There is nothing here that can be
>   optimized without taking these into account.
>

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 27 Aug 2010 15:10:32 -0400

When I first started the -00 draft, the problems were not totally clear, 
and were specifically about multiple interfaces, hence the wg name. Then 
the wg moved to multiple admin/prov domains, then discussions on 
mobility, connection manager, etc... In the process, we updated the 
document "roughly" only by fixing words in sentences. The doc got lost 
in the forest... I guess the problem space to describe has grown enough 
through the discussions of the wg that I somewhat agree with the need to 
revisit and look at a larger edit in order to describe the full scope of 
the problem.

So I agree with Jari's plan (even if I would have preferred to work on 
something else... ;-)). Co-editors will discuss offline on how to do the 
new revision.

Marc.

Le 10-08-27 10:41, Jari Arkko a écrit :
>> I have a fundamental problem with the way in which this document
>> characterizes the problems resulting from the simultaneous use of
>> multiple interfaces as all resulting from receiving different
>> configuration objects from different administrative domains. In my
>> opinion, some of the example problems in the document are a result of
>> other problems inherent with the simlutaneous use of multiple
>> interfaces. This distinction is important because , again in my
>> opinion, there are mif problems which cannot be solved by changes to
>> the configuration behavior in the host.
>>
>> is inherent in having interfaces connected to networks using
>> overlapping address spaces, and cannot be solved by improvements to
>> the configuration behavior.
>>
>> I see two ways to address my concern: either be explicit in limiting
>> the problem statement and mif deliverables to those problems that can
>> be solved with proper handling of configuration information from
>> multiple admin domains or extend the scope of this document to include
>> any problems that may result from the disparate environments (IP
>> reachability, DNS resolution, QoS) to which interfaces are attached.
>
> Lars' Discuss:
>
>> Section 3., paragraph 1:
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

-- 
=========
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
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Hui Deng <[email-masked]>
Date: Mon, 30 Aug 2010 16:05:57 +0800

I also agree with this plan, meantime would like to remind new
item proposers to contribute if your issue is not clear there?

and during the last meeting, Julien mentioned that some problems wasn't
clear enough,
Could Julien more speicfic on what content you need?

Best regards,

-Hui

2010/8/28 Marc Blanchet <[email-masked]>

> and were specifically about multiple interfaces, hence the wg name. Then the
> wg moved to multiple admin/prov domains, then discussions on mobility,
> connection manager, etc... In the process, we updated the document "roughly"
> only by fixing words in sentences. The doc got lost in the forest... I guess
> the problem space to describe has grown enough through the discussions of
> the wg that I somewhat agree with the need to revisit and look at a larger
> edit in order to describe the full scope of the problem.
>
> something else... ;-)). Co-editors will discuss offline on how to do the new
> revision.
>
> Marc.
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 30 Aug 2010 15:55:48 -0400

Jari - your plan sounds appropriate to me.  I will, of course, review the revised document when it comes to the IESG and would be happy to provide any guidance the WG might find helpful as it updates the document.

- Ralph

On Aug 27, 2010, at 10:41 AM 8/27/10, Jari Arkko wrote:

> We discussed this document today on the IESG call. Two major comments were made. First, Lars Eggert made the point that the document's explanation of interface choice based on interface characteristics (Problem 3.2 in Section 5) is far too simplistic. Interface speed, for instance, is just one factor among many, and that in reality, congestion, path characteristics and perhaps even application traffic patterns would have to be taken into account; most likely you would not know what kind of characteristics you can get before actually using the interface for the task at hand. Interface selection in order to optimize application performance is a very hard problem, perhaps unsolvable in the general case.
> 
> Second, Ralph Droms made the point that not all problems associated with the multiple interfaces are merely due to merging node-scoped information. Overlapping address space on different interfaces is a fundamental problem that cannot be solved through better host configuration mechanisms, for instance. The document currently focuses mostly on the configuration part of the problem today.
> 
> We also talked quite a bit about what the next steps for resolving these issues are. My opinion is that the document would be most useful when it describes the full scope of the problem. It would be particularly valuable to describe the fundamental issues, as that may help us understand potential limits of solutions. Here's what I would suggest that we do:
> 
> 1. Go through the document and expand/correct it to describe both the configuration merging problem and other fundamental issues around multiple interfaces (such as address or name space overlap).
> 
> 2. Change the parts of the document that talk aboout interface selection based on characteristics, and point out that for proper selection, many factors have to be considered.
> 
> 3. Go through the document and make a clearer statement about what problems it discusses are hard. For instance, Section 6 says: "Therefore, there is a need to define the appropriate behavior of an IP stack and possibly define protocols to manage these cases." This needs to be expanded in order to explain what issues are solvable through configuration object management, and what issues remain as fundamentally hard problems (address space overlap, knowing what throughput the path from one interface will give you, etc).
> 
> These changes are extensive, but in my opinion doable. I am sending the document back to the working group in order to make the next revision, and we will be doing a new WGLC/IETF Last Call when the revision is ready.
>

---

From: <[email-masked]>
Date: Tue, 31 Aug 2010 15:50:58 +0200

Hi Jari,

I agree with your plan too. We will also take into account comments from other reviewers (review from Routing Area Directorate, revision of security considerations,...).

BR,
Pierrick

> -----Message d'origine-----
> De : Marc Blanchet [mailto:[email-masked]]
> Envoyé : vendredi 27 août 2010 21:11
> À : Jari Arkko
> Cc : mif; IESG; Ralph Droms; draft-ietf-mif-problem-
> [email-masked]
> Objet : Re: [mif] Next steps on draft-ietf-mif-problem-statement-07.txt
>