Subject: [mif] WG LC for MIF PS

From: Hui Deng <[email-masked]>
Date: Fri, 12 Mar 2010 16:20:56 +0800

We appear ready to start the working group last call for our PS documents.  
This is a two-week WGLC.
http://www.ietf.org/id/draft-ietf-mif-problem-statement-02.txt

This is a two week WGLC finishing on March 26.  Please send substantive
review comments to [email-masked] 

Thanks,

-Hui
 		 	   		  
_________________________________________________________________
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
https://signup.live.com/signup.aspx?id=60969

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Mar 2010 10:52:01 +0100

Thank you for the draft and the LC.

I support the draft because I find to deal in much detail with the
problem of multiple interfaces.

However, I have many comments on it too.  I will provide now only some.

> A MIF host (H1) has an active interface(I1) connected to a network 
> (N1) and another active interface (I2) connected to a network (N2). 
> The user or the application is trying to reach an IP address (IP1). 
> Any of the following situations may occur: 1.  For the IP1 address 
> family, H1 has one default route (R1, R2)

Is IP1 an address family or an address?  You say both above.

What does it mean "default route(R1, R2)"?

For one address family (IPv4 or IPv6) there's typically a single default
route.

Alex

---

From: <[email-masked]>
Date: Thu, 18 Mar 2010 11:24:03 +0100

Hi Alex, 

Thanks for the review, please see inline.

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de
> Alexandru Petrescu
> Envoyé : jeudi 18 mars 2010 10:52
> À : [email-masked]
> Objet : Re: [mif] WG LC for MIF PS
> 

Many thanks.

> Is IP1 an address family or an address?  You say both above.

IP1 is an address, please check if the proposed rewording of Bullet 1 avoid confusion.

> For one address family (IPv4 or IPv6) there's typically a single default

You're right, and Bullet 1. needs clarification. Does the following better?

1. For the address family of IP1, H1 has one default route (R1) via
       network (N1).  IP1 is only reachable by N2.  H1 stack uses R1
       and tries to send through I1.  IP1 is never reached or is not the
       right target.

> Alex
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Mar 2010 19:28:00 +0100

Hi Pierrick,

thanks for the reply,

Le 18/03/2010 11:24, [email-masked] a écrit :
[..]

>>> A MIF host (H1) has an active interface(I1) connected to a
>>> network (N1) and another active interface (I2) connected to a
>>> network (N2). The user or the application is trying to reach an
>>> IP address (IP1). Any of the following situations may occur: 1.
>>> For the IP1 address family, H1 has one default route (R1, R2)
>>
>> For one address family (IPv4 or IPv6) there's typically a single
>> default route.
>>
>
> network (N1).  IP1 is only reachable by N2.  H1 stack uses R1 and
> tries to send through I1.  IP1 is never reached or is not the right
> target.

Even if I don't really understand... it seems ok.  The correction seems
better than the initial text, we could leave it that way.

For the details.

I don't understand why the address family plays a role here.  IT seems
in the description that the topological reachability of an address (of
any family: v4 or v6) is the breaking factor, and not the address family.

If I wanted to point to a problem of default routes and the address
families (only 2, actually: ipv4 and ipv6) then the description would
necessary talk tunnels too: the IPv4 default route points to the
IPv4-first-hop IPv4 gw and the IPv6 default route points to another
IPv6-first-hop IPv6 gw.  If trying to encapsulate IPv4 in IPv6 in IPv4
one finds out that it's difficult to choose an outgoing interface of an
IPv4 packet between the IPv4 default route and the IPv4-in-IPv6 default
route.  Something like that.

Coming back to the suggested text: if IP1 is not topologically reachable
by N1 then the MIF host is badly configured with a default route to N1.

At the same time it may be possible that IP1 is not reachable via N1 as
MIF host would believe it is, but via some other longer way, in which
case the packet _would_ get delivered, even though not the way the MIF
host would believe it to take.

