Re: [mif] mif Digest, Vol 5, Issue 18

Min Hui <huimin.cmcc@gmail.com> Fri, 20 March 2009 09:05 UTC

Return-Path: <huimin.cmcc@gmail.com>
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 7A95A3A6A68 for <mif@core3.amsl.com>; Fri, 20 Mar 2009 02:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.406
X-Spam-Level:
X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 Z1oS0i0EwNx1 for <mif@core3.amsl.com>; Fri, 20 Mar 2009 02:05:30 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 60C0D3A6C20 for <mif@ietf.org>; Fri, 20 Mar 2009 02:05:30 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 24so1126627wfg.31 for <mif@ietf.org>; Fri, 20 Mar 2009 02:06:16 -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 :content-transfer-encoding; bh=69LLy4+crOowk0SnjDJa3K0JGTqEni6F0lEv4Pc5spU=; b=GusnUnkU0AWexfNgc9QMNWMX/GKX9ah7KWq0xhsN+7h+lGLd+5PXaZme9n5WpHsnD3 b9irovRRm64ATDHuZDhFIouQ1tpTVBSBFJTelUCx9wPGIq9l5YwAszBApEQbRyel3aPk PvY7H4sdj74W/4ZZR2Z2jlCvyEAM0IVc0xoWI=
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:content-transfer-encoding; b=q8xk0vZYH8EwGCbagPXXjIRv7rw6Dp4ctuwnu0c29jBZKBFmEe5UUBmAkxhYH9goV/ j1SmFBaRoBMtRd9n3ai8qBZ8bWN8rnj6XOk3G/T/SpSPx3M9dwuJ0y5nCU67BTIPm8kL j2EYw9QqTeAepPWdcxfc+CJhftyiRrRdGPvso=
MIME-Version: 1.0
Received: by 10.142.174.13 with SMTP id w13mr1381397wfe.212.1237539976766; Fri, 20 Mar 2009 02:06:16 -0700 (PDT)
In-Reply-To: <49C21159.6070302@it.uc3m.es>
References: <mailman.25.1237230002.1293.mif@ietf.org> <e360024e0903162241n245af6e0v5877d86cedc35ef3@mail.gmail.com> <5dca10d30903170225s332bc12bkae4da4281d5aaf30@mail.gmail.com> <e360024e0903170402u4450129by7f93774fad42e528@mail.gmail.com> <5dca10d30903180156r18efc2c3l7df6ecdfb2d2bfd6@mail.gmail.com> <49C21159.6070302@it.uc3m.es>
Date: Fri, 20 Mar 2009 17:06:16 +0800
Message-ID: <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com>
From: Min Hui <huimin.cmcc@gmail.com>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: mif@ietf.org, ma yc <ycma610103@gmail.com>
Subject: Re: [mif] mif Digest, Vol 5, Issue 18
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2009 09:05:31 -0000

Hi, marcelo


2009/3/19 marcelo bagnulo braun <marcelo@it.uc3m.es>:
> Min Hui escribió:
>>
>> Hi,  Yuanchen
>>
>> pls see my reply in line. thx.
>>
>> 2009/3/17 ma yc <ycma610103@gmail.com>:
>>
>>>
>>> Hi Min
>>>
>>> Thank you for your reply. Please check inline.
>>>
>>> Yuanchen
>>>
>>> 2009/3/17 Min Hui <huimin.cmcc@gmail.com>:
>>>
>>>>
>>>> Hi, Yuanchen
>>>>
>>>> For the first question, there are two situations.
>>>>
>>>> 1. the host sends data using one of its interfaces, and the correspond
>>>> node reply to the address of this interface. it's has no problem, the
>>>> host will receive the reply by the same interface.
>>>> 2. the network side initiate the communication, the host name will be
>>>> used in the DNS query to get a list of addresses, which one should be
>>>> choosed depends on the network side policy.
>>>>
>>>
>>> yuanchen> i agree with this scenario that the DNS query may result
>>> in a list of addresses. But i still don't understand what "network
>>> side initiated"
>>> means. IP flow is end-to-end and the other end node should
>>> make the DNS query and make the decision. Do you mean that the other end
>>> node should get some information from somewhere in the network to help
>>> the
>>> decision making? I think the requirement should be clarified.
>>>
>>>
>>
>> Sorry for misleading the "network side", the meaning is when the other
>> end node initiates the communication, it will not directly target one
>> of the addresses, the network element will make this decision and
>> return one address to this node.
>>
>
> I don't understand this
> Usually, the DNS is the one that returns the addresses, Are you considering
> that the network influences the DNS responses or are you thinking in
> something else?

