Re: [mif] mif Digest, Vol 5, Issue 18
marcelo bagnulo braun <marcelo@it.uc3m.es> Fri, 20 March 2009 15:20 UTC
Return-Path: <marcelo@it.uc3m.es>
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 4D88C3A6B26 for <mif@core3.amsl.com>; Fri, 20 Mar 2009 08:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.417
X-Spam-Level:
X-Spam-Status: No, score=-6.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E06+wKUj8FJZ for <mif@core3.amsl.com>; Fri, 20 Mar 2009 08:20:23 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F01F33A698F for <mif@ietf.org>; Fri, 20 Mar 2009 08:20:22 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (164.pool85-53-152.dynamic.orange.es [85.53.152.164]) by smtp01.uc3m.es (Postfix) with ESMTP id D4CBFBA00ED; Fri, 20 Mar 2009 16:21:07 +0100 (CET)
Message-ID: <49C3B463.8060206@it.uc3m.es>
Date: Fri, 20 Mar 2009 16:21:07 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Min Hui <huimin.cmcc@gmail.com>
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> <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com>
In-Reply-To: <5dca10d30903200206y549f2d49u397ce4d58791236c@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16532.000
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 15:20:24 -0000
Min Hui escribió: > 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. > we need to look into this a bit more in detail...i am not sure it is the best idea to have the network tweaking the dns responses. regards, marcelo > >> 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 >>> >>> >>> >> > >
- Re: [mif] mif Digest, Vol 5, Issue 18 ma yc
- Re: [mif] mif Digest, Vol 5, Issue 18 pierrick.seite
- Re: [mif] mif Digest, Vol 5, Issue 18 Min Hui
- Re: [mif] mif Digest, Vol 5, Issue 18 ma yc
- Re: [mif] mif Digest, Vol 5, Issue 18 ma yc
- Re: [mif] mif Digest, Vol 5, Issue 18 Min Hui
- Re: [mif] mif Digest, Vol 5, Issue 18 ma yc
- Re: [mif] mif Digest, Vol 5, Issue 18 marcelo bagnulo braun
- Re: [mif] mif Digest, Vol 5, Issue 18 Min Hui
- Re: [mif] mif Digest, Vol 5, Issue 18 marcelo bagnulo braun
- Re: [mif] mif Digest, Vol 5, Issue 18 Scott Brim
- Re: [mif] mif Digest, Vol 5, Issue 18 ma yc
- Re: [mif] mif Digest, Vol 5, Issue 18 Scott Brim
- Re: [mif] mif Digest, Vol 5, Issue 18 ma yc