I think an illustration would be useful, if you need I can draw.

Also, I want to say that there is indeed a problem with the default
routes in a host having multiple interfaces.  Typically only one default
route is actually taken by leaving MIF host, despite the presence of
potentially numerous default route entries in the routing table.
Several default routes may appear in the routing table with some DHCP
implementations or mixtures DHCP+ppp.

In practice this isn't always a problem.

I believe it becomes a problem when the application programmer is not
aware of which path the outgoing packets take.

To my interest this is a problem when the application expects the
outgoing traffic to take both default routes at the same time and the
kernel doesn't obey.

If we drew pictures we could agree probably.

Thanks,

Alex

>
>> Alex
>>
>> _______________________________________________ mif mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Mar 2010 14:43:39 -0700 (PDT)

I read this draft. I also support this draft moving forward because it describes the problems nicely.
My comments are as follows:
1. Reading statements like 
there is no set of high level API to
   provide all required services for a connection manager
 
the draft sounds like a requirements draft while it is in fact PS draft.
2. All references are informational. In PS documents (RFC 4093, 4487, etc.) formative references can be made, like RFC 1122, 3484, 4294, etc. so why not have some?
3. I think Section 11 should be removed.
 
Here are some typos I found:
s/interfac
   es (e.g., WiMAX and CDMA, LTE and HSPA, etc)/interfaces (e.g., WiMAX and CDMA, LTE and HSPA, etc.)
s/single interace/single interface
s/Default Address Selection [RFC3484]/Default Address Selection specification [RFC3484]
s/MIF similar issues/issues similar to MIF
s/of a same connection/of the same connection
In Sec. 4.3 it says
Any of the following situations may occur:
but only one is listed?
s/4) Address selectiona and 5) connexion management/4)Address selection and 5) connection management
s/the [RFC1122] strong model/the strong host model [RFC1122]

Regards,
 
Behcet

---

From: Zhen Cao <[email-masked]>
Date: Sat, 20 Mar 2010 13:46:22 +0800

Dear Authors,

Some comments below:

3.1 Below IP Interaction
Do we need to consider some below-ip layer techniques like Virtual interfaces?

3.4 Address selection
It is good to mention that some OS like OSX does not implement
3484-like policy table. Default behavior of the 3484 policy table is
to prefer IPv6 over IPv4, but this behavior in some situations are not
optimal and need to be changed.

3.5 Finding and Sharing IP Addresses with Peers
I do not think we need to consider the application referral behavior,
and it is out of scope of mif. I suggest removing the Grobj referral
to ip address referral generally.

4.1, bullet 6,
it is not a dns selection problem, rather it is the address selection problem.
The dns selection problem related to DNS64 is covered in
draft-wing-behave-dns64-config-02.

a typo here is "quaranteed", should be "guaranteed"

4.3 Address Selection Policy
I suggest add some text on IP family selection as one bullet, some
symptoms are introduced in draft-cao-mif-ifs.

"The inconsistency of host's application IP family, interface address
family and remote end's IP family makes the IP family selection
problem difficult.  Wrongly choosing the ip family will result into
communication failure. "

Thanks,
Zhen

2010/3/12 Hui Deng <[email-masked]>:
> ________________________________
> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.

---

From: <[email-masked]>
Date: Sat, 20 Mar 2010 08:32:26 +0100

Hi,

> draft-wing-behave-dns64-config-02.

I don't fully follow - this section is talking about dns server selection problems and also address usage limitations. Do you think the bullet 6 should be somewhere else then? Then probably also bullet 4 and 5? IMHO it is ok to have both dns server selection problems and problems on limited scope of usability of addresses learned from DNS servers. 

The draft-wing-behave-dns64-config might be something to add as a reference in section 4, but this has been also described earlier in draft-savolainen-mif-dns-server-selection draft. 

Best regards,

Teemu