I mean the network influences the DNS responses. DNS need to pick one
address among multiple addresses and return it to the node, the
network could have some selection policy to influence the DNS
responses.

>
> Regards, marcelo
>
>>
>>>>
>>>> For the second question, the element would be the gateway which in
>>>> charge of all the interfaces, e.g. PDN GW in 3GPP architecture, LMA in
>>>> PMIP domain.
>>>>
>>>
>>> yuanchen> I do not think LMA is a good example for MIF, since the LMA is
>>> for
>>> mobility management. PND GW in 3GPP also has the function of LMA.
>>> Such scenario sounds more like extension to PMIP for multiple interface
>>> node
>>> support. Netlmm may be better place for such topic.
>>>
>>>
>>
>> I'll avoid to discuss mobility management in mif, but I'm not very
>> sure whether PDN GW example isn't suitable to be discussed in mif,
>> because it's a network element which is responsible for all the
>> interfaces in the 3GPP architecture, and doesn't only appear as a LMA.
>>
>>
>>
>>>>
>>>> Thanks for your comments.
>>>>
>>>> - Hui Min
>>>>
>>>> 2009/3/17 ma yc <ycma610103@gmail.com>:
>>>>
>>>>>
>>>>> Hi, Min Hui,
>>>>>
>>>>> I an also confused on the requirement 5.
>>>>>
>>>>> As for the the flow directed to the multiple
>>>>> interface node, why does the network side need
>>>>> to decide which interface to forward the data?
>>>>>
>>>>> The dst address of the packet should be used for routing.
>>>>> The network just forwards the data according to the routing table.
>>>>> I do not see the needs for interface selection to route the flow.
>>>>>
>>>>> Also if you have the use case, i have the same concern
>>>>> as macelo, which elememt will be in chcarge of
>>>>> distributing the traffic?
>>>>>
>>>>> Thank you.
>>>>> Regards
>>>>> Yuanchen
>>>>>
>>>>>
>>>>>>
>>>>>> Date: Mon, 16 Mar 2009 18:13:29 +0100
>>>>>> From: marcelo bagnulo braun <marcelo@it.uc3m.es>
>>>>>> Subject: Re: [mif] about draft-hui-ip-multiple-connections-ps-02
>>>>>> To: Min Hui <huimin.cmcc@gmail.com>
>>>>>> Cc: mif <mif@ietf.org>
>>>>>> Message-ID: <49BE88B9.6010306@it.uc3m.es>
>>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>  5 Network side should be capable of distributing the IP flow
>>>>>>>  according to some parameters, such as IP address prefix, network
>>>>>>> type
>>>>>>>  and so on.
>>>>>>>
>>>>>>> i don't understnad what you mean by this one, could you expand?
>>>>>>>
>>>>>>> A: That is the policy in the network side. Corresponding to the
>>>>>>> policy
>>>>>>> of sending data mentioned in the fourth bullet, the policy of
>>>>>>> receiving data is also needed, which can be apply in the network
>>>>>>> side.
>>>>>>> The network can determine forward a specific IP flow to which
>>>>>>> interface of the destination host according to the policy.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> right, i see what you mean. I am not sure which element of the network
>>>>>> would do that... i mean, are you assuming that all interfaces are
>>>>>> being
>>>>>> connected to the same ISP? If not, i am not sure how would you do
>>>>>> this...
>>>>>>
>>>>>>>
>>>>>>> Regards, marcelo
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>
>