Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt
Qin Wu <sunseawq@huawei.com> Fri, 20 November 2009 02:19 UTC
Return-Path: <sunseawq@huawei.com>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8963A67D6 for <netext@core3.amsl.com>; Thu, 19 Nov 2009 18:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.305
X-Spam-Level: *
X-Spam-Status: No, score=1.305 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1]
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 NYoF35Lmm81X for <netext@core3.amsl.com>; Thu, 19 Nov 2009 18:19:44 -0800 (PST)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 46C433A6935 for <netext@ietf.org>; Thu, 19 Nov 2009 18:19:44 -0800 (PST)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTD005HRYGJPV@szxga01-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 10:19:31 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTD00MDVYGJGW@szxga01-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 10:19:31 +0800 (CST)
Received: from w53375 ([10.164.12.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTD00077YGEBM@szxml04-in.huawei.com> for netext@ietf.org; Fri, 20 Nov 2009 10:19:31 +0800 (CST)
Date: Fri, 20 Nov 2009 10:19:25 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Mohana Jeyatharan <Mohana.Jeyatharan@sg.panasonic.com>
Message-id: <006601ca6987$e49609a0$420ca40a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <20091026083001.DC4873A679C@core3.amsl.com> <5F09D220B62F79418461A978CA0921BD03AED937@pslexc01.psl.local>
Cc: netext@ietf.org
Subject: Re: [netext] Comments on :draft-wu-netext-local-ro-04.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2009 02:19:46 -0000
Hi, Mohana: Sorry for my late reply. Also thank you for your review and comments. please see my reply inline. Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com> To: "Qin Wu" <sunseawq@huawei.com> Cc: <netext@ietf.org> Sent: Monday, November 16, 2009 9:59 AM Subject: Comments on :draft-wu-netext-local-ro-04.txt Hi Qin, Read your ID. I have few comments. Please see below. BR, Mohana In abstract, "In case the correspondent node is connected to another local mobility anchor, the local mobility anchors connected by the correspondent node needs to be discovered firstly so that it can notify its mobile access gateways attached by the correspondent node to the mobile access gateway attached by the mobile node afterwards." <<<[Mohana] In abstract it is not very clear which entitiy notifies CN's MAG to MN's MAG. Perhaps a rewording may be useful>>> [Qin]: Yes, what we are really saying here is CN's LMA will notify CN's MAG to MN's MAG when MN's MAG communicate with CN's LMA using normal PBU/PBA. Maybe the proper way to say would be " so that the discovered local mobility anchor notity its mobile access gateways attached by the correspondent node...... " In abstract, Mobile access gateways create and refresh bindings using proxy binding update and acknowledgement messages. <<<[Mohana] What is the reason for this. Is this refering to PBU to LMA or PBU to MAG? Perhaps more clarity on this will help.>>> [Qin]: Okay, actually PBU/PBA will be used between MAGs to create binding when it is the first time for MAGs to setup localized routing path. during handover case, PBU/PBA will be used between MAGs to refresh binding. The reason to create and refresh bindings between MAGs attached by mobile node and correspondent node is quite similar to correspondent registration in the Mobile IPv6 Routing optimization between mobile node and correspondent node described in the section 11.7.2 of RFC3775. i.e., allowing correspondent node to cache mobile node's proxy care-of address or allowing mobile node to cache correspondent node' proxy care-of address, In conventions used section it is mentioned Local routing: Traffic between MN and CN does not pass through LMA and is locally routed in the same PMIPv6 domain. <<<[Mohana] Perhaps a re-wording may be necessary when referring to PMIPv6 domain. This should be aligned with the PS draft terminology. It should be same provider domain running PMIPv6 or some thing like that.>>> [Qin]: Okay, will check the wording to be consistent with PS draft. In conventions used section it is mentioned Local Routing Optimization Request (LROREQ): A message initiated by the MAG or LMA requesting the MAG or LMA to establish local routing optimization path between MN and at least one pair of CNs who communicate with MN. <<<[Mohana] why is there reference to at least one pair of CN. Are u saying at least a single CN? Not very clear>>> [Qin]: Right, thank for your good catching and correction. The reason to say at least one CN is in some cases, maybe MN will communicate with more than one CN, in this sense, LROREQ message may be sent from MN's LMA to each MAGs attached by serveral CNs which is communicating with MN. or sent from MN's MAG to each LMA which is registered by more than one CNs which is communicating with MN during inter-LMA handover case. In section 3 Scenario analysis for PMIPv6 local routing <<<[Mohana]The text before the figure 1 is refering to PMIPv6 domain. Again I think this should be single administrative/provider domain running PMIpv6.>>> [Qin]: Okay. In figure 1, <<<[Mohana]the MAG1 is connectedto IPv4 only or IPv4/IPv6 transport to LMA.>>> [Qin]: I am okay with this change in the figure 1. In last para in section 3 which is In all the above scenarios, MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or move from one PMIPv6 domains(i.e., MN's visited domains)to another. CN should stay with MN within the same PMIPv6 domain, e.g., MN moves to the visited domain to which CN belongs. Another example is MN and CN move to the same visited domain to which MN's LMA or CN's LMA does not belong. <<<[Mohana] Here PMIPv6 domain should be chnaged to administrative domain. Probably re-writing with respect to MN in home or visited domain and CN inhome or visited domain may be useful. Currently the text is not very clear>>> [Qin]: Agree there is room for improvement here, this paragraph will be reworded in accordance with the terminologies used in the PS draft In section 4, <<<[Mohana] the first bullet should be changed to administrative domain instaed of PMIPv6 domain. The second bullet says MN and CN attached to same LMA. But in section 3 it is mentioned inter LMA scenario as well. So, I am a bit confused as to whether the solution is not handling inter LMA scenario.>>> [Qin]: Yes, inter LMA scenario will be handled in one separate section of our Solution I-D. Our solution I-D mainly focuses on specifying the localize drouting protocol based on the first two scenarios described in the section 3. the common aspect of the first two scenarios is it does not require PMIP6 mobility entities discovery described in the PS draft. As regarding to the inter-LMA local routing scenario, it depends on PMIP6 mobility entities discovery, extra extended PMIP6 signaling is required between MN's MAG and CN's LMA. Therefore inter-LMA local routing case is separated from section 4 which is concentrating on the first two scenarios and addressed in the independent section, i.e., section 7. In section 4.1 <<<[Mohana] In this section there is reference to three different types of flags such as intra-LMA local routing flag, intra-MAG local routing flag, Enable detect local routing flag. A description of these in section 2 would be better for easy understanding.>>> [Qin]: Okay. Thank for your suggestion. In section 4.1, para 3, it is mentioned After successful local routing optimization process, if MN and CN attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA localrouting flag is set to value one, the MAG1 to which the MN attaches may send PBU message to the MAG2 which the CN attaches to. <<<[Mohana]Here I think there needs to be a rephrasing of sentence. I think you are referring to MN connected to MAG 1 and CN connected to MAG2 and intra LMA flag is set at the MAG and PBU/PBA exchange between th etwo MAGs. The sentence is not clear.>>> [Qin]: Okay, maybe we could say: " MAG1 to which the MN is connected may send PBU message to the MAG2 to which the CN is connected. " In section 4.1, in para 3 it is mentioned that MN's MAG is informed of CN MAG via LROResponse from LMA (assuming MAG initiated RO) and CN's MAG is informed of Mn'sMAG via LRO response and both MN's Mag and CN's MAGs are engaged in bi-ditectional PBU/PBA. <<<[Mohana]Here I have some comments. Mn's MAG will do LROReq to LMA. LMA can pass CN's MAG address in new option. Then MN's MAG can start PBU with CN's MAG. But the question I have is how does CN's MAG create the routing state for MN prefix. How does the CN's MAG know that this prefix is owned by MN and MN's MAG is actually proxying that prefix? The same when CN's MAG does PBU to MN's MAG. Probably, after getting the PBU from MN's MAG, CN's MAG can start PBU with CN's MAG. But again to create the the routing state for CN's prefix at MN's MAG the MN's MAG should know the prefix CN owns is valid prefix. Otherwise, I don't see how a valid routing state can be created. So, by reading this I feel a prefix ownership kind of information is needed in the PBU.>>> [Qin]: My understanding is if CN's MAG trusts MN's MAG, then CN's MAG must believe the prefix sent from MN's MAG is owned by MN. Because MN's MAG can check whether prefix is ownd by MN and used to create a valid routing before it send the prefix to the CN's MAG. That is to say we can assume there is a trust relationship between MN's MAG and CN's MAG. In oder for this, two possible ways in my mind are, 1) we assume a prior agreement between MN's MAG and CN's MAG. 2) the second way is we use IPSEC to setup Security association between MN's MAG and CN's MAG. By these two ways mentioned above, we can have trust relationship between MAGs, But what if MN's MAG establish trust relationship with CN's MAG and send the forged MN's prefix to CN's MAG, I think the prefix ownership validation may be useful in this scenario to help create valid routing state at CN's MAGs Therefore I would like to address this security threat in our solution I-D.Thanks for your good points. In the handover mechanims in section 4.1.1, it is mentioned that the nMAG1 will get context from old MAG (pMAG1). <<<[Mohana] But the question I have is when nMAG1 does PBU to CN's MAG, how can CN's MAG know that this prefix of MN is valid and nMAG1 is proxying the preifx. Bcos during handoff, the LMA is not involved. nMAG1 has no issue in knowing that MN;s prefix is given by LMA because when it does PBU to LMA it will know that this is a valid prefix. But that is not the case with CN's MAG.>>> [Qin]: Good question, when MN hands over from pMAG1 to nMAG1 and keeps on communication with CN, there is no trust relationship beforehand between nMAG1 and MAG2 to which CN is connected. That is true. But I think MN's prefix will keep unchanged during handover. The only change to MN is MN's Proxy CoA will . Is it necessary/mandatory to ask CN's MAG to validate MN's prefix ownership each time MN hands over? In my understanding, prefix ownership validation can be understood as routing reachability test(RRT) procedure defined in the RFC3775. But I am not sure RRT procedure will be done each time MN hands over according to RFC3775. Also in section 4.1 in second paragraph it is mentioned that MAG can send LRO req to LMA when Mn and CN are not attached to same MAG. <<<[Mohana] In this case, how does MAG know the CN address. What value will be attached in the Mn-CN pair mobility option. Is there some L2 message sent from Mn to MAG and all CN addresses are given in these. Probably such mentioning will be useful>>> [Qin]: How MAG know the CN address actually is beyond scope of this solution I-D. The possible way is MAG may look at data packet' destination address to know CN address.For the case where one MN communicates with one CN, MN-CN pair mobility option may include one MN's info and one CN's info. MN's. For the case where one MN communciates with several CNs, MN-CN pair mobility option may include one MN's info and several CNs' info. I have more comments. But rather than sending all at once I thought I will stop here for now. Thanks. > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, October 26, 2009 4:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-wu-netext-local-ro-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Proxy MIP extension for local routing optimization > Author(s) : W. Wu, B. Sarikaya > Filename : draft-wu-netext-local-ro-04.txt > Pages : 32 > Date : 2009-10-26 > > This document extends local routing in proxy Mobile IPv6 and defines > a localized routing optimization protocol within one PMIPv6 domain. > The protocol supports IPv4 transport network operation, IPv4 home > address mobility and handover. The Local mobility anchor/mobile > access gateway initiates local routing for the mobile and > correspondent node by sending messages to each mobile access > gateway/local mobility anchor. In case the correspondent node is > connected to another local mobility anchor, the local mobility > anchors connected by the correspondent node needs to be discovered > firstly so that it can notify its mobile access gateways attached by > the correspondent node to the mobile access gateway attached by the > mobile node afterwards. Mobile access gateways create and refresh > bindings > using proxy binding update and acknowledgement messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft.
- [netext] Comments on :draft-wu-netext-local-ro-04… Mohana Jeyatharan
- Re: [netext] Comments on :draft-wu-netext-local-r… Qin Wu
- Re: [netext] Comments on :draft-wu-netext-local-r… Mohana Jeyatharan
- Re: [netext] Comments on :draft-wu-netext-local-r… Qin Wu
- Re: [netext] Comments on :draft-wu-netext-local-r… Mohana Jeyatharan
- Re: [netext] Comments on :draft-wu-netext-local-r… Qin Wu
- Re: [netext] Comments on :draft-wu-netext-local-r… Mohana Jeyatharan
- Re: [netext] Comments on :draft-wu-netext-local-r… Qin Wu