---

From: Zhen Cao <[email-masked]>
Date: Sun, 21 Mar 2010 17:51:43 -0700

> I don't fully follow - this section is talking about dns server selection problems and also address usage limitations. Do you think the bullet 6 should be somewhere else then? Then probably also bu…

OK, the problems are linked.

> The draft-wing-behave-dns64-config might be something to add as a reference in section 4, but this has been also described earlier in draft-savolainen-mif-dns-server-selection draft.

Yes, I did not noticed that your draft had already mentioned the
problem of DNS64 selection. Thanks.

Regards,
Zhen

---

From: <[email-masked]>
Date: Mon, 22 Mar 2010 14:50:16 +0100

Hi,

Here are some comments from me:

* Would be good to have some definitions for Provisioning Domain and Administrative Domain, and especially clarify if one administration domain can contain multiple provisioning domains

* The document at least in two places recommends standardization of API, e.g. at page 7:"standardization of such on API".. and page 11:"So, clearly, standardization could bring harmonization, e.g. a standard API could be considered.". I have two issues with this: 

1) These suggestions are not inline with other problems, regarding them there are no suggestion of standardization of something to solve them. For example, we could say regarding routing that "standardization of routing provisioning solutions would be good" and so forth. I do not think these suggestions really belong to this document. Unless this will be both Problem Statement and Analysis document combined?

2) I do not think IETF is the right place to standardize APIs. At most, an Informational document describing an example posix-style API could be ok.

* section 4.1:".. IP address is not the right one..", I'd prefer:"not the same one". 

* section 4.1, could say instead: "Therefore, the application tries to connect to the wrong destination host or to the wrong interface of the destination host, which may imply security issues or result in lack of service." ?

* section 4.4: Could this be expanded a bit? I mean does this refer to IPv6 and site-multihoming, where multiple prefixes are available on a single interface? And can this happen with IPv4 as well or only IPv6?

* Page 11: On page 10 problem categories were numbered (1, 2, 3..) but here they are shown as bullets. Would be clearer to number also the bullets?

Best regards,

Teemu

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 23 Mar 2010 09:06:18 -0700

> * Would be good to have some definitions for Provisioning Domain and Administrative Domain, and especially clarify if one administration domain can contain multiple provisioning domains

We agree. will write something to that effect.

> 2) I do not think IETF is the right place to standardize APIs. At most, an Informational document describing an example posix-style API could be ok.

We agree. We will remove the sentence on page 11 and rewrite the one on 
page 7.

> * section 4.1:".. IP address is not the right one..", I'd prefer:"not the same one". 

fine.

> * section 4.1, could say instead: "Therefore, the application tries to connect to the wrong destination host or to the wrong interface of the destination host, which may imply security issues or re…

fine.

> * section 4.4: Could this be expanded a bit? I mean does this refer to IPv6 and site-multihoming, where multiple prefixes are available on a single interface? And can this happen with IPv4 as well…

agreed. will expand.

> * Page 11: On page 10 problem categories were numbered (1, 2, 3..) but here they are shown as bullets. Would be clearer to number also the bullets?

agreed.

> Best regards,

Thanks!

Marc.

-- 
=========
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: Marc Blanchet <[email-masked]>
Date: Tue, 23 Mar 2010 09:06:44 -0700

> Do we need to consider some below-ip layer techniques like Virtual interfaces?

in the first meetings, it was clearly said and agreed that these 
techniques were out of scope of PS.

> 3484-like policy table. 

This belongs to the current-practices doc.

> Default behavior of the 3484 policy table is

How much this comment related to MIF? Can you describe a specific scenario?

> to ip address referral generally.

this is on the contrary to another comment asking to include Grobj, as 
agreed in Hiroshima. See: http://trac.tools.ietf.org/wg/mif/trac/ticket/4

> draft-wing-behave-dns64-config-02.

draft-wing-behave-dns64-config covers issues about a least preferable 
path for a dual-stack host on a shared v6 network with DNS64/NAT64 to 
reach a v4 destination. It has nothing to do with multiple interfaces.

Can you provide a specific MIF scenario that brings another issue that 
is not related to the current text in 4.1 bullet 6?

> a typo here is "quaranteed", should be "guaranteed"

thanks.

> problem difficult. 

Can you be more explicit on the issue with MIF? This looks a generic 
statement about address selection, not related to MIF.

> Wrongly choosing the ip family will result into
> communication failure. "

Thanks for the comments, Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 23 Mar 2010 09:06:58 -0700

> the draft sounds like a requirements draft while it is in fact PS draft.

stating a fact like there is no high level API is not necessarily a 
requirement. A REQ document would define requirements such as " This 
feature MUST be ...".  I don't think we have this kind of text in the 
current PS.

> 2. All references are informational. In PS documents (RFC 4093, 4487, etc.) formative references can be made, like RFC 1122, 3484, 4294, etc. so why not have some?

I'm not sure what we gain to have normative references for PS documents. 
Having said that, if you can provide the list of normative references, 
then we can change them.

> 3. I think Section 11 should be removed.

does not harm. will remove.

> s/the [RFC1122] strong model/the strong host model [RFC1122]

thanks!

Marc.

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 23 Mar 2010 18:51:45 -0700

Hello,

Some of us have put together a draft to begin working on the MIF Current Practice Analysis [1]. As a starting point to the analysis, we have re-classified / expanded on the problems listed in earlier version of the problem statement, and communicated that to the authors. Some of our comments were integrated in the last PS draft, but not all.

So my comment towards WGLC is that I'd like the full problem list documented in our draft [1] to be incorporated into the MIF PS. If we can't agree to do that, I'd like to discuss a bit more why some of the problems listed in our drafts were not considered valid.

Thanks.

--julien

[1] http://tools.ietf.org/html/draft-cao-mif-analysis-00

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 23 Mar 2010 21:59:17 -0700

> Hello,

Julien, is there any way you can be more specific in what is missing?

Marc.

---

From: <[email-masked]>
Date: Wed, 24 Mar 2010 17:57:58 +0100

Hi,

>From my understanding:

The PS does not describe the problem when a terminal supports multiple connection managers. I agree this is an issue and this problem will be added.

Document [1] considers domain selection issue. Actually, I think we are inline here: the PS covers that problem with connection manager considerations (the PS considers domain selection as a task of the connection manager). 

Julien, if I missed something, do not hesitate to correct me.

Pierrick

> De : [email-masked] [mailto:[email-masked]] De la part de Marc
> Blanchet
> Envoyé : mercredi 24 mars 2010 05:59
> À : Laganier, Julien
> Cc : [email-masked]; Hui Deng; [email-masked]
> > Some of us have put together a draft to begin working on the MIF Current
> Practice Analysis [1]. As a starting point to the analysis, we have re-
> classified / expanded on the problems listed in earlier version of the
> problem statement, and communicated that to the authors. Some of our
> comments were integrated in the last PS draft, but not all.
> >
> > So my comment towards WGLC is that I'd like the full problem list
> documented in our draft [1] to be incorporated into the MIF PS. If we
> can't agree to do that, I'd like to discuss a bit more why some of the
> problems listed in our drafts were not considered valid.
> >
> > Thanks.
> >
> > --julien
> >

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 24 Mar 2010 12:23:52 -0700

A connection manager is just one particular instance of an entity that performs domain selection, and the proliferation of connection managers on a single host illustrates the challenges involved with multiple policies on domain selection playing simultaneously.

So the two missing in points in the draft are 1) issues with domain selection, and 2) issues with different policies for domain selection being provisioned by different actors, e.g., end-user, corporate IT admin, ISP, operator.

I believe these are spelled out in [1]

--julien

> -----Original Message-----
> From: [email-masked] [mailto:pierrick.seite@orange-
> ftgroup.com]
> Sent: Wednesday, March 24, 2010 9:58 AM
> To: [email-masked]; Laganier, Julien
> Cc: [email-masked]; [email-masked]; draft-cao-mif-
> [email-masked]
> Subject: RE: [mif] WG LC for MIF PS
> 
> 
> Hi,
> 
> From my understanding:
> 
> The PS does not describe the problem when a terminal supports multiple
> connection managers. I agree this is an issue and this problem will be
> added.
> 
> Document [1] considers domain selection issue. Actually, I think we are
> inline here: the PS covers that problem with connection manager
> considerations (the PS considers domain selection as a task of the
> connection manager).
> 
> Marc

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Mar 2010 12:36:52 -0700 (PDT)

Here is one more issue that I forgot to write about last week:
In Sec. 3.1 you say:
Proxy MIP allows sharing a single IP address across multiple interfac
   es (e.g., WiMAX and CDMA, LTE and HSPA, etc) to disparate networks.
   From the IP stack view on the node, there is only a single interface
   and single IP address.  Therefore, this situation is out of scope.
   Furthermore, link aggregation done under IP where a single interace
   is shown to the IP stack is also out of scope.

I don't quite understand what this paragraph is really referring to. Are you talking about MIPv6 which has the Home Address concept, i.e. outside world know MN by its HoA and the different interfaces only get care-of addresses which are temporary. Is the problem described above referring to this?
In PMIPv6 each interface is independent of others, at least in the current RFC 5213. Are you saying that this causes problems?

Regards,

Behcet

----- Original Message ----
> From: Marc Blanchet <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: [email-masked]
> Sent: Tue, March 23, 2010 11:06:58 AM
> Subject: Re: [mif] WG LC for MIF PS
> 
> I read this draft. I also support this draft 
> moving forward because it describes the problems nicely.
> My comments are 
> as follows:
> 1. Reading statements like there is no set of high level API 
> to

stating a fact like there is no high level API is not 
> necessarily a requirement. A REQ document would define requirements such as " 
> This feature MUST be ...".  I don't think we have this kind of text in the 
> current PS.

> 2. All references are informational. In PS documents 
> (RFC 4093, 4487, etc.) formative references can be made, like RFC 1122, 3484, 
> 4294, etc. so why not have some?

I'm not sure what we gain to have 
> normative references for PS documents. Having said that, if you can provide the 
> list of normative references, then we can change them.

> Section 11 should be removed.

does not harm. will 
> remove.

>    es (e.g., WiMAX and CDMA, LTE and HSPA, 
> etc)/interfaces (e.g., WiMAX and CDMA, LTE and HSPA, etc.)
> s/single 
> s/Default Address Selection [RFC3484]/Default 
> Address Selection specification [RFC3484]
> In 
> Sec. 4.3 it says
> but 
> only one is listed?
> s/4) Address selectiona and 5) connexion 
> management/4)Address selection and 5) connection management
> s/the 
> [RFC1122] strong model/the strong host model 
> [RFC1122]

thanks!

Marc.

> href="mailto:[email-masked]">[email-masked]
> 
> href="https://www.ietf.org/mailman/listinfo/mif" target=_blank 

-- =========
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: <[email-masked]>
Date: Thu, 25 Mar 2010 03:07:08 +0100

We are on the same page :-)

> De : Laganier, Julien [mailto:[email-masked]]
> Envoyé : mercredi 24 mars 2010 20:24
> À : SEITE Pierrick RD-RESA-REN; [email-masked]
> Cc : [email-masked]; [email-masked]; draft-cao-mif-
> [email-masked]
> Objet : RE: [mif] WG LC for MIF PS
> 
> A connection manager is just one particular instance of an entity that
> performs domain selection, and the proliferation of connection managers on
> a single host illustrates the challenges involved with multiple policies
> on domain selection playing simultaneously.
> 
> So the two missing in points in the draft are 1) issues with domain
> selection, and 2) issues with different policies for domain selection
> being provisioned by different actors, e.g., end-user, corporate IT admin,
> ISP, operator.
> 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: liu dapeng <[email-masked]>
Date: Sat, 27 Mar 2010 09:42:22 +0800

Hi Teemu,

Thanks for the comments, please see inline.

2010/3/22, [email-masked] <[email-masked]>:
> * Would be good to have some definitions for Provisioning Domain and
> Administrative Domain, and especially clarify if one administration domain
> can contain multiple provisioning domains
>
> * The document at least in two places recommends standardization of API,
> e.g. at page 7:"standardization of such on API".. and page 11:"So, clearly,
> standardization could bring harmonization, e.g. a standard API could be
> considered.". I have two issues with this:

> 1) These suggestions are not inline with other problems, regarding them
> there are no suggestion of standardization of something to solve them. For
> example, we could say regarding routing that "standardization of routing
> provisioning solutions would be good" and so forth. I do not think these
> suggestions really belong to this document. Unless this will be both Problem
> Statement and Analysis document combined?

In my personally opinion, providing MIF APIs to the application layer
could help to solve the MIF problem, and in the WG discussion, seems
people agree with this point...

> 2) I do not think IETF is the right place to standardize APIs. At most, an
> Informational document describing an example posix-style API could be ok.

Agree, maybe an informational document is more proper.

Best wishes,
Dapeng Liu

> * section 4.1, could say instead: "Therefore, the application tries to
> connect to the wrong destination host or to the wrong interface of the
> destination host, which may imply security issues or result in lack of
> service." ?
>
> * section 4.4: Could this be expanded a bit? I mean does this refer to IPv6
> and site-multihoming, where multiple prefixes are available on a single
> interface? And can this happen with IPv4 as well or only IPv6?
>
> * Page 11: On page 10 problem categories were numbered (1, 2, 3..) but here
> they are shown as bullets. Would be clearer to number also the bullets?
>
> Best regards,
>
> Teemu
>

---

From: Zhen Cao <[email-masked]>
Date: Mon, 29 Mar 2010 18:24:54 +0800

Hi Marc,

Thanks for the response, see my reply inline.

-Zhen
On Wed, Mar 24, 2010 at 12:06 AM, Marc Blanchet
<[email-masked]> wrote:
> in the first meetings, it was clearly said and agreed that these techniques
> were out of scope of PS.

Agree, but MIF WG should be fully aware of the virtual interface?

> How much this comment related to MIF? Can you describe a specific scenario?

If the host has two interfaces, one connects to the IPv6-only and one
connection to IPv4, and a dual stack application may be restricted by
the address selection policy.

> agreed in Hiroshima. See: http://trac.tools.ietf.org/wg/mif/trac/ticket/4

Okay, but I do not know if it is appropriate to refer to some
individual document.

---

From: <[email-masked]>
Date: Mon, 29 Mar 2010 15:02:03 +0200

Hi,

> > agreed in Hiroshima. See:
> http://trac.tools.ietf.org/wg/mif/trac/ticket/4
> 

Actually the text is dealing with referrals in general, and refer to
GROBF as an example.

Regards,
Pierrick

---

From: <[email-masked]>
Date: Wed, 31 Mar 2010 15:22:22 +0200

Hi Zhen,

> the address selection policy.

Ok, the PS text can be updated to state that default selection, as per
RFC3484, is not always optimal.

Regards,
Pierrick

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 31 Mar 2010 08:27:17 -0700

Hello,

> RFC3484, is not always optimal.

RFC 3484 address selection not being optimal seems like an orthogonal problem to a host being attached to multiple network domains since the issue can also occurs when a host is attached to a single domain. So I don't think we should list this in the PS.

--julien