From marcelo@it.uc3m.es Sun Sep 6 02:25:43 2009 Return-Path: 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 2F6F63A67AB for ; Sun, 6 Sep 2009 02:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 h9x6NAGH2o9D for ; Sun, 6 Sep 2009 02:25:42 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 75E5E3A67A8 for ; Sun, 6 Sep 2009 02:25:42 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (126.pool85-53-142.dynamic.orange.es [85.53.142.126]) by smtp01.uc3m.es (Postfix) with ESMTP id 7536DB9FF8B; Sun, 6 Sep 2009 11:26:05 +0200 (CEST) Message-ID: <4AA3802D.2070104@it.uc3m.es> Date: Sun, 06 Sep 2009 11:26:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16870.006 Subject: [netext] Netext2 bof draft minutes posted 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 09:25:43 -0000 Hi, The draft minutes for the bof have been posted. thanks to Telemaco for taking the minutes! Please send corrections if you have any. Regards, marcelo From marcelo@it.uc3m.es Sun Sep 6 02:26:17 2009 Return-Path: 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 3141E3A67AB for ; Sun, 6 Sep 2009 02:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 0qid1f83B12j for ; Sun, 6 Sep 2009 02:26:16 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 67C8E3A67A8 for ; Sun, 6 Sep 2009 02:26:16 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (126.pool85-53-142.dynamic.orange.es [85.53.142.126]) by smtp01.uc3m.es (Postfix) with ESMTP id 0FC91B9FF8B for ; Sun, 6 Sep 2009 11:26:40 +0200 (CEST) Message-ID: <4AA3804F.9040701@it.uc3m.es> Date: Sun, 06 Sep 2009 11:26:39 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: netext@ietf.org References: <4AA3802D.2070104@it.uc3m.es> In-Reply-To: <4AA3802D.2070104@it.uc3m.es> 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-16870.006 Subject: Re: [netext] Netext2 bof draft minutes posted 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 09:26:17 -0000 and the link is: http://www.ietf.org/proceedings/75/minutes/netext2.txt marcelo bagnulo braun escribió: > Hi, > > The draft minutes for the bof have been posted. > > thanks to Telemaco for taking the minutes! > > Please send corrections if you have any. > > Regards, marcelo > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Basavaraj.Patil@nokia.com Sun Sep 6 14:44:10 2009 Return-Path: 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 C39053A68FE for ; Sun, 6 Sep 2009 14:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 NLvG4-lQRHEq for ; Sun, 6 Sep 2009 14:44:09 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6EE1E3A6806 for ; Sun, 6 Sep 2009 14:44:08 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n86LiH5V028990 for ; Mon, 7 Sep 2009 00:44:18 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 00:44:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 00:44:25 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Sun, 6 Sep 2009 23:44:25 +0200 From: To: Date: Sun, 6 Sep 2009 23:44:24 +0200 Thread-Topic: Draft minutes of WG meeting at IETF75 Thread-Index: AQHKLzsyBHJUE7JvJkizK0kVcMkFjQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Sep 2009 21:44:25.0479 (UTC) FILETIME=[33F59970:01CA2F3B] Subject: [netext] Draft minutes of WG meeting at IETF75 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 21:44:10 -0000 Minutes of : Network-Based Mobility Extensions (netext) At: IETF75 (Stockholm) THURSDAY, July 30, 2009 from 1300-1500=20 Chairs: Basavaraj Patil =20 Rajeev Koodli =20 Credit for these minutes: 1. Marco Liebsch 2. Juan Carlos Zuniga =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Agenda bashing, Blueseheets, Note takers, Jabber scribes 5 Mins =20 Basavaraj Patil: First part/hour will be dedicated to the 3 approved items: Localized routing, Runtime LMA association and Bulk registrations=20 Second part will be dedicated to new proposals =20 =20 2. WG Status update 10 Mins Chairs =20 BP: Charter includes 3 deliverables - Netext2 will determine flow mobility and multiple interface candidate features for re-chartering=20 Localized routing, not to be refered to as routing optimization Sri: scope in single MAG? BP: hold discussion for Marco's presentation Behcet Sarikaya: no multiple MAGs then no routing optimizations BP: Please hold discussion for Marco=92s presentation 3. Localized Routing discussion 30~40 Mins Problem statement, Scope and Solutions discussion I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt Presenter: Marco Liebsch Qin Wu: initiation of signaling. What is the sequence between initiating signaling and detection? Shouldn=92t it be the other way around?=20 ML: there is no order implied. This is a list of requirements and more may be needed=20 QW: before setting up routing pat you should as LMA to localize routing. ML: You mean negotiation? Rajeev: What negotiation? QW: Negotiate the scenario RK: You are assuming a certain bahaviour. Let=92s see slides first Sri Gundavelli: ?? RK: Ref arch 1, Is there LMA-LMA signaling? ML: It depends on the solution. We should first decide on the use cases=20 RK: regardless of the use cases, we should decide if inter-LMA signalling is in scope or not=20 ML: LMA2 should be aware somehow RK: currently we assume no LMA-LMA signaling ML: my opinion is that inter-LMA signaling should not be a reason to rule out scenarios=20 Ken Leung: I agree that this is an architecture and use cases, so no solution assumptions are made=20 Alper Yegin: LMA most likely will be needed QW: In this figure, LMA1 and LMA2 are in one domain. If they were in a different domain, would they be considered. =20 ML: My understanding was that the scope was for a single domain BP: Only in the case of MN registered to different LMA is then this considered. IF they have different prefixes then there is no need for siganlling=20 RK: This doesn=92t imply communication between the two LMAs. MAG1 can talk = to LMA2 ML: this is the same level AY: In the roaming case MAG1 may not have security association to LMA2. This could be a single PMIP domain still. MAG to MAG may be needed, so we will need to extend beyond the current only LMA-MAG signaling paradigm=20 SG: Even with different operators, we should be able to solve the problem with MAG-LMA signaling=20 RK: We should not rule it out, but we still have to discuss ML: So multiple LMAs are considered but signalling should still be discussed=20 JeanMichel Combes: ??? Subir Das: With roaming we should then consider other things. Two LMA in the same domain (operator) makes sense, but between two different operators we might not need localized routing.=20 BP: we currently refer to LMA and MAG as one domain SD: in terms of localized routing, this only makes sense for a single operator. Otherwise you need a lot more =20 RK: so far we assume a 1-1 mapping PMIP domain and operator. If you have LMA out of domain (operator) it is a different case and this is not in scope=20 SG: they have to be intra domain, otherwise there is no security associatio= n SG: if you roam in a PMIP6 domain, then is in scope SG: as long as boxes have a security association ML: cannot restrict scope if terminology is not agreed SG: ?? AP: In WiMAX dynamic security association can be done between one local MAG and remote LMA=20 SD: one to one mappings between all combinations is possible, but we should restrict=20 BP: discussion to be taken in mailing list BS: restrict to single domain and then recharter ML: too restricting ML: continuation on issues, terminology. We assume single and multi-MAG scenarios. Multiple LMAs still under discussions.=20 BP: We agree on MAGs in same domain, but still debate on multiple domains KL: Single should be considered too. ML: it is implicit SG: Is internetwork signaling? Telemaco Melia: Negotiation between MN=92s and CN=92s MAG should be tight to inter-domain=20 RK: We won=92t get agreement if we don=92t restrict to single domain Ryuji Kakikawa: This IPv4 may create a big problem. But using IPv4 transport does not make sense.=20 KL: Typically transport will be the same, but some transition networks may have both IPv4 and IPv6, so we should not preclude this mixed transport.=20 SD: We should clarify the assumptions otherwise the solution may be very different=20 BP: send text on mailing list SG: No need to create restrictions. Also all MAGs in the same domain is for sure in scope. Intra-MAG in the same domain would not have address overlapping.=20 RK: we should not preclude but we should not explicitly design for that, as LMA could initiate as well=20 =20 RK: We were planning to spend 1 hr in three topics and we just spent 1 hr in the first topic alone. We should discuss these remaining issues in the mailing list.=20 BP: To make progress, should we consider this document baseline? About 12 in favor, none against BS (for Jari in jabber): for adopting as well - Solution presentations skipped in lieu of time constraints 4. Runtime LMA Assignment Support for Proxy Mobile IPv6"=20 I-D: draft-korhonen-netext-redirect-02 Jouni Korhonen - 10 Mins Jouni presents: *LMA re-selection during running connection *Define solution that is not dependent on external infrastructure *Issues with selection *Typically implies AAA interaction *From LMA point of view the selection of the MAG may be suboptimal *Initiating a new selection is costly *Why runtime selection of LMA? *Loadbalancing *current solution draft has two solution approaches Discussion:=20 Rajeev: You look at PBU from LMA1 to LMA2? Sri: It's just a relay Rajeev: This protocol is about telling MAG about a different LMA. Why do we overload the proposal by sending PBU from LMA1 to LMA2? Alper: First PBU not for discovery, but to create a BCE. Its optimization Rajeev: That optimization should not be part of this protocol Just have LMA1 telling MAG: go to LMA2. Out of scope should be how LMA1 finds LMA2 Jouni: May be misleading Ryuji: Seems very simmilar to HAHA document Rajeev: Everything going between LMAs should be out of scope of this docume= nt PBU is misleading, as we know what PBU means Jean-Michel: LMA redirect solution exists, why not using it? Jouni: I don't know how to use it here Jouni: Vijay said the redirection is not applicable to this space Sri: At what point is the BCE created on the LMA2? Jouni: Depends on the implementation Sri: Assume three boxes, at what point is the BCE created? Jouni: Here (points to the slides, I guess it was at the PBU between LMAs) Rajeev: Then I have a problem. Sri: Point is you have no longer the LMA1 in path kent: r2LMA should have some states at some point. This is not described how to set up? What if LMA1 and LMA2 are different vendors? Jouni: Did not think about different vendors Rajeev: You solve two problems at the same time. Selection is fine. PBU below (MAG-LMA2) should create the BCE Jouni: So you propose to delete the LMA1->LMA2 signaling? Raj: Valid questions about different vendors Rajeev: Take it to the list Two things: LMA selection one issue. How to create BCE at the secon= d LMA2 is not an issue here. Jouni: Adopt as WG document? Raj: Clarify remaining questions first. Clarify on the ML, then we take the consensus discussion on the lis= t Kent: Ok with this work. Should be ok to ask now Result: Pros-> 10 in favour Cons-> opposed, take as baseline but do something else: 4 Raj: Formal consensus call on the ML LZ: we submitted a document to address a similar solution, so we can review= it SG: A second document 4 months after is a waste of time 5. Bulk Re-registration for Proxy Mobile IPv6 10 Mins I-D: draft-premec-netlmm-bulk-re-registration-02 Jouni Korhonen =20 AY: numbers should be 1:20000. Why to group (=85) JK:??? ML/SG: If all sessions are in the same MAG you want them together BS: is like CSG concept in 3GPP for femto JK: no BP: should be separate concepts wrt mobile node group identifier? BP: Should we consider adopting RK: Group identifier is an interesting concept. We should specify it when we have use cases like bulk =85 and then you define it.=20 JK: ??? RK: In deregistration LMA needs to know. You need something stating that if the MN has a group id then you should deregister=20 JK: this is a detail RK: An important one KL: Bulk registration is a specific case, whereas group id is more generic and useful thinking of the use cases=20 AY: Group id ok, Bulk not so much. Group id could be useful for these and other concepts=20 SG: ??? RW: I would like to see usage and justify this for single MAG SG: all group id can be used BP: We might specify in different documents =20 Raj: Adopt as WG baseline document?: 5 hands Raj: Specify group ID in a separate document may be ok. ++++++++++++++++++++++++++++++ 6. Mobile Node Group Identifier Option 10 Mins I-D: draft-gundavelli-netext-mn-groupid-option-01 Sri Gundavelli=09 Sri proposes a Mobile Node Group Identifier Option Alper: LMA assigns the group ID? Do you consider that the MAG assigns? Sri: Yes. Group ID could be on both ends Alper: How do they know about the use of the ID? Sri: Option has field Sub-Type, which defines the scope Ryuji: Do you assign ID to the MN which is anchored by same MAG or different MAG? Sri: LMA doing allocation. Could be different MAGs. Then ID is allcoated in LMA scope Ryuji: How can different MAGs use the same group ID? Rajeev: Cut the line Jouni: You said it's bad that LMA assigns the ID. LMA assigns in scope of one or multiple MAGs? Qin: Possible to assign though AAA?=20 Rajeev: Scope of group ID, who manages, lots of interesting questions, use cases, buld refresh, bulk revokation. Please continue discussion on the list. 7. Tunnel Negotiation for Proxy Mobile IPv6 5 Mins I-D: draft-xia-netext-tunnel-negotiation-01.txt Hidetoshi Yokota for Frank Xia =20 =20 JK: What does it change if this is not IPv4? HY: ??? SG: Already specified elsewhere Suresh: The tbit exists, but if you want other types is possible, and I want that=20 BP: Do we need that flexibility in PMIP? There needs to be SA between LMA and MAG, so the knowledge and support of the peer is assumed=20 HY: configuration will change Suresh: even with MPLS provisioning you might need such capability. RK: End of time. Move to mailing list Raj: Do we really need this flexibiity at the current time? Don't see the need now. MAG does not send PBU to random LMA. There is a security association, etc. so there is configuration knowledge=20 Hidetoshi: Operator may change the network Other agenda items not discussed because of a lack of time. +++++++++++++++++++ Next Steps: Raj: Next: 3 main documents to proceed. Reviews are appreciated. Please provide comments=20 From sunseawq@huawei.com Sun Sep 6 20:01:15 2009 Return-Path: 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 A05003A6832 for ; Sun, 6 Sep 2009 20:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.075 X-Spam-Level: X-Spam-Status: No, score=-0.075 tagged_above=-999 required=5 tests=[AWL=1.035, BAYES_05=-1.11] 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 cj-xYMZCMvtw for ; Sun, 6 Sep 2009 20:01:14 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 37E713A67B4 for ; Sun, 6 Sep 2009 20:01:14 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPK00LABZ2QN2@szxga02-in.huawei.com> for netext@ietf.org; Mon, 07 Sep 2009 11:01:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPK002TGZ2QNP@szxga02-in.huawei.com> for netext@ietf.org; Mon, 07 Sep 2009 11:01:38 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPK009FFZ2N17@szxml04-in.huawei.com> for netext@ietf.org; Mon, 07 Sep 2009 11:01:38 +0800 (CST) Date: Mon, 07 Sep 2009 11:01:34 +0800 From: Qin Wu To: Mohana Jeyatharan , Marco Liebsch Message-id: <01a801ca2f67$84709c70$260ca40a@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: <5F09D220B62F79418461A978CA0921BD03879B87@pslexc01.psl.local> Cc: netext@ietf.org Subject: Re: [netext] [Netext] localized route optimization - roaming issue 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 03:01:15 -0000 Hi,Mohana and Marco: I am wondering whether we need to write something to address roaming issue or what we talk about here is just to clarify how to understand local MAG routing applicability. As for me, I think it is beneficial to have some explaination text/section addressing this in the PS draft. Regards! -Qin ----- Original Message ----- From: "Mohana Jeyatharan" To: "Marco Liebsch" Cc: "Qin Wu" ; "Sri Gundavelli" ; "Cypher, David E." ; Sent: Friday, September 04, 2009 4:44 PM Subject: RE: [Netext] localized route optimization - roaming issue Hi Marco, Such disussion we had is more to understand the local MAG routing applicability. >Or should we provide additional info in the > PS? So, I think in PS we need not talk about SA between MAG. Or LMA or some other entity helping in creating the security association between MAGs. Thanks. BR, Mohana > -----Original Message----- > From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] > Sent: Friday, September 04, 2009 4:19 PM > To: Mohana Jeyatharan > Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.; > netext@mail.mobileip.jp > Subject: Re: [Netext] localized route optimization - roaming issue > > Hi Mohana, > > Mohana Jeyatharan schrieb: > > Hi Marco and all, > > > > > >> The PMIPv6 domain term does not fit in here, in my opinion, as we > >> do not talk about the scope of a single MN's mobility, but the > >> > > relation > > > >> between mobility management components of two MNs. > >> > > > > I agree on this. > > > > > >> solution: PMIPv6 components, which exchange signaling in the context > >> > > of > > > >> route optimization, must share a security association. Everything else > >> > > is > > > >> deployment specific. > >> > > > > Here we can probably explain which entities need security association > > for RO to be succussful. This is more towards solution space tied to > > different local MAG RO scenarios. I think the current localized RO > > solution drafts have captured these. > > > We can only provide examples. To establish a forwarding tunnel between > MAGs does not mean > we need an SA between them. Only if we perform signaling between MAGs, > the SA is required. > As you said, this is solution specific. So, to be on the safe side, we > could discuss the > picture and indicate that the solution may need an SA between the two > associated LMAs > and the two associated MAGs. Or should we provide additional info in the > PS? > > marco > > > BR, > > Mohana > > > >> -----Original Message----- > >> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] > >> Sent: Thursday, September 03, 2009 11:56 PM > >> To: Qin Wu > >> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco > >> > > Liebsch; > > > >> netext@mail.mobileip.jp > >> Subject: Re: [Netext] localized route optimization - roaming issue > >> > >> Now coming back to my original opinion that I don't see benefit in > >> mandating support for or ruling out any particular roaming scenarios. > >> The picture I proposed could be used in the Problem Statement (PS) > >> at the most to discuss *issues* when components being associated > >> with MN1 and MN2 are distributed between administrative domains. > >> The PMIPv6 domain term does not fit in here, in my opinion, as we > >> do not talk about the scope of a single MN's mobility, but the > >> > > relation > > > >> between mobility management components of two MNs. > >> > >> From that picture I see that only one requirement derives for the > >> protocol > >> solution: PMIPv6 components, which exchange signaling in the context > >> > > of > > > >> route optimization, must share a security association. Everything else > >> > > is > > > >> deployment specific. > >> > >> marco > >> > >> > >> > >> Qin Wu wrote: > >> > >>> Thank for your clarification. > >>> In this sense, no matter which domain the MN's MAG belongs to, as > >>> > > long > > > >> as the MN does not change LMA and MN's current MAG can setup SA with > >> > > MN's > > > >> LMA, MN is still in the same PMIP6 domain as its LMA. Right? > >> > >>> Regard! > >>> -Qin > >>> ----- Original Message ----- > >>> From: "Sri Gundavelli" > >>> To: "Qin Wu" > >>> Cc: > From Mohana.Jeyatharan@sg.panasonic.com Sun Sep 6 20:32:34 2009 Return-Path: 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 5104D3A6359 for ; Sun, 6 Sep 2009 20:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.91 X-Spam-Level: * X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_26=0.6] 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 M-V8qN7levsJ for ; Sun, 6 Sep 2009 20:32:33 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 245E43A6840 for ; Sun, 6 Sep 2009 20:32:33 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id n873WtL0021736; Mon, 7 Sep 2009 12:32:55 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id n873Wtu18872; Mon, 7 Sep 2009 12:32:55 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 Sep 2009 11:29:32 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03879D03@pslexc01.psl.local> In-Reply-To: <01a801ca2f67$84709c70$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [Netext] localized route optimization - roaming issue Thread-Index: AcovZxIWCWjGnaSUQgqwsy/rei1aCAAA06rQ From: "Mohana Jeyatharan" To: "Qin Wu" , "Marco Liebsch" Cc: netext@ietf.org Subject: Re: [netext] [Netext] localized route optimization - roaming issue 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 03:32:34 -0000 Hi Qin, Marco and all, > I am wondering whether we need to write something to address roaming issue > or what we talk about here is just to clarify how to understand local MAG > routing applicability. Yes, I agree. The PS needs to mention about some deployment scenarios wherevthe local MAG routing can be applied (ex bcos of SA available) and scenarios where cannot be applied (SA cannot be established so cannot perform).=20 *The scenarios Marco attached previously can be used.=20 *Perhaps some terminilogy such as PMIPv6 domain, administrative domain etc in the PS will be helpful. I mean PMIPv6 doamin is already well defined but re-emphasizing it w.r.t. to the work in local MAG routing will be useful. I guess these canbe captured without any details of solutions in the PS draft. Such capturing is useful to identify whether the solution drafts we have address all such cases of local MAG route optimization Again this is my opinion. Thanks. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Qin Wu > Sent: Monday, September 07, 2009 11:02 AM > To: Mohana Jeyatharan; Marco Liebsch > Cc: netext@ietf.org > Subject: Re: [netext] [Netext] localized route optimization - roaming > issue >=20 > Hi,Mohana and Marco: > I am wondering whether we need to write something to address roaming issue > or what we talk about here is just to clarify how to understand local MAG > routing applicability. > As for me, I think it is beneficial to have some explaination text/section > addressing this in the PS draft. >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Marco Liebsch" > Cc: "Qin Wu" ; "Sri Gundavelli" ; > "Cypher, David E." ; > Sent: Friday, September 04, 2009 4:44 PM > Subject: RE: [Netext] localized route optimization - roaming issue >=20 >=20 > Hi Marco, >=20 > Such disussion we had is more to understand the local MAG routing > applicability. >=20 > >Or should we provide additional info in the > > PS? > So, I think in PS we need not talk about SA between MAG. Or LMA or some > other entity helping in creating the security association between MAGs. >=20 > Thanks. >=20 > BR, > Mohana > > -----Original Message----- > > From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] > > Sent: Friday, September 04, 2009 4:19 PM > > To: Mohana Jeyatharan > > Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.; > > netext@mail.mobileip.jp > > Subject: Re: [Netext] localized route optimization - roaming issue > > > > Hi Mohana, > > > > Mohana Jeyatharan schrieb: > > > Hi Marco and all, > > > > > > > > >> The PMIPv6 domain term does not fit in here, in my opinion, as we > > >> do not talk about the scope of a single MN's mobility, but the > > >> > > > relation > > > > > >> between mobility management components of two MNs. > > >> > > > > > > I agree on this. > > > > > > > > >> solution: PMIPv6 components, which exchange signaling in the > context > > >> > > > of > > > > > >> route optimization, must share a security association. Everything > else > > >> > > > is > > > > > >> deployment specific. > > >> > > > > > > Here we can probably explain which entities need security > association > > > for RO to be succussful. This is more towards solution space tied to > > > different local MAG RO scenarios. I think the current localized RO > > > solution drafts have captured these. > > > > > We can only provide examples. To establish a forwarding tunnel between > > MAGs does not mean > > we need an SA between them. Only if we perform signaling between MAGs, > > the SA is required. > > As you said, this is solution specific. So, to be on the safe side, we > > could discuss the > > picture and indicate that the solution may need an SA between the two > > associated LMAs > > and the two associated MAGs. Or should we provide additional info in > the > > PS? > > > > marco > > > > > BR, > > > Mohana > > > > > >> -----Original Message----- > > >> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] > > >> Sent: Thursday, September 03, 2009 11:56 PM > > >> To: Qin Wu > > >> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco > > >> > > > Liebsch; > > > > > >> netext@mail.mobileip.jp > > >> Subject: Re: [Netext] localized route optimization - roaming issue > > >> > > >> Now coming back to my original opinion that I don't see benefit in > > >> mandating support for or ruling out any particular roaming > scenarios. > > >> The picture I proposed could be used in the Problem Statement (PS) > > >> at the most to discuss *issues* when components being associated > > >> with MN1 and MN2 are distributed between administrative domains. > > >> The PMIPv6 domain term does not fit in here, in my opinion, as we > > >> do not talk about the scope of a single MN's mobility, but the > > >> > > > relation > > > > > >> between mobility management components of two MNs. > > >> > > >> From that picture I see that only one requirement derives for the > > >> protocol > > >> solution: PMIPv6 components, which exchange signaling in the > context > > >> > > > of > > > > > >> route optimization, must share a security association. Everything > else > > >> > > > is > > > > > >> deployment specific. > > >> > > >> marco > > >> > > >> > > >> > > >> Qin Wu wrote: > > >> > > >>> Thank for your clarification. > > >>> In this sense, no matter which domain the MN's MAG belongs to, as > > >>> > > > long > > > > > >> as the MN does not change LMA and MN's current MAG can setup SA > with > > >> > > > MN's > > > > > >> LMA, MN is still in the same PMIP6 domain as its LMA. Right? > > >> > > >>> Regard! > > >>> -Qin > > >>> ----- Original Message ----- > > >>> From: "Sri Gundavelli" > > >>> To: "Qin Wu" > > >>> Cc: > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Tue Sep 8 05:31:21 2009 Return-Path: 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 8032B3A68B3 for ; Tue, 8 Sep 2009 05:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6] 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 YegAcLypHlHA for ; Tue, 8 Sep 2009 05:31:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 339753A6825 for ; Tue, 8 Sep 2009 05:31:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 00BD82C0004DB; Tue, 8 Sep 2009 14:31:50 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqbc0pK1ceQG; Tue, 8 Sep 2009 14:31:49 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id C57752C0004DE; Tue, 8 Sep 2009 14:31:34 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 14:31:34 +0200 Message-ID: <4AA64EA8.7030008@nw.neclab.eu> Date: Tue, 08 Sep 2009 14:31:36 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mohana Jeyatharan References: <5F09D220B62F79418461A978CA0921BD03879D03@pslexc01.psl.local> In-Reply-To: <5F09D220B62F79418461A978CA0921BD03879D03@pslexc01.psl.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2009 12:31:34.0648 (UTC) FILETIME=[4D6DF780:01CA3080] Cc: netext@ietf.org Subject: Re: [netext] [Netext] localized route optimization - roaming issue 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 12:31:21 -0000 Hi Mohana, Qin, ok, we can take a section "Roaming Aspects" into account for the PS and discuss applicability of localized routing. We can add this section to the initial WG draft of the PS. If folks consider this later as not useful, we can take it out again. Btw, I think this discussion can happen in parallel to protocol design, just to address some folks' concern with a PS to delay the protocol design. From the discussion we had so far, obviously it's common understanding that use cases with two LMAs should be supported, right? Thanks, marco Mohana Jeyatharan wrote: > Hi Qin, Marco and all, > > >> I am wondering whether we need to write something to address roaming >> > issue > >> or what we talk about here is just to clarify how to understand local >> > MAG > >> routing applicability. >> > > Yes, I agree. The PS needs to mention about some deployment scenarios > wherevthe local MAG routing can be applied (ex bcos of SA available) and > scenarios where cannot be applied (SA cannot be established so cannot > perform). > *The scenarios Marco attached previously can be used. > *Perhaps some terminilogy such as PMIPv6 domain, administrative domain > etc in the PS will be helpful. I mean PMIPv6 doamin is already well > defined but re-emphasizing it w.r.t. to the work in local MAG routing > will be useful. > > I guess these canbe captured without any details of solutions in the PS > draft. Such capturing is useful to identify whether the solution drafts > we have address all such cases of local MAG route optimization > Again this is my opinion. > > Thanks. > > BR, > Mohana > > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >> > Behalf > >> Of Qin Wu >> Sent: Monday, September 07, 2009 11:02 AM >> To: Mohana Jeyatharan; Marco Liebsch >> Cc: netext@ietf.org >> Subject: Re: [netext] [Netext] localized route optimization - roaming >> issue >> >> Hi,Mohana and Marco: >> I am wondering whether we need to write something to address roaming >> > issue > >> or what we talk about here is just to clarify how to understand local >> > MAG > >> routing applicability. >> As for me, I think it is beneficial to have some explaination >> > text/section > >> addressing this in the PS draft. >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Mohana Jeyatharan" >> To: "Marco Liebsch" >> Cc: "Qin Wu" ; "Sri Gundavelli" >> > ; > >> "Cypher, David E." ; >> Sent: Friday, September 04, 2009 4:44 PM >> Subject: RE: [Netext] localized route optimization - roaming issue >> >> >> Hi Marco, >> >> Such disussion we had is more to understand the local MAG routing >> applicability. >> >> >>> Or should we provide additional info in the >>> PS? >>> >> So, I think in PS we need not talk about SA between MAG. Or LMA or >> > some > >> other entity helping in creating the security association between >> > MAGs. > >> Thanks. >> >> BR, >> Mohana >> >>> -----Original Message----- >>> From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] >>> Sent: Friday, September 04, 2009 4:19 PM >>> To: Mohana Jeyatharan >>> Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.; >>> netext@mail.mobileip.jp >>> Subject: Re: [Netext] localized route optimization - roaming issue >>> >>> Hi Mohana, >>> >>> Mohana Jeyatharan schrieb: >>> >>>> Hi Marco and all, >>>> >>>> >>>> >>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>> do not talk about the scope of a single MN's mobility, but the >>>>> >>>>> >>>> relation >>>> >>>> >>>>> between mobility management components of two MNs. >>>>> >>>>> >>>> I agree on this. >>>> >>>> >>>> >>>>> solution: PMIPv6 components, which exchange signaling in the >>>>> >> context >> >>>> of >>>> >>>> >>>>> route optimization, must share a security association. Everything >>>>> >> else >> >>>> is >>>> >>>> >>>>> deployment specific. >>>>> >>>>> >>>> Here we can probably explain which entities need security >>>> >> association >> >>>> for RO to be succussful. This is more towards solution space tied >>>> > to > >>>> different local MAG RO scenarios. I think the current localized RO >>>> solution drafts have captured these. >>>> >>>> >>> We can only provide examples. To establish a forwarding tunnel >>> > between > >>> MAGs does not mean >>> we need an SA between them. Only if we perform signaling between >>> > MAGs, > >>> the SA is required. >>> As you said, this is solution specific. So, to be on the safe side, >>> > we > >>> could discuss the >>> picture and indicate that the solution may need an SA between the >>> > two > >>> associated LMAs >>> and the two associated MAGs. Or should we provide additional info in >>> >> the >> >>> PS? >>> >>> marco >>> >>> >>>> BR, >>>> Mohana >>>> >>>> >>>>> -----Original Message----- >>>>> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] >>>>> Sent: Thursday, September 03, 2009 11:56 PM >>>>> To: Qin Wu >>>>> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco >>>>> >>>>> >>>> Liebsch; >>>> >>>> >>>>> netext@mail.mobileip.jp >>>>> Subject: Re: [Netext] localized route optimization - roaming >>>>> > issue > >>>>> Now coming back to my original opinion that I don't see benefit >>>>> > in > >>>>> mandating support for or ruling out any particular roaming >>>>> >> scenarios. >> >>>>> The picture I proposed could be used in the Problem Statement >>>>> > (PS) > >>>>> at the most to discuss *issues* when components being associated >>>>> with MN1 and MN2 are distributed between administrative domains. >>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>> do not talk about the scope of a single MN's mobility, but the >>>>> >>>>> >>>> relation >>>> >>>> >>>>> between mobility management components of two MNs. >>>>> >>>>> From that picture I see that only one requirement derives for >>>>> > the > >>>>> protocol >>>>> solution: PMIPv6 components, which exchange signaling in the >>>>> >> context >> >>>> of >>>> >>>> >>>>> route optimization, must share a security association. Everything >>>>> >> else >> >>>> is >>>> >>>> >>>>> deployment specific. >>>>> >>>>> marco >>>>> >>>>> >>>>> >>>>> Qin Wu wrote: >>>>> >>>>> >>>>>> Thank for your clarification. >>>>>> In this sense, no matter which domain the MN's MAG belongs to, >>>>>> > as > >>>> long >>>> >>>> >>>>> as the MN does not change LMA and MN's current MAG can setup SA >>>>> >> with >> >>>> MN's >>>> >>>> >>>>> LMA, MN is still in the same PMIP6 domain as its LMA. Right? >>>>> >>>>> >>>>>> Regard! >>>>>> -Qin >>>>>> ----- Original Message ----- >>>>>> From: "Sri Gundavelli" >>>>>> To: "Qin Wu" >>>>>> Cc: >>>>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> From Basavaraj.Patil@nokia.com Tue Sep 8 08:22:59 2009 Return-Path: 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 D188C3A69CA for ; Tue, 8 Sep 2009 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, 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 o3rODIHLv9Ev for ; Tue, 8 Sep 2009 08:22:58 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 026A33A68EB for ; Tue, 8 Sep 2009 08:22:57 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n88FN7SM027516; Tue, 8 Sep 2009 18:23:11 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 18:23:11 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 18:23:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Sep 2009 18:23:02 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 8 Sep 2009 17:22:58 +0200 From: To: , Date: Tue, 8 Sep 2009 17:23:07 +0200 Thread-Topic: [netext] [Netext] localized route optimization - roaming issue Thread-Index: AcowgGU3Mf3XalXjSRi2wjmsELMvewAF97tz Message-ID: In-Reply-To: <4AA64EA8.7030008@nw.neclab.eu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2009 15:23:02.0873 (UTC) FILETIME=[41B08490:01CA3098] Cc: netext@ietf.org Subject: Re: [netext] [Netext] localized route optimization - roaming issue 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 15:22:59 -0000 Hi Marco, One of the issues that we got hung up at IETF75 during the LR discussion wa= s on roaming. It would be good to have a clear description of the relationshi= p between the MAG and LMA in the context of a PMIP6 domain especially when yo= u consider home and visited network scenarios wherein the MAG/LMA entities ar= e in different domains. The PMIP6 domain definition in RFC5213: " Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be set up and authorization for sending Proxy Binding Updates on behalf of the mobile nodes can be ensured. " does not have any references to home/visited network concepts. The only criteria for an entity (MAG/LMA) being considered being a part of the PMIP6 domain is the existence of a security association. It would be good to elaborate how this maps to the current discussion in LR. -Raj On 9/8/09 7:31 AM, "ext Marco Liebsch" wrote: > Hi Mohana, Qin, >=20 > ok, we can take a section "Roaming Aspects" into account for the PS and > discuss > applicability of localized routing. We can add this section to the > initial WG draft > of the PS. If folks consider this later as not useful, we can take it > out again. >=20 > Btw, I think this discussion can happen in parallel to protocol design, > just to address > some folks' concern with a PS to delay the protocol design. >=20 > From the discussion we had so far, obviously it's common understanding t= hat > use cases with two LMAs should be supported, right? >=20 > Thanks, > marco >=20 >=20 > Mohana Jeyatharan wrote: >> Hi Qin, Marco and all, >>=20 >> =20 >>> I am wondering whether we need to write something to address roaming >>> =20 >> issue >> =20 >>> or what we talk about here is just to clarify how to understand local >>> =20 >> MAG >> =20 >>> routing applicability. >>> =20 >>=20 >> Yes, I agree. The PS needs to mention about some deployment scenarios >> wherevthe local MAG routing can be applied (ex bcos of SA available) and >> scenarios where cannot be applied (SA cannot be established so cannot >> perform). >> *The scenarios Marco attached previously can be used. >> *Perhaps some terminilogy such as PMIPv6 domain, administrative domain >> etc in the PS will be helpful. I mean PMIPv6 doamin is already well >> defined but re-emphasizing it w.r.t. to the work in local MAG routing >> will be useful. >>=20 >> I guess these canbe captured without any details of solutions in the PS >> draft. Such capturing is useful to identify whether the solution drafts >> we have address all such cases of local MAG route optimization >> Again this is my opinion. >>=20 >> Thanks. >>=20 >> BR, >> Mohana >>=20 >>=20 >> =20 >>> -----Original Message----- >>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>> =20 >> Behalf >> =20 >>> Of Qin Wu >>> Sent: Monday, September 07, 2009 11:02 AM >>> To: Mohana Jeyatharan; Marco Liebsch >>> Cc: netext@ietf.org >>> Subject: Re: [netext] [Netext] localized route optimization - roaming >>> issue >>>=20 >>> Hi,Mohana and Marco: >>> I am wondering whether we need to write something to address roaming >>> =20 >> issue >> =20 >>> or what we talk about here is just to clarify how to understand local >>> =20 >> MAG >> =20 >>> routing applicability. >>> As for me, I think it is beneficial to have some explaination >>> =20 >> text/section >> =20 >>> addressing this in the PS draft. >>>=20 >>> Regards! >>> -Qin >>> ----- Original Message ----- >>> From: "Mohana Jeyatharan" >>> To: "Marco Liebsch" >>> Cc: "Qin Wu" ; "Sri Gundavelli" >>> =20 >> ; >> =20 >>> "Cypher, David E." ; >>> Sent: Friday, September 04, 2009 4:44 PM >>> Subject: RE: [Netext] localized route optimization - roaming issue >>>=20 >>>=20 >>> Hi Marco, >>>=20 >>> Such disussion we had is more to understand the local MAG routing >>> applicability. >>>=20 >>> =20 >>>> Or should we provide additional info in the >>>> PS? >>>> =20 >>> So, I think in PS we need not talk about SA between MAG. Or LMA or >>> =20 >> some >> =20 >>> other entity helping in creating the security association between >>> =20 >> MAGs. >> =20 >>> Thanks. >>>=20 >>> BR, >>> Mohana >>> =20 >>>> -----Original Message----- >>>> From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] >>>> Sent: Friday, September 04, 2009 4:19 PM >>>> To: Mohana Jeyatharan >>>> Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.; >>>> netext@mail.mobileip.jp >>>> Subject: Re: [Netext] localized route optimization - roaming issue >>>>=20 >>>> Hi Mohana, >>>>=20 >>>> Mohana Jeyatharan schrieb: >>>> =20 >>>>> Hi Marco and all, >>>>>=20 >>>>>=20 >>>>> =20 >>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>>=20 >>>>>> =20 >>>>> relation >>>>>=20 >>>>> =20 >>>>>> between mobility management components of two MNs. >>>>>>=20 >>>>>> =20 >>>>> I agree on this. >>>>>=20 >>>>>=20 >>>>> =20 >>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>> =20 >>> context >>> =20 >>>>> of >>>>>=20 >>>>> =20 >>>>>> route optimization, must share a security association. Everything >>>>>> =20 >>> else >>> =20 >>>>> is >>>>>=20 >>>>> =20 >>>>>> deployment specific. >>>>>>=20 >>>>>> =20 >>>>> Here we can probably explain which entities need security >>>>> =20 >>> association >>> =20 >>>>> for RO to be succussful. This is more towards solution space tied >>>>> =20 >> to >> =20 >>>>> different local MAG RO scenarios. I think the current localized RO >>>>> solution drafts have captured these. >>>>>=20 >>>>> =20 >>>> We can only provide examples. To establish a forwarding tunnel >>>> =20 >> between >> =20 >>>> MAGs does not mean >>>> we need an SA between them. Only if we perform signaling between >>>> =20 >> MAGs, >> =20 >>>> the SA is required. >>>> As you said, this is solution specific. So, to be on the safe side, >>>> =20 >> we >> =20 >>>> could discuss the >>>> picture and indicate that the solution may need an SA between the >>>> =20 >> two >> =20 >>>> associated LMAs >>>> and the two associated MAGs. Or should we provide additional info in >>>> =20 >>> the >>> =20 >>>> PS? >>>>=20 >>>> marco >>>>=20 >>>> =20 >>>>> BR, >>>>> Mohana >>>>>=20 >>>>> =20 >>>>>> -----Original Message----- >>>>>> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] >>>>>> Sent: Thursday, September 03, 2009 11:56 PM >>>>>> To: Qin Wu >>>>>> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco >>>>>>=20 >>>>>> =20 >>>>> Liebsch; >>>>>=20 >>>>> =20 >>>>>> netext@mail.mobileip.jp >>>>>> Subject: Re: [Netext] localized route optimization - roaming >>>>>> =20 >> issue >> =20 >>>>>> Now coming back to my original opinion that I don't see benefit >>>>>> =20 >> in >> =20 >>>>>> mandating support for or ruling out any particular roaming >>>>>> =20 >>> scenarios. >>> =20 >>>>>> The picture I proposed could be used in the Problem Statement >>>>>> =20 >> (PS) >> =20 >>>>>> at the most to discuss *issues* when components being associated >>>>>> with MN1 and MN2 are distributed between administrative domains. >>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>>=20 >>>>>> =20 >>>>> relation >>>>>=20 >>>>> =20 >>>>>> between mobility management components of two MNs. >>>>>>=20 >>>>>> From that picture I see that only one requirement derives for >>>>>> =20 >> the >> =20 >>>>>> protocol >>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>> =20 >>> context >>> =20 >>>>> of >>>>>=20 >>>>> =20 >>>>>> route optimization, must share a security association. Everything >>>>>> =20 >>> else >>> =20 >>>>> is >>>>>=20 >>>>> =20 >>>>>> deployment specific. >>>>>>=20 >>>>>> marco >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Qin Wu wrote: >>>>>>=20 >>>>>> =20 >>>>>>> Thank for your clarification. >>>>>>> In this sense, no matter which domain the MN's MAG belongs to, >>>>>>> =20 >> as >> =20 >>>>> long >>>>>=20 >>>>> =20 >>>>>> as the MN does not change LMA and MN's current MAG can setup SA >>>>>> =20 >>> with >>> =20 >>>>> MN's >>>>>=20 >>>>> =20 >>>>>> LMA, MN is still in the same PMIP6 domain as its LMA. Right? >>>>>>=20 >>>>>> =20 >>>>>>> Regard! >>>>>>> -Qin >>>>>>> ----- Original Message ----- >>>>>>> From: "Sri Gundavelli" >>>>>>> To: "Qin Wu" >>>>>>> Cc: >>>>>>> =20 >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> =20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Wed Sep 9 01:46:08 2009 Return-Path: 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 AEF593A67B2 for ; Wed, 9 Sep 2009 01:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.38 X-Spam-Level: X-Spam-Status: No, score=0.38 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_26=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 cZRbVM2GvVcd for ; Wed, 9 Sep 2009 01:46:07 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 4006E3A689A for ; Wed, 9 Sep 2009 01:46:07 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPP00E624DDMH@szxga02-in.huawei.com> for netext@ietf.org; Wed, 09 Sep 2009 16:46:25 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPP00KR44DDNB@szxga02-in.huawei.com> for netext@ietf.org; Wed, 09 Sep 2009 16:46:25 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPP00ID64DCSO@szxml06-in.huawei.com> for netext@ietf.org; Wed, 09 Sep 2009 16:46:25 +0800 (CST) Date: Wed, 09 Sep 2009 16:46:23 +0800 From: Qin Wu To: Marco Liebsch , Mohana Jeyatharan Message-id: <06bc01ca312a$0369e720$260ca40a@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: <5F09D220B62F79418461A978CA0921BD03879D03@pslexc01.psl.local> <4AA64EA8.7030008@nw.neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] [Netext] localized route optimization - roaming issue 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 08:46:08 -0000 Hi, Marco: I think roaming case is very usful. It help us to better understanding on how local routing works when MN roams over PMIPv6 domain. So I support to add a new section to talk about roaming section. In this sense, we can loose requirements on PMIPv6 components distribution. i.e., MN's LMA and CN's LMA need not stay with MN and CN within the same PMIPv6 domain, But it is required that MN and CN should connect to corresponding MAGs within the same PMIPv6 domain, am I right? Based these loose requirements or assumption, I think use case with two LMAs can be supported. As regarding protocol desgin, I think there is no reason to delay this work if folks have arrived at common understanding. Regards! -Qin ----- Original Message ----- From: "Marco Liebsch" To: "Mohana Jeyatharan" Cc: "Qin Wu" ; "Marco Liebsch" ; Sent: Tuesday, September 08, 2009 8:31 PM Subject: Re: [netext] [Netext] localized route optimization - roaming issue > Hi Mohana, Qin, > > ok, we can take a section "Roaming Aspects" into account for the PS and > discuss > applicability of localized routing. We can add this section to the > initial WG draft > of the PS. If folks consider this later as not useful, we can take it > out again. > > Btw, I think this discussion can happen in parallel to protocol design, > just to address > some folks' concern with a PS to delay the protocol design. > > From the discussion we had so far, obviously it's common understanding that > use cases with two LMAs should be supported, right? > > Thanks, > marco > > > Mohana Jeyatharan wrote: >> Hi Qin, Marco and all, >> >> >>> I am wondering whether we need to write something to address roaming >>> >> issue >> >>> or what we talk about here is just to clarify how to understand local >>> >> MAG >> >>> routing applicability. >>> >> >> Yes, I agree. The PS needs to mention about some deployment scenarios >> wherevthe local MAG routing can be applied (ex bcos of SA available) and >> scenarios where cannot be applied (SA cannot be established so cannot >> perform). >> *The scenarios Marco attached previously can be used. >> *Perhaps some terminilogy such as PMIPv6 domain, administrative domain >> etc in the PS will be helpful. I mean PMIPv6 doamin is already well >> defined but re-emphasizing it w.r.t. to the work in local MAG routing >> will be useful. >> >> I guess these canbe captured without any details of solutions in the PS >> draft. Such capturing is useful to identify whether the solution drafts >> we have address all such cases of local MAG route optimization >> Again this is my opinion. >> >> Thanks. >> >> BR, >> Mohana >> >> >> >>> -----Original Message----- >>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>> >> Behalf >> >>> Of Qin Wu >>> Sent: Monday, September 07, 2009 11:02 AM >>> To: Mohana Jeyatharan; Marco Liebsch >>> Cc: netext@ietf.org >>> Subject: Re: [netext] [Netext] localized route optimization - roaming >>> issue >>> >>> Hi,Mohana and Marco: >>> I am wondering whether we need to write something to address roaming >>> >> issue >> >>> or what we talk about here is just to clarify how to understand local >>> >> MAG >> >>> routing applicability. >>> As for me, I think it is beneficial to have some explaination >>> >> text/section >> >>> addressing this in the PS draft. >>> >>> Regards! >>> -Qin >>> ----- Original Message ----- >>> From: "Mohana Jeyatharan" >>> To: "Marco Liebsch" >>> Cc: "Qin Wu" ; "Sri Gundavelli" >>> >> ; >> >>> "Cypher, David E." ; >>> Sent: Friday, September 04, 2009 4:44 PM >>> Subject: RE: [Netext] localized route optimization - roaming issue >>> >>> >>> Hi Marco, >>> >>> Such disussion we had is more to understand the local MAG routing >>> applicability. >>> >>> >>>> Or should we provide additional info in the >>>> PS? >>>> >>> So, I think in PS we need not talk about SA between MAG. Or LMA or >>> >> some >> >>> other entity helping in creating the security association between >>> >> MAGs. >> >>> Thanks. >>> >>> BR, >>> Mohana >>> >>>> -----Original Message----- >>>> From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] >>>> Sent: Friday, September 04, 2009 4:19 PM >>>> To: Mohana Jeyatharan >>>> Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.; >>>> netext@mail.mobileip.jp >>>> Subject: Re: [Netext] localized route optimization - roaming issue >>>> >>>> Hi Mohana, >>>> >>>> Mohana Jeyatharan schrieb: >>>> >>>>> Hi Marco and all, >>>>> >>>>> >>>>> >>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>> >>>>>> >>>>> relation >>>>> >>>>> >>>>>> between mobility management components of two MNs. >>>>>> >>>>>> >>>>> I agree on this. >>>>> >>>>> >>>>> >>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>> >>> context >>> >>>>> of >>>>> >>>>> >>>>>> route optimization, must share a security association. Everything >>>>>> >>> else >>> >>>>> is >>>>> >>>>> >>>>>> deployment specific. >>>>>> >>>>>> >>>>> Here we can probably explain which entities need security >>>>> >>> association >>> >>>>> for RO to be succussful. This is more towards solution space tied >>>>> >> to >> >>>>> different local MAG RO scenarios. I think the current localized RO >>>>> solution drafts have captured these. >>>>> >>>>> >>>> We can only provide examples. To establish a forwarding tunnel >>>> >> between >> >>>> MAGs does not mean >>>> we need an SA between them. Only if we perform signaling between >>>> >> MAGs, >> >>>> the SA is required. >>>> As you said, this is solution specific. So, to be on the safe side, >>>> >> we >> >>>> could discuss the >>>> picture and indicate that the solution may need an SA between the >>>> >> two >> >>>> associated LMAs >>>> and the two associated MAGs. Or should we provide additional info in >>>> >>> the >>> >>>> PS? >>>> >>>> marco >>>> >>>> >>>>> BR, >>>>> Mohana >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] >>>>>> Sent: Thursday, September 03, 2009 11:56 PM >>>>>> To: Qin Wu >>>>>> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco >>>>>> >>>>>> >>>>> Liebsch; >>>>> >>>>> >>>>>> netext@mail.mobileip.jp >>>>>> Subject: Re: [Netext] localized route optimization - roaming >>>>>> >> issue >> >>>>>> Now coming back to my original opinion that I don't see benefit >>>>>> >> in >> >>>>>> mandating support for or ruling out any particular roaming >>>>>> >>> scenarios. >>> >>>>>> The picture I proposed could be used in the Problem Statement >>>>>> >> (PS) >> >>>>>> at the most to discuss *issues* when components being associated >>>>>> with MN1 and MN2 are distributed between administrative domains. >>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>> >>>>>> >>>>> relation >>>>> >>>>> >>>>>> between mobility management components of two MNs. >>>>>> >>>>>> From that picture I see that only one requirement derives for >>>>>> >> the >> >>>>>> protocol >>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>> >>> context >>> >>>>> of >>>>> >>>>> >>>>>> route optimization, must share a security association. Everything >>>>>> >>> else >>> >>>>> is >>>>> >>>>> >>>>>> deployment specific. >>>>>> >>>>>> marco >>>>>> >>>>>> >>>>>> >>>>>> Qin Wu wrote: >>>>>> >>>>>> >>>>>>> Thank for your clarification. >>>>>>> In this sense, no matter which domain the MN's MAG belongs to, >>>>>>> >> as >> >>>>> long >>>>> >>>>> >>>>>> as the MN does not change LMA and MN's current MAG can setup SA >>>>>> >>> with >>> >>>>> MN's >>>>> >>>>> >>>>>> LMA, MN is still in the same PMIP6 domain as its LMA. Right? >>>>>> >>>>>> >>>>>>> Regard! >>>>>>> -Qin >>>>>>> ----- Original Message ----- >>>>>>> From: "Sri Gundavelli" >>>>>>> To: "Qin Wu" >>>>>>> Cc: >>>>>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> > From Basavaraj.Patil@nokia.com Wed Sep 9 07:55:34 2009 Return-Path: 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 DA3783A67D8 for ; Wed, 9 Sep 2009 07:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 xB1V3RBgNe+K for ; Wed, 9 Sep 2009 07:55:33 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id EC6AD3A680C for ; Wed, 9 Sep 2009 07:55:29 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n89EtXFo028477 for ; Wed, 9 Sep 2009 17:55:46 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 17:55:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 17:55:46 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 9 Sep 2009 16:55:45 +0200 From: To: Date: Wed, 9 Sep 2009 16:55:58 +0200 Thread-Topic: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Thread-Index: AcoxW3x0itr054ovT3Oh2zchhv74PgAALA6gAABdu5A= Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1FD67837@zrc2hxm0.corp.nortel.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2009 14:55:46.0153 (UTC) FILETIME=[9C8A9D90:01CA315D] Subject: [netext] FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 14:55:34 -0000 You probably will see this email several times. Please do nominate people who you think would be well suited to serve on the IESG. -Raj ------ Forwarded Message From: ext Mary Barnes Date: Wed, 9 Sep 2009 16:46:38 +0200 To: Working Group Chairs Subject: FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Loca= l Office hours, Nominee Questionnaires available Hi all, Thanks to the ADs and chairs that forwarded the previous reminder to their mailing lists. I would appreciate it if other chairs and ADs could do so, since we are really in need of more nominations. Thanks, Mary. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Wednesday, September 09, 2009 9:38 AM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Hi all, This is a 2nd reminder of the Call for Nominations that is underway. We *really* need more nominations in order to properly execute the task of selecting candidates for the open positions. At this time, the number of nominations for all the positions is about 1/2 of what is necessary for the Nomcom to do a conscientious job of evaluating the nominees and we are over 2/3 of the way through the nominations period. Nomcom cannot do their job without this important input from the community. So, please consider making nominations for the open positions - it takes just a few minutes of your time - the details are below. Right now, we just need the names/email addresses for the nominees - we'll be soliciting feedback later. Also, consider that over 1/2 the nominees are not able to accept the nominations for a variety of reasons - e.g., lack of funding, lack of sponsor support, etc. Thus, please consider nominating more than one individual for each of the positions. As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours 3) Questionnaires available for nominees Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D 1) Call for Nominations ------------------------ The nomination period ends in less than 2 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA:=20 Stephen Kent - kent@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.barnes@gmail.com Lucy Yong - lucyyong@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.brim@gmail.com Montevideo, Uruguay: Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+ietf@qualcomm.com Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) =20 Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------ End of Forwarded Message From Marco.Liebsch@nw.neclab.eu Wed Sep 9 08:07:47 2009 Return-Path: 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 EA07128C256 for ; Wed, 9 Sep 2009 08:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_26=0.6] 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 b-wDF1bcdlyl for ; Wed, 9 Sep 2009 08:07:46 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id EDF3628C260 for ; Wed, 9 Sep 2009 08:07:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 659802C0004DB; Wed, 9 Sep 2009 17:08:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrxG4laWCUS1; Wed, 9 Sep 2009 17:08:18 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 36F5B2C0001AA; Wed, 9 Sep 2009 17:08:03 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 17:08:03 +0200 Message-ID: <4AA7C4CE.1030305@nw.neclab.eu> Date: Wed, 09 Sep 2009 17:07:58 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2009 15:08:03.0132 (UTC) FILETIME=[53D0AFC0:01CA315F] Cc: netext@ietf.org, Mohana.Jeyatharan@sg.panasonic.com Subject: Re: [netext] [Netext] localized route optimization - roaming issue 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:07:48 -0000 Hi Raj, yes, agreed, that's why it has been proposed to add a section on this in the PS. The picture could be based on what I sent some mails ago. We're currently preparing some text, but I think it makes sense to discuss and agree on the text before it goes to the PS draft. marco Basavaraj.Patil@nokia.com wrote: > Hi Marco, > > One of the issues that we got hung up at IETF75 during the LR discussion was > on roaming. It would be good to have a clear description of the relationship > between the MAG and LMA in the context of a PMIP6 domain especially when you > consider home and visited network scenarios wherein the MAG/LMA entities are > in different domains. > > The PMIP6 domain definition in RFC5213: > " > Proxy Mobile IPv6 domain refers to the network where the mobility > management of a mobile node is handled using the Proxy Mobile IPv6 > protocol as defined in this specification. The Proxy Mobile IPv6 > domain includes local mobility anchors and mobile access gateways > between which security associations can be set up and > authorization for sending Proxy Binding Updates on behalf of the > mobile nodes can be ensured. > " > > does not have any references to home/visited network concepts. The only > criteria for an entity (MAG/LMA) being considered being a part of the PMIP6 > domain is the existence of a security association. It would be good to > elaborate how this maps to the current discussion in LR. > > -Raj > > > On 9/8/09 7:31 AM, "ext Marco Liebsch" wrote: > > >> Hi Mohana, Qin, >> >> ok, we can take a section "Roaming Aspects" into account for the PS and >> discuss >> applicability of localized routing. We can add this section to the >> initial WG draft >> of the PS. If folks consider this later as not useful, we can take it >> out again. >> >> Btw, I think this discussion can happen in parallel to protocol design, >> just to address >> some folks' concern with a PS to delay the protocol design. >> >> From the discussion we had so far, obviously it's common understanding that >> use cases with two LMAs should be supported, right? >> >> Thanks, >> marco >> >> >> Mohana Jeyatharan wrote: >> >>> Hi Qin, Marco and all, >>> >>> >>> >>>> I am wondering whether we need to write something to address roaming >>>> >>>> >>> issue >>> >>> >>>> or what we talk about here is just to clarify how to understand local >>>> >>>> >>> MAG >>> >>> >>>> routing applicability. >>>> >>>> >>> Yes, I agree. The PS needs to mention about some deployment scenarios >>> wherevthe local MAG routing can be applied (ex bcos of SA available) and >>> scenarios where cannot be applied (SA cannot be established so cannot >>> perform). >>> *The scenarios Marco attached previously can be used. >>> *Perhaps some terminilogy such as PMIPv6 domain, administrative domain >>> etc in the PS will be helpful. I mean PMIPv6 doamin is already well >>> defined but re-emphasizing it w.r.t. to the work in local MAG routing >>> will be useful. >>> >>> I guess these canbe captured without any details of solutions in the PS >>> draft. Such capturing is useful to identify whether the solution drafts >>> we have address all such cases of local MAG route optimization >>> Again this is my opinion. >>> >>> Thanks. >>> >>> BR, >>> Mohana >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>> >>>> >>> Behalf >>> >>> >>>> Of Qin Wu >>>> Sent: Monday, September 07, 2009 11:02 AM >>>> To: Mohana Jeyatharan; Marco Liebsch >>>> Cc: netext@ietf.org >>>> Subject: Re: [netext] [Netext] localized route optimization - roaming >>>> issue >>>> >>>> Hi,Mohana and Marco: >>>> I am wondering whether we need to write something to address roaming >>>> >>>> >>> issue >>> >>> >>>> or what we talk about here is just to clarify how to understand local >>>> >>>> >>> MAG >>> >>> >>>> routing applicability. >>>> As for me, I think it is beneficial to have some explaination >>>> >>>> >>> text/section >>> >>> >>>> addressing this in the PS draft. >>>> >>>> Regards! >>>> -Qin >>>> ----- Original Message ----- >>>> From: "Mohana Jeyatharan" >>>> To: "Marco Liebsch" >>>> Cc: "Qin Wu" ; "Sri Gundavelli" >>>> >>>> >>> ; >>> >>> >>>> "Cypher, David E." ; >>>> Sent: Friday, September 04, 2009 4:44 PM >>>> Subject: RE: [Netext] localized route optimization - roaming issue >>>> >>>> >>>> Hi Marco, >>>> >>>> Such disussion we had is more to understand the local MAG routing >>>> applicability. >>>> >>>> >>>> >>>>> Or should we provide additional info in the >>>>> PS? >>>>> >>>>> >>>> So, I think in PS we need not talk about SA between MAG. Or LMA or >>>> >>>> >>> some >>> >>> >>>> other entity helping in creating the security association between >>>> >>>> >>> MAGs. >>> >>> >>>> Thanks. >>>> >>>> BR, >>>> Mohana >>>> >>>> >>>>> -----Original Message----- >>>>> From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] >>>>> Sent: Friday, September 04, 2009 4:19 PM >>>>> To: Mohana Jeyatharan >>>>> Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.; >>>>> netext@mail.mobileip.jp >>>>> Subject: Re: [Netext] localized route optimization - roaming issue >>>>> >>>>> Hi Mohana, >>>>> >>>>> Mohana Jeyatharan schrieb: >>>>> >>>>> >>>>>> Hi Marco and all, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>>> >>>>>>> >>>>>>> >>>>>> relation >>>>>> >>>>>> >>>>>> >>>>>>> between mobility management components of two MNs. >>>>>>> >>>>>>> >>>>>>> >>>>>> I agree on this. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>>> >>>>>>> >>>> context >>>> >>>> >>>>>> of >>>>>> >>>>>> >>>>>> >>>>>>> route optimization, must share a security association. Everything >>>>>>> >>>>>>> >>>> else >>>> >>>> >>>>>> is >>>>>> >>>>>> >>>>>> >>>>>>> deployment specific. >>>>>>> >>>>>>> >>>>>>> >>>>>> Here we can probably explain which entities need security >>>>>> >>>>>> >>>> association >>>> >>>> >>>>>> for RO to be succussful. This is more towards solution space tied >>>>>> >>>>>> >>> to >>> >>> >>>>>> different local MAG RO scenarios. I think the current localized RO >>>>>> solution drafts have captured these. >>>>>> >>>>>> >>>>>> >>>>> We can only provide examples. To establish a forwarding tunnel >>>>> >>>>> >>> between >>> >>> >>>>> MAGs does not mean >>>>> we need an SA between them. Only if we perform signaling between >>>>> >>>>> >>> MAGs, >>> >>> >>>>> the SA is required. >>>>> As you said, this is solution specific. So, to be on the safe side, >>>>> >>>>> >>> we >>> >>> >>>>> could discuss the >>>>> picture and indicate that the solution may need an SA between the >>>>> >>>>> >>> two >>> >>> >>>>> associated LMAs >>>>> and the two associated MAGs. Or should we provide additional info in >>>>> >>>>> >>>> the >>>> >>>> >>>>> PS? >>>>> >>>>> marco >>>>> >>>>> >>>>> >>>>>> BR, >>>>>> Mohana >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] >>>>>>> Sent: Thursday, September 03, 2009 11:56 PM >>>>>>> To: Qin Wu >>>>>>> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco >>>>>>> >>>>>>> >>>>>>> >>>>>> Liebsch; >>>>>> >>>>>> >>>>>> >>>>>>> netext@mail.mobileip.jp >>>>>>> Subject: Re: [Netext] localized route optimization - roaming >>>>>>> >>>>>>> >>> issue >>> >>> >>>>>>> Now coming back to my original opinion that I don't see benefit >>>>>>> >>>>>>> >>> in >>> >>> >>>>>>> mandating support for or ruling out any particular roaming >>>>>>> >>>>>>> >>>> scenarios. >>>> >>>> >>>>>>> The picture I proposed could be used in the Problem Statement >>>>>>> >>>>>>> >>> (PS) >>> >>> >>>>>>> at the most to discuss *issues* when components being associated >>>>>>> with MN1 and MN2 are distributed between administrative domains. >>>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>>> >>>>>>> >>>>>>> >>>>>> relation >>>>>> >>>>>> >>>>>> >>>>>>> between mobility management components of two MNs. >>>>>>> >>>>>>> From that picture I see that only one requirement derives for >>>>>>> >>>>>>> >>> the >>> >>> >>>>>>> protocol >>>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>>> >>>>>>> >>>> context >>>> >>>> >>>>>> of >>>>>> >>>>>> >>>>>> >>>>>>> route optimization, must share a security association. Everything >>>>>>> >>>>>>> >>>> else >>>> >>>> >>>>>> is >>>>>> >>>>>> >>>>>> >>>>>>> deployment specific. >>>>>>> >>>>>>> marco >>>>>>> >>>>>>> >>>>>>> >>>>>>> Qin Wu wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thank for your clarification. >>>>>>>> In this sense, no matter which domain the MN's MAG belongs to, >>>>>>>> >>>>>>>> >>> as >>> >>> >>>>>> long >>>>>> >>>>>> >>>>>> >>>>>>> as the MN does not change LMA and MN's current MAG can setup SA >>>>>>> >>>>>>> >>>> with >>>> >>>> >>>>>> MN's >>>>>> >>>>>> >>>>>> >>>>>>> LMA, MN is still in the same PMIP6 domain as its LMA. Right? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regard! >>>>>>>> -Qin >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Sri Gundavelli" >>>>>>>> To: "Qin Wu" >>>>>>>> Cc: >>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > From Marco.Liebsch@nw.neclab.eu Wed Sep 9 08:15:30 2009 Return-Path: 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 CB3C928C2D8 for ; Wed, 9 Sep 2009 08:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_26=0.6] 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 HKvUYyayCXnn for ; Wed, 9 Sep 2009 08:15:29 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0762328C238 for ; Wed, 9 Sep 2009 08:15:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7DE442C0004E6; Wed, 9 Sep 2009 17:16:01 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN5ePZnD3Qp8; Wed, 9 Sep 2009 17:16:01 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 4B7032C0004DB; Wed, 9 Sep 2009 17:15:46 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 17:15:46 +0200 Message-ID: <4AA7C6A2.8080003@nw.neclab.eu> Date: Wed, 09 Sep 2009 17:15:46 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Qin Wu References: <5F09D220B62F79418461A978CA0921BD03879D03@pslexc01.psl.local> <4AA64EA8.7030008@nw.neclab.eu> <06bc01ca312a$0369e720$260ca40a@china.huawei.com> In-Reply-To: <06bc01ca312a$0369e720$260ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2009 15:15:46.0204 (UTC) FILETIME=[67D3DDC0:01CA3160] Cc: netext@ietf.org, Mohana Jeyatharan Subject: Re: [netext] [Netext] localized route optimization - roaming issue 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:15:30 -0000 Hi Qin, Qin Wu wrote: > Hi, Marco: > I think roaming case is very usful. It help us to better understanding > on how local routing works when MN roams over PMIPv6 domain. > So I support to add a new section to talk about roaming section. > Yes, I am ok with this. > In this sense, we can loose requirements on PMIPv6 components distribution. > i.e., MN's LMA and CN's LMA need not stay with MN and CN within the same > PMIPv6 domain, But it is required that MN and CN should connect to corresponding MAGs > within the same PMIPv6 domain, am I right? > I think your text fits better when talking about administrative domains ;-) I'd propose to take the last picture about the roaming case and take this as base for the discussion. In my opinion, we need to talk about administrative domains to resolve this. I also see the need to define (according to David's comment) what's an administrative domain this the context of this discussion. marco > Based these loose requirements or assumption, I think use case with two LMAs can be supported. > > As regarding protocol desgin, I think there is no reason to delay this work if folks have arrived at common understanding. > > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: "Mohana Jeyatharan" > Cc: "Qin Wu" ; "Marco Liebsch" ; > Sent: Tuesday, September 08, 2009 8:31 PM > Subject: Re: [netext] [Netext] localized route optimization - roaming issue > > > >> Hi Mohana, Qin, >> >> ok, we can take a section "Roaming Aspects" into account for the PS and >> discuss >> applicability of localized routing. We can add this section to the >> initial WG draft >> of the PS. If folks consider this later as not useful, we can take it >> out again. >> >> Btw, I think this discussion can happen in parallel to protocol design, >> just to address >> some folks' concern with a PS to delay the protocol design. >> >> From the discussion we had so far, obviously it's common understanding that >> use cases with two LMAs should be supported, right? >> >> Thanks, >> marco >> >> >> Mohana Jeyatharan wrote: >> >>> Hi Qin, Marco and all, >>> >>> >>> >>>> I am wondering whether we need to write something to address roaming >>>> >>>> >>> issue >>> >>> >>>> or what we talk about here is just to clarify how to understand local >>>> >>>> >>> MAG >>> >>> >>>> routing applicability. >>>> >>>> >>> Yes, I agree. The PS needs to mention about some deployment scenarios >>> wherevthe local MAG routing can be applied (ex bcos of SA available) and >>> scenarios where cannot be applied (SA cannot be established so cannot >>> perform). >>> *The scenarios Marco attached previously can be used. >>> *Perhaps some terminilogy such as PMIPv6 domain, administrative domain >>> etc in the PS will be helpful. I mean PMIPv6 doamin is already well >>> defined but re-emphasizing it w.r.t. to the work in local MAG routing >>> will be useful. >>> >>> I guess these canbe captured without any details of solutions in the PS >>> draft. Such capturing is useful to identify whether the solution drafts >>> we have address all such cases of local MAG route optimization >>> Again this is my opinion. >>> >>> Thanks. >>> >>> BR, >>> Mohana >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>> >>>> >>> Behalf >>> >>> >>>> Of Qin Wu >>>> Sent: Monday, September 07, 2009 11:02 AM >>>> To: Mohana Jeyatharan; Marco Liebsch >>>> Cc: netext@ietf.org >>>> Subject: Re: [netext] [Netext] localized route optimization - roaming >>>> issue >>>> >>>> Hi,Mohana and Marco: >>>> I am wondering whether we need to write something to address roaming >>>> >>>> >>> issue >>> >>> >>>> or what we talk about here is just to clarify how to understand local >>>> >>>> >>> MAG >>> >>> >>>> routing applicability. >>>> As for me, I think it is beneficial to have some explaination >>>> >>>> >>> text/section >>> >>> >>>> addressing this in the PS draft. >>>> >>>> Regards! >>>> -Qin >>>> ----- Original Message ----- >>>> From: "Mohana Jeyatharan" >>>> To: "Marco Liebsch" >>>> Cc: "Qin Wu" ; "Sri Gundavelli" >>>> >>>> >>> ; >>> >>> >>>> "Cypher, David E." ; >>>> Sent: Friday, September 04, 2009 4:44 PM >>>> Subject: RE: [Netext] localized route optimization - roaming issue >>>> >>>> >>>> Hi Marco, >>>> >>>> Such disussion we had is more to understand the local MAG routing >>>> applicability. >>>> >>>> >>>> >>>>> Or should we provide additional info in the >>>>> PS? >>>>> >>>>> >>>> So, I think in PS we need not talk about SA between MAG. Or LMA or >>>> >>>> >>> some >>> >>> >>>> other entity helping in creating the security association between >>>> >>>> >>> MAGs. >>> >>> >>>> Thanks. >>>> >>>> BR, >>>> Mohana >>>> >>>> >>>>> -----Original Message----- >>>>> From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] >>>>> Sent: Friday, September 04, 2009 4:19 PM >>>>> To: Mohana Jeyatharan >>>>> Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.; >>>>> netext@mail.mobileip.jp >>>>> Subject: Re: [Netext] localized route optimization - roaming issue >>>>> >>>>> Hi Mohana, >>>>> >>>>> Mohana Jeyatharan schrieb: >>>>> >>>>> >>>>>> Hi Marco and all, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>>> >>>>>>> >>>>>>> >>>>>> relation >>>>>> >>>>>> >>>>>> >>>>>>> between mobility management components of two MNs. >>>>>>> >>>>>>> >>>>>>> >>>>>> I agree on this. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>>> >>>>>>> >>>> context >>>> >>>> >>>>>> of >>>>>> >>>>>> >>>>>> >>>>>>> route optimization, must share a security association. Everything >>>>>>> >>>>>>> >>>> else >>>> >>>> >>>>>> is >>>>>> >>>>>> >>>>>> >>>>>>> deployment specific. >>>>>>> >>>>>>> >>>>>>> >>>>>> Here we can probably explain which entities need security >>>>>> >>>>>> >>>> association >>>> >>>> >>>>>> for RO to be succussful. This is more towards solution space tied >>>>>> >>>>>> >>> to >>> >>> >>>>>> different local MAG RO scenarios. I think the current localized RO >>>>>> solution drafts have captured these. >>>>>> >>>>>> >>>>>> >>>>> We can only provide examples. To establish a forwarding tunnel >>>>> >>>>> >>> between >>> >>> >>>>> MAGs does not mean >>>>> we need an SA between them. Only if we perform signaling between >>>>> >>>>> >>> MAGs, >>> >>> >>>>> the SA is required. >>>>> As you said, this is solution specific. So, to be on the safe side, >>>>> >>>>> >>> we >>> >>> >>>>> could discuss the >>>>> picture and indicate that the solution may need an SA between the >>>>> >>>>> >>> two >>> >>> >>>>> associated LMAs >>>>> and the two associated MAGs. Or should we provide additional info in >>>>> >>>>> >>>> the >>>> >>>> >>>>> PS? >>>>> >>>>> marco >>>>> >>>>> >>>>> >>>>>> BR, >>>>>> Mohana >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu] >>>>>>> Sent: Thursday, September 03, 2009 11:56 PM >>>>>>> To: Qin Wu >>>>>>> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco >>>>>>> >>>>>>> >>>>>>> >>>>>> Liebsch; >>>>>> >>>>>> >>>>>> >>>>>>> netext@mail.mobileip.jp >>>>>>> Subject: Re: [Netext] localized route optimization - roaming >>>>>>> >>>>>>> >>> issue >>> >>> >>>>>>> Now coming back to my original opinion that I don't see benefit >>>>>>> >>>>>>> >>> in >>> >>> >>>>>>> mandating support for or ruling out any particular roaming >>>>>>> >>>>>>> >>>> scenarios. >>>> >>>> >>>>>>> The picture I proposed could be used in the Problem Statement >>>>>>> >>>>>>> >>> (PS) >>> >>> >>>>>>> at the most to discuss *issues* when components being associated >>>>>>> with MN1 and MN2 are distributed between administrative domains. >>>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we >>>>>>> do not talk about the scope of a single MN's mobility, but the >>>>>>> >>>>>>> >>>>>>> >>>>>> relation >>>>>> >>>>>> >>>>>> >>>>>>> between mobility management components of two MNs. >>>>>>> >>>>>>> From that picture I see that only one requirement derives for >>>>>>> >>>>>>> >>> the >>> >>> >>>>>>> protocol >>>>>>> solution: PMIPv6 components, which exchange signaling in the >>>>>>> >>>>>>> >>>> context >>>> >>>> >>>>>> of >>>>>> >>>>>> >>>>>> >>>>>>> route optimization, must share a security association. Everything >>>>>>> >>>>>>> >>>> else >>>> >>>> >>>>>> is >>>>>> >>>>>> >>>>>> >>>>>>> deployment specific. >>>>>>> >>>>>>> marco >>>>>>> >>>>>>> >>>>>>> >>>>>>> Qin Wu wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thank for your clarification. >>>>>>>> In this sense, no matter which domain the MN's MAG belongs to, >>>>>>>> >>>>>>>> >>> as >>> >>> >>>>>> long >>>>>> >>>>>> >>>>>> >>>>>>> as the MN does not change LMA and MN's current MAG can setup SA >>>>>>> >>>>>>> >>>> with >>>> >>>> >>>>>> MN's >>>>>> >>>>>> >>>>>> >>>>>>> LMA, MN is still in the same PMIP6 domain as its LMA. Right? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Regard! >>>>>>>> -Qin >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Sri Gundavelli" >>>>>>>> To: "Qin Wu" >>>>>>>> Cc: >>>>>>>> >>>>>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>>> From Marco.Liebsch@nw.neclab.eu Wed Sep 9 09:18:14 2009 Return-Path: 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 ABD113A6A1D for ; Wed, 9 Sep 2009 09:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001] 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 pAIQheJpJTPu for ; Wed, 9 Sep 2009 09:18:13 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id AB6D428C422 for ; Wed, 9 Sep 2009 09:18:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 446572C0012C3 for ; Wed, 9 Sep 2009 18:18:46 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BabNCdAuR2dq for ; Wed, 9 Sep 2009 18:18:46 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 2798F2C0004DB for ; Wed, 9 Sep 2009 18:18:41 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 18:18:41 +0200 Message-ID: <4AA7D561.5010501@nw.neclab.eu> Date: Wed, 09 Sep 2009 18:18:41 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: netext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Sep 2009 16:18:41.0066 (UTC) FILETIME=[31D218A0:01CA3169] Subject: [netext] Roaming etc. - some definitions 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 16:18:14 -0000 In the context of the discussion about localized routing in roaming cases, please see below definitions as starting point. Please comment, so we can converge and reflect the common picture in the PS draft. Definitions: + "PMIPv6 domain" defined as in RFC5213 + "Administrative domain" (in the context of this discussion): A collection of network components (Routers, MAGs, LMAs) and the interconnecting network managed by a single administrative authority. In the context of this discussion, an administrative authority can be understood as an operator within one country. "Within one country" is in my opinion necessary to distinguish say T-Mobile Germany from T-Mobile US, looks like one operator, but are in fact different PLMNs. Hence, ddministrative domain is identified by the tuple Operator + Country code. Alternatively, we can use/define PLMN if this is preferable. + "Roaming": attachment of a subscriber from administrative domain/PLMN (PLMN A) in the network of a different administrative domain (PLMN B). This includes national as well as international roaming. Best regards, marco From Basavaraj.Patil@nokia.com Wed Sep 9 09:35:07 2009 Return-Path: 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 B39CF28C23A for ; Wed, 9 Sep 2009 09:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 fVDoCcr9uyzM for ; Wed, 9 Sep 2009 09:35:06 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 882C528C11B for ; Wed, 9 Sep 2009 09:35:06 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n89GZL6P011536; Wed, 9 Sep 2009 19:35:23 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 19:35:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 19:35:25 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 9 Sep 2009 18:35:25 +0200 From: To: , Date: Wed, 9 Sep 2009 18:35:34 +0200 Thread-Topic: [netext] Roaming etc. - some definitions Thread-Index: AcoxaTuFNjJumbyrSaeFB2wHiqTNhQAAlINA Message-ID: In-Reply-To: <4AA7D561.5010501@nw.neclab.eu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Sep 2009 16:35:25.0939 (UTC) FILETIME=[88C58C30:01CA316B] Subject: Re: [netext] Roaming etc. - some definitions 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 16:35:07 -0000 Hi Marco, On 9/9/09 11:18 AM, "ext Marco Liebsch" wrote: > In the context of the discussion about localized routing in roaming cases= , > please see below definitions as starting point. Please comment, so we can > converge and reflect the common picture in the PS draft. >=20 >=20 > Definitions: >=20 > + "PMIPv6 domain" defined as in RFC5213 >=20 > + "Administrative domain" (in the context of this discussion): A > collection of network components (Routers, MAGs, LMAs) > and the interconnecting network managed by a single administrative > authority. In the context of this discussion, > an administrative authority can be understood as an operator within one > country. "Within one country" is in my opinion > necessary to distinguish say T-Mobile Germany from T-Mobile US, looks > like one operator, > but are in fact different PLMNs. Hence, ddministrative domain is > identified by the tuple Operator + Country code. > Alternatively, we can use/define PLMN if this is preferable. I don't think the scoping of administrative domain being limited to "within one country" is a good choice. Also the term PLMN is definitely not something we should be taking into the lexicon of this I-D. Maybe you can reuse the terminology of Administrative domain from RFC1136 o= r for a more recent one in RFC4375 which defines it as: " Administrative Domain: The collection of resources under the control of a single administrative authority. This authority establishes the design and operation of a set of resources (i.e., the network). " We should avoid MCC+MNC type of identifiers and at best use them only as an example. >=20 > + "Roaming": attachment of a subscriber from administrative domain/PLMN > (PLMN A) in the network of a different > administrative domain (PLMN B). This includes national as well as > international roaming. Again, I think it is best to avoid PLMN concepts here. Maybe reuse the term defined by the Roamops WG in the RFC2486 : " Roaming Capability Roaming capability can be loosely defined as the ability to use any one of multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of cases where roaming capability might be required include ISP "confederations" and ISP- provided corporate network access support. " I think the above would suffice in the context of this discussion. -Raj >=20 >=20 > Best regards, > marco >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Wed Sep 9 10:22:21 2009 Return-Path: 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 D53753A69AD for ; Wed, 9 Sep 2009 10:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 OUucl6i2BrZe for ; Wed, 9 Sep 2009 10:22:21 -0700 (PDT) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 246E63A68DB for ; Wed, 9 Sep 2009 10:22:18 -0700 (PDT) Received: (qmail 62310 invoked by uid 60001); 9 Sep 2009 16:32:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252513950; bh=suMauX73ntFXN514VKN0+o4atYNnr4U49UQRdolBiFY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=nICMB+/hNi+pCrrnccP1FRaNRzGeEch1ihwcwAiTp/zBkRPVwxQgMoPrsc19f1dGMR34zbBHfi+0ZGbd5DuPox9NcWcb14MJlfkIlJlq5+b5fdTizC5V7F80PiNiyafWlJPcMBt1ymy0chFaRrybpP8t7deFx8lgshazOpdir8k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=X4NUcAmzRZw4G4g9W/lmFRGCobhjcpOToo/0X0FqctaB6lQRhc1ZE/wc78LEAa5SIinMputI0iS91omtm27yRzT1kkHJWuelU0PV9Z/2YRgkuGsuossiiWKqf6dAQulY2YXtC8o/nGqYzukqGu3Etvhm+phs3RFyomLIBbKDJJ8=; Message-ID: <10355.61838.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: 0nhqu.8VM1nrPd5WQtgU_2APHDOskIxUrDowgqtSQ3tkBjXsTC8HSZiUDpIe7bPIihykv0Ot9KUpgsxIuXGwGrSfv2WRrQmHTuAookCdyuyyAyjDD3WdDcD8.p9h6M5Hufjlw9lrZfLWDsClpAdysg5LIY9RmVz6we7f54inRqtV9rLh1Vu_VvQx9IXnb9oNB.U4VvHb4JJAjISqUoAqtBuv4JSnfnvkmINAu.nqRaebU8uMSPEAwlYuPkBZ2WnzxzWt6NadSe8RTYAeRdYc_IuJBK6SwOd2wtDgH0320MNeCAD.Q9w_DsU- Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Wed, 09 Sep 2009 09:32:29 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 References: <4AA7D561.5010501@nw.neclab.eu> Date: Wed, 9 Sep 2009 09:32:29 -0700 (PDT) From: Behcet Sarikaya To: Marco Liebsch , netext@ietf.org In-Reply-To: <4AA7D561.5010501@nw.neclab.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netext] Roaming etc. - some definitions X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 17:22:21 -0000 Marco, administrative domain is defined in RFC 1136 http://tools.ietf.org/html/rfc1136 in 1989, i.e. 20 years ago. Are you trying to reinvent the wheel? Regards, Behcet ----- Original Message ---- > From: Marco Liebsch > To: netext@ietf.org > Sent: Wednesday, September 9, 2009 11:18:41 AM > Subject: [netext] Roaming etc. - some definitions > > In the context of the discussion about localized routing in roaming cases, > please see below definitions as starting point. Please comment, so we can > converge and reflect the common picture in the PS draft. > > > Definitions: > > + "PMIPv6 domain" defined as in RFC5213 > > + "Administrative domain" (in the context of this discussion): A collection of > network components (Routers, MAGs, LMAs) > and the interconnecting network managed by a single administrative authority. In > the context of this discussion, > an administrative authority can be understood as an operator within one country. > "Within one country" is in my opinion > necessary to distinguish say T-Mobile Germany from T-Mobile US, looks like one > operator, > but are in fact different PLMNs. Hence, ddministrative domain is identified by > the tuple Operator + Country code. > Alternatively, we can use/define PLMN if this is preferable. > > + "Roaming": attachment of a subscriber from administrative domain/PLMN (PLMN A) > in the network of a different > administrative domain (PLMN B). This includes national as well as international > roaming. > > > Best regards, > marco > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Wed Sep 9 11:04:36 2009 Return-Path: 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 4BDAF28C4F1 for ; Wed, 9 Sep 2009 11:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6] 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 d5nwPpaI+Bsp for ; Wed, 9 Sep 2009 11:04:35 -0700 (PDT) Received: from web111416.mail.gq1.yahoo.com (web111416.mail.gq1.yahoo.com [67.195.15.222]) by core3.amsl.com (Postfix) with SMTP id 77C7D28C26A for ; Wed, 9 Sep 2009 11:04:35 -0700 (PDT) Received: (qmail 99800 invoked by uid 60001); 9 Sep 2009 18:05:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252519506; bh=PtbHxoYq20XcCmGq5jJDWSiUEwC4VhHC9+9s9riGxz8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Bori8TX+jOpLkK9UIfsd8g8btb1/NZu2KmdpoQlo4ePC5sMdysQmHLfnC5QU3XNRuNliCFmVnxthISJKYrgdPHYT73s58beZcgmpzchrHS2/jLTv/2xwYSguTXXg5Wj2TC5ISLEUidH+QehHwJ7qLTT2EqSfKgeVEtJeeG1P67I= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=yEymk2SZaHmn8ORJ1Ltm6iJbssYSOBMwp6nC8BVm9ShrkUFOz7dLlzluTS8iyOYa3NFiqnSNzc2kvVt2BjVEC000QJ6qvL7lm9ZBzB4Kel66Fcv3ul4yUR1WsHfATeBCyBtAqbeHk/q+OSSIDX4b5yTaosd+2C1ozq+kIC5xUgY=; Message-ID: <655179.97984.qm@web111416.mail.gq1.yahoo.com> X-YMail-OSG: mp_7mPoVM1mIupPSzp5_KS6AuaCaCbiMqnJcdKbz.eoierd8L7ZhgXIadoORNypKiC.M7Wnq5saYXPZPyTE9xzz9I13MDpqUx2JsbSzoIID5heFbrRuUBL1hN8c.N_i4HzmUJGFDh1C2R8.GcOnYO3XylMRJ2GdrIOet3UygfgfMbun78_D66MpcjEFIU6X9Wil4iLmuwfry_lcqe3kMlltMMj66ZvsQwjcBx2Bj9QaUeF4MTp1zCrzHopaiNSQYQ6JanorIzChbhD8GJKPFY0JdqwBhZhAfoQAkb1vNE5XUF19GqPHbAF0- Received: from [206.16.17.212] by web111416.mail.gq1.yahoo.com via HTTP; Wed, 09 Sep 2009 11:05:06 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 References: Date: Wed, 9 Sep 2009 11:05:06 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, liebsch@nw.neclab.eu, netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netext] Roaming etc. - some definitions X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:04:36 -0000 I agree. Regards, Behcet ----- Original Message ---- > From: "Basavaraj.Patil@nokia.com" > To: liebsch@nw.neclab.eu; netext@ietf.org > Sent: Wednesday, September 9, 2009 11:35:34 AM > Subject: Re: [netext] Roaming etc. - some definitions > > > Hi Marco, > > > On 9/9/09 11:18 AM, "ext Marco Liebsch" wrote: > > > In the context of the discussion about localized routing in roaming cases, > > please see below definitions as starting point. Please comment, so we can > > converge and reflect the common picture in the PS draft. > > > > > > Definitions: > > > > + "PMIPv6 domain" defined as in RFC5213 > > > > + "Administrative domain" (in the context of this discussion): A > > collection of network components (Routers, MAGs, LMAs) > > and the interconnecting network managed by a single administrative > > authority. In the context of this discussion, > > an administrative authority can be understood as an operator within one > > country. "Within one country" is in my opinion > > necessary to distinguish say T-Mobile Germany from T-Mobile US, looks > > like one operator, > > but are in fact different PLMNs. Hence, ddministrative domain is > > identified by the tuple Operator + Country code. > > Alternatively, we can use/define PLMN if this is preferable. > > I don't think the scoping of administrative domain being limited to "within > one country" is a good choice. Also the term PLMN is definitely not > something we should be taking into the lexicon of this I-D. > > Maybe you can reuse the terminology of Administrative domain from RFC1136 or > for a more recent one in RFC4375 which defines it as: > > " Administrative Domain: The collection of resources under the > control of a single administrative authority. This authority > establishes the design and operation of a set of resources > (i.e., the network). > " > > We should avoid MCC+MNC type of identifiers and at best use them only as an > example. > > > > > + "Roaming": attachment of a subscriber from administrative domain/PLMN > > (PLMN A) in the network of a different > > administrative domain (PLMN B). This includes national as well as > > international roaming. > > Again, I think it is best to avoid PLMN concepts here. Maybe reuse the term > defined by the Roamops WG in the RFC2486 : > " > Roaming Capability > Roaming capability can be loosely defined as the ability to > use any one of multiple Internet service providers (ISPs), > while maintaining a formal, customer-vendor relationship > with only one. Examples of cases where roaming capability > might be required include ISP "confederations" and ISP- > provided corporate network access support. > " > > I think the above would suffice in the context of this discussion. > > -Raj > > > > > > > Best regards, > > marco > > > > > > > > > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Marco.Liebsch@nw.neclab.eu Thu Sep 10 00:58:39 2009 Return-Path: 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 E61FE3A6918 for ; Thu, 10 Sep 2009 00:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, 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 woeEFGWEFOZo for ; Thu, 10 Sep 2009 00:58:39 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D48813A6A19 for ; Thu, 10 Sep 2009 00:58:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8089B2C0004DB; Thu, 10 Sep 2009 09:59:12 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyh-0YlfiQfS; Thu, 10 Sep 2009 09:59:12 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 5D9352C0002FE; Thu, 10 Sep 2009 09:59:02 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 09:59:02 +0200 Message-ID: <4AA8B1C2.8030002@nw.neclab.eu> Date: Thu, 10 Sep 2009 09:58:58 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Behcet Sarikaya References: <4AA7D561.5010501@nw.neclab.eu> <10355.61838.qm@web111403.mail.gq1.yahoo.com> In-Reply-To: <10355.61838.qm@web111403.mail.gq1.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2009 07:59:02.0236 (UTC) FILETIME=[8F7569C0:01CA31EC] Cc: netext@ietf.org Subject: Re: [netext] Roaming etc. - some definitions 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 07:58:40 -0000 Behcet Sarikaya wrote: > Marco, administrative domain is defined in RFC 1136 > http://tools.ietf.org/html/rfc1136 > > in 1989, i.e. 20 years ago. > > Are you trying to reinvent the wheel? > wheel, good idea. Let's go for it.. ;-) No, just propose a definition in the context of this discussion and localized routing. Discussion is about deployment scenarios. So, 3GPP is one candidate to deploy localized routing. And so far we mixed terms such as H/VPLMN, administrative domain, PMIPv6 domain. Hence, a 3GPP oriented attempt for a definition. If you think the referred definitions suit the discussion, fine with me. Greetings, marco > Regards, > > Behcet > > > ----- Original Message ---- > >> From: Marco Liebsch >> To: netext@ietf.org >> Sent: Wednesday, September 9, 2009 11:18:41 AM >> Subject: [netext] Roaming etc. - some definitions >> >> In the context of the discussion about localized routing in roaming cases, >> please see below definitions as starting point. Please comment, so we can >> converge and reflect the common picture in the PS draft. >> >> >> Definitions: >> >> + "PMIPv6 domain" defined as in RFC5213 >> >> + "Administrative domain" (in the context of this discussion): A collection of >> network components (Routers, MAGs, LMAs) >> and the interconnecting network managed by a single administrative authority. In >> the context of this discussion, >> an administrative authority can be understood as an operator within one country. >> "Within one country" is in my opinion >> necessary to distinguish say T-Mobile Germany from T-Mobile US, looks like one >> operator, >> but are in fact different PLMNs. Hence, ddministrative domain is identified by >> the tuple Operator + Country code. >> Alternatively, we can use/define PLMN if this is preferable. >> >> + "Roaming": attachment of a subscriber from administrative domain/PLMN (PLMN A) >> in the network of a different >> administrative domain (PLMN B). This includes national as well as international >> roaming. >> >> >> Best regards, >> marco >> >> >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Marco.Liebsch@nw.neclab.eu Thu Sep 10 01:06:42 2009 Return-Path: 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 004BB3A6918 for ; Thu, 10 Sep 2009 01:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 PKkdLQNW+M61 for ; Thu, 10 Sep 2009 01:06:41 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E4DF73A6A35 for ; Thu, 10 Sep 2009 01:06:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 16C462C0012C6; Thu, 10 Sep 2009 10:07:15 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAEFEIXlYfPX; Thu, 10 Sep 2009 10:07:14 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id E2A452C0002FE; Thu, 10 Sep 2009 10:07:04 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 10:07:04 +0200 Message-ID: <4AA8B3A9.7030301@nw.neclab.eu> Date: Thu, 10 Sep 2009 10:07:05 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2009 08:07:04.0829 (UTC) FILETIME=[AF1B42D0:01CA31ED] Cc: netext@ietf.org Subject: Re: [netext] Roaming etc. - some definitions 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 08:06:42 -0000 Hi Raj, Basavaraj.Patil@nokia.com wrote: > Hi Marco, > > > On 9/9/09 11:18 AM, "ext Marco Liebsch" wrote: > > >> In the context of the discussion about localized routing in roaming cases, >> please see below definitions as starting point. Please comment, so we can >> converge and reflect the common picture in the PS draft. >> >> >> Definitions: >> >> + "PMIPv6 domain" defined as in RFC5213 >> >> + "Administrative domain" (in the context of this discussion): A >> collection of network components (Routers, MAGs, LMAs) >> and the interconnecting network managed by a single administrative >> authority. In the context of this discussion, >> an administrative authority can be understood as an operator within one >> country. "Within one country" is in my opinion >> necessary to distinguish say T-Mobile Germany from T-Mobile US, looks >> like one operator, >> but are in fact different PLMNs. Hence, ddministrative domain is >> identified by the tuple Operator + Country code. >> Alternatively, we can use/define PLMN if this is preferable. >> > > I don't think the scoping of administrative domain being limited to "within > one country" is a good choice. Also the term PLMN is definitely not > something we should be taking into the lexicon of this I-D. > > Maybe you can reuse the terminology of Administrative domain from RFC1136 or > for a more recent one in RFC4375 which defines it as: > > " Administrative Domain: The collection of resources under the > control of a single administrative authority. This authority > establishes the design and operation of a set of resources > (i.e., the network). > " > > Fine, if this is clear to everybody for the discussion we have. I am ok with it. > We should avoid MCC+MNC type of identifiers and at best use them only as an > example. > Sure, they are examples to support understanding of the scope. > >> + "Roaming": attachment of a subscriber from administrative domain/PLMN >> (PLMN A) in the network of a different >> administrative domain (PLMN B). This includes national as well as >> international roaming. >> > > Again, I think it is best to avoid PLMN concepts here. Maybe reuse the term > defined by the Roamops WG in the RFC2486 : > " > Roaming Capability > Roaming capability can be loosely defined as the ability to > use any one of multiple Internet service providers (ISPs), > while maintaining a formal, customer-vendor relationship > with only one. Examples of cases where roaming capability > might be required include ISP "confederations" and ISP- > provided corporate network access support. > " > > I think the above would suffice in the context of this discussion. > Same as above: If it's clear to everybody when these definitions are used in the context of localized routing deployment within operator networks, fine with me. marco > -Raj > > >> Best regards, >> marco >> >> >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > From sunseawq@huawei.com Thu Sep 10 05:29:33 2009 Return-Path: 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 907A03A6AB3 for ; Thu, 10 Sep 2009 05:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[AWL=1.614, 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 feQeZ6vX5anr for ; Thu, 10 Sep 2009 05:29:29 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A449F3A6AB9 for ; Thu, 10 Sep 2009 05:29:27 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPR00DU89E0BC@szxga03-in.huawei.com> for netext@ietf.org; Thu, 10 Sep 2009 20:30:00 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPR00L2K9E0VF@szxga03-in.huawei.com> for netext@ietf.org; Thu, 10 Sep 2009 20:30:00 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPR00KGT9E0EW@szxml04-in.huawei.com> for netext@ietf.org; Thu, 10 Sep 2009 20:30:00 +0800 (CST) Date: Thu, 10 Sep 2009 20:29:57 +0800 From: Qin Wu To: Marco Liebsch , Basavaraj.Patil@nokia.com Message-id: <041f01ca3212$6881af10$260ca40a@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: <4AA7C4CE.1030305@nw.neclab.eu> Cc: netext@ietf.org, Mohana.Jeyatharan@sg.panasonic.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 12:29:33 -0000 Hi, all: Since folks has no objection to add a section to talk about roaming issues. I would like to propose some texts based on roaming picture proposed by Marco. The proposed text is as follows: " In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) can be distributed into different PMIPv6 domains. In order to support localized routing, it is required that MAGs to which MN and CN connect are within the same PMIPv6 domain and each MAG setup security relationship respectively with corresponding LMAs which maintain specific context to which MN and CN belong. It is not required that LMAs anchored by MN and CN are part of PMIPv6 domain as MAGs attached by MN and CN. MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or over different PMIPv6 domains(i.e., MN's visited domains). CN should stay with MN within the same PMIPv6 domain. Figure x shows PMIPv6 roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 domain. In this figure, four PMIPv6 roaming cases need to be taken into account. Roaming case 1: MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located in the same PMIPv6 domain A as described in the figure 2. Roaming case 2: MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B. Roaming case 3: MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A Roaming case 4: MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is located in the PMIPv6 domain B " -------------------------------------------------------------------------------- > > > | > +-----+ +-----+ | +-----+ > |LMA1 | |LMA2 | | |LMA2'| > +-----+ +-----+ | +-----+ > | > | > | > | > +-----+ +-----+ | > |MAG1 | |MAG2 | | > +-----+ +-----+ | > | > | > A | B > ------------------------------+------------------------------- > C > > > +-----+ +-----+ > |MAG1'| |MAG2'| > +-----+ +-----+ > > > > > > > -------------------------------------------------------------------------------- If people prefer to use administrative domain, we can replace all PMIPv6 domain in the proposed text with *administrative domain*, Welcome your bash,:-) Regards! -Qin ----- Original Message ----- From: "Marco Liebsch" To: Cc: ; Sent: Wednesday, September 09, 2009 11:07 PM Subject: Re: [netext] [Netext] localized route optimization - roaming issue > Hi Raj, > > yes, agreed, that's why it has been proposed to add a section on this in > the PS. The picture > could be based on what I sent some mails ago. We're currently preparing > some text, but > I think it makes sense to discuss and agree on the text before it goes > to the PS draft. > > marco > > Basavaraj.Patil@nokia.com wrote: >> Hi Marco, >> >> One of the issues that we got hung up at IETF75 during the LR discussion was >> on roaming. It would be good to have a clear description of the relationship >> between the MAG and LMA in the context of a PMIP6 domain especially when you >> consider home and visited network scenarios wherein the MAG/LMA entities are >> in different domains. >> >> The PMIP6 domain definition in RFC5213: >> " >> Proxy Mobile IPv6 domain refers to the network where the mobility >> management of a mobile node is handled using the Proxy Mobile IPv6 >> protocol as defined in this specification. The Proxy Mobile IPv6 >> domain includes local mobility anchors and mobile access gateways >> between which security associations can be set up and >> authorization for sending Proxy Binding Updates on behalf of the >> mobile nodes can be ensured. >> " >> >> does not have any references to home/visited network concepts. The only >> criteria for an entity (MAG/LMA) being considered being a part of the PMIP6 >> domain is the existence of a security association. It would be good to >> elaborate how this maps to the current discussion in LR. >> >> -Raj From Marco.Liebsch@nw.neclab.eu Thu Sep 10 05:58:26 2009 Return-Path: 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 451CA3A68C6 for ; Thu, 10 Sep 2009 05:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 fZYqz6-0cXaf for ; Thu, 10 Sep 2009 05:58:25 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id EAB173A67B2 for ; Thu, 10 Sep 2009 05:58:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5C1372C0012C6; Thu, 10 Sep 2009 14:58:59 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHA+Ju7V6csq; Thu, 10 Sep 2009 14:58:59 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 9A0E52C0002FE; Thu, 10 Sep 2009 14:58:38 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Sep 2009 14:58:38 +0200 Message-ID: <4AA8F7FA.3050805@nw.neclab.eu> Date: Thu, 10 Sep 2009 14:58:34 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Qin Wu References: <4AA7C4CE.1030305@nw.neclab.eu> <041f01ca3212$6881af10$260ca40a@china.huawei.com> In-Reply-To: <041f01ca3212$6881af10$260ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Sep 2009 12:58:38.0536 (UTC) FILETIME=[6A2B1C80:01CA3216] Cc: netext@ietf.org, Mohana.Jeyatharan@sg.panasonic.com, Basavaraj.Patil@nokia.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 12:58:26 -0000 Hi Qin, thanks for proposing some text. I think it's a good starting point. Please see for a comment inline. marco Qin Wu wrote: > Hi, all: > Since folks has no objection to add a section to talk about roaming issues. I would like to propose > some texts based on roaming picture proposed by Marco. The proposed text is as follows: > " > In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) can be distributed into different PMIPv6 domains. In order to support localized routing, it is required that MAGs to which MN and CN connect are within the same PMIPv6 domain and each MAG setup security relationship respectively with corresponding LMAs which maintain specific context to which MN and CN belong. I am not sure if we can say that the two MAGs belong to the same PMIP domain, can we? Look at the picture: MAG1' and MAG2' (roaming case) belong to one PLMN (or administrative domain), I think that was the requirement we talked about some time ago. Now, MN is attached to MAG1' and registered with LMA1, whereas CN is attached to MAG2' and registered with LMA2 or LMA2'. MAG1' and LMA1 build one PMIP domain, MAG2' and LMA2/LMA2' build one PMIP domain. I don't think this implies that MAG1' and MAG2' are in the same PMIP domain. This also means that we cannot assume that MAG1 has an SA with LMA2/LMA2'. Hence, MN and CN are attached to different PMIPv6 domains. That's at least my view. > It is not required that LMAs anchored by MN and CN are part of PMIPv6 domain as MAGs attached by MN and CN. MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or over different PMIPv6 domains(i.e., MN's visited domains). CN should stay with MN within the same PMIPv6 domain. Figure x shows PMIPv6 roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 domain. In this figure, four PMIPv6 roaming cases need to be taken into account. > Roaming case 1: > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located in the same PMIPv6 domain A as described in the figure 2. > Roaming case 2: > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B. > Roaming case 3: > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A > Roaming case 4: > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is located in the PMIPv6 domain B > > " > > > -------------------------------------------------------------------------------- > > > >> | >> +-----+ +-----+ | +-----+ >> |LMA1 | |LMA2 | | |LMA2'| >> +-----+ +-----+ | +-----+ >> | >> | >> | >> | >> +-----+ +-----+ | >> |MAG1 | |MAG2 | | >> +-----+ +-----+ | >> | >> | >> A | B >> ------------------------------+------------------------------- >> C >> >> >> +-----+ +-----+ >> |MAG1'| |MAG2'| >> +-----+ +-----+ >> >> >> >> >> >> >> >> > > > -------------------------------------------------------------------------------- > > If people prefer to use administrative domain, we can replace all PMIPv6 domain in the proposed text with *administrative domain*, Welcome your bash,:-) > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: > Cc: ; > Sent: Wednesday, September 09, 2009 11:07 PM > Subject: Re: [netext] [Netext] localized route optimization - roaming issue > > > >> Hi Raj, >> >> yes, agreed, that's why it has been proposed to add a section on this in >> the PS. The picture >> could be based on what I sent some mails ago. We're currently preparing >> some text, but >> I think it makes sense to discuss and agree on the text before it goes >> to the PS draft. >> >> marco >> >> Basavaraj.Patil@nokia.com wrote: >> >>> Hi Marco, >>> >>> One of the issues that we got hung up at IETF75 during the LR discussion was >>> on roaming. It would be good to have a clear description of the relationship >>> between the MAG and LMA in the context of a PMIP6 domain especially when you >>> consider home and visited network scenarios wherein the MAG/LMA entities are >>> in different domains. >>> >>> The PMIP6 domain definition in RFC5213: >>> " >>> Proxy Mobile IPv6 domain refers to the network where the mobility >>> management of a mobile node is handled using the Proxy Mobile IPv6 >>> protocol as defined in this specification. The Proxy Mobile IPv6 >>> domain includes local mobility anchors and mobile access gateways >>> between which security associations can be set up and >>> authorization for sending Proxy Binding Updates on behalf of the >>> mobile nodes can be ensured. >>> " >>> >>> does not have any references to home/visited network concepts. The only >>> criteria for an entity (MAG/LMA) being considered being a part of the PMIP6 >>> domain is the existence of a security association. It would be good to >>> elaborate how this maps to the current discussion in LR. >>> >>> -Raj >>> From sunseawq@huawei.com Thu Sep 10 19:22:41 2009 Return-Path: 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 E81143A6A10 for ; Thu, 10 Sep 2009 19:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 DIfHeqBEkHaE for ; Thu, 10 Sep 2009 19:22:40 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7FB373A676A for ; Thu, 10 Sep 2009 19:22:40 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPS0073YBYHLE@szxga04-in.huawei.com> for netext@ietf.org; Fri, 11 Sep 2009 10:23:06 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPS0076GBYH2F@szxga04-in.huawei.com> for netext@ietf.org; Fri, 11 Sep 2009 10:23:05 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPS00932BYHD2@szxml06-in.huawei.com> for netext@ietf.org; Fri, 11 Sep 2009 10:23:05 +0800 (CST) Date: Fri, 11 Sep 2009 10:23:04 +0800 From: Qin Wu To: Marco Liebsch Message-id: <012301ca3286$cb1c5ac0$260ca40a@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: <4AA7C4CE.1030305@nw.neclab.eu> <041f01ca3212$6881af10$260ca40a@china.huawei.com> <4AA8F7FA.3050805@nw.neclab.eu> Cc: netext@ietf.org, Mohana.Jeyatharan@sg.panasonic.com, Basavaraj.Patil@nokia.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 02:22:42 -0000 Hi, Marco and all: ----- Original Message ----- From: "Marco Liebsch" To: "Qin Wu" Cc: ; ; Sent: Thursday, September 10, 2009 8:58 PM Subject: Re: [Netext] roaming issue-proposed text for roaming section > Hi Qin, > > thanks for proposing some text. I think it's a good starting point. > Please see for a comment inline. > > marco > > Qin Wu wrote: >> Hi, all: >> Since folks has no objection to add a section to talk about roaming issues. I would like to propose >> some texts based on roaming picture proposed by Marco. The proposed text is as follows: >> " >> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) can be distributed into different PMIPv6 domains. In order to support localized routing, it is required that MAGs to which MN and CN connect are within the same PMIPv6 domain and each MAG setup security relationship respectively with corresponding LMAs which maintain specific context to which MN and CN belong. > I am not sure if we can say that the two MAGs belong to the same PMIP > domain, can we? Look at the picture: MAG1' and MAG2' (roaming case) > belong to one PLMN (or administrative domain), I think that was the > requirement we talked about some time ago. Now, MN is attached to MAG1' > and registered with LMA1, whereas CN is attached to MAG2' and registered > with LMA2 or LMA2'. MAG1' and LMA1 build one PMIP domain, MAG2' > and LMA2/LMA2' build one PMIP domain. I don't think this implies that > MAG1' and MAG2' are in the same PMIP domain. This also means that > we cannot assume that MAG1 has an SA with LMA2/LMA2'. Hence, MN > and CN are attached to different PMIPv6 domains. That's at least my view. [Qin]: I know your concerns. I think we have some misunderstanding on PMIPv6 domain or *administrative domain* In my mind, *Administrative A, B,C* are really *PMIPv6 domain A, B,C* I understand respectively. In this way, we can see 1.LMA1,LMA2,MAG1,MAG2 do not leave PMIPv6 domain A 2. LMA2' does not leave PMIPv6 domain B 3. MAG1',MAG2' do not leave PMIPv6 domain C. Only MN and CN can roam within one PMIPv6 domain or roam over different PMIPv6 domain. whatever MN move around, MN still belong to the same PMIPv6 domain as LMA which maintains MN's context information. As regarding whether MAG1' and LMA1 build one PMIP domain, MAG2' and LMA2/LMA2' build one PMIP domain, I have the same understanding as you before. But from the discussion in the ML, I have new understanding. In my opinion, MAG1' belongs to PMIPv6 domain C, when MN is attached to the MAG1', MN will be achcored to LMA1 in the PMIPv6 domain A(i.e., MN's home PMIPv6 domain) through MAG1' in the PMIPv6 domain C(i.e., one visited PMIPv6 domain). In this sense, MAG1' still belong to PMIPv6 domain C and MN and MN's LMA(i.e., LMA1) still belong to the PMIPv6 domain A. So it seems not reasonable to say we build one new PMIPv6 domain containing MAG1' and LMA1. So my conclusion is PMIPv6 domain can be understand as PLMN, we can allow two different PMIPv6 domains are interconnected with each other, but we are not necessary to understand them as one big PMIPv6 domain. On the other hand, MAGs in one PMIPv6 domain can be attached by MN which belongs to the same PMIPv6 domain as these MAGs. and MAGs in one PMIPv6 domain also can be attached by MN moving from another PMIPv6 domain, in other words MN and MAGs may belong to different PMIPv6 domains although MN communicates with LMAs through these MAGs. So if MAGs does not leave one PMIPv6 domain, these MAGs can be understood to belong to this PMIPv6 domain. And these MAGs can be used to access LMAs by MNs which belong to different PMIPv6 domain. Does this make sense? >> It is not required that LMAs anchored by MN and CN are part of PMIPv6 domain as MAGs attached by MN and CN. MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or over different PMIPv6 domains(i.e., MN's visited domains). CN should stay with MN within the same PMIPv6 domain. Figure x shows PMIPv6 roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 domain. In this figure, four PMIPv6 roaming cases need to be taken into account. >> Roaming case 1: >> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located in the same PMIPv6 domain A as described in the figure 2. >> Roaming case 2: >> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B. >> Roaming case 3: >> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A >> Roaming case 4: >> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is located in the PMIPv6 domain B >> >> " >> >> >> -------------------------------------------------------------------------------- >> >> >> >>> | >>> +-----+ +-----+ | +-----+ >>> |LMA1 | |LMA2 | | |LMA2'| >>> +-----+ +-----+ | +-----+ >>> | >>> | >>> | >>> | >>> +-----+ +-----+ | >>> |MAG1 | |MAG2 | | >>> +-----+ +-----+ | >>> | >>> | >>> A | B >>> ------------------------------+------------------------------- >>> C >>> >>> >>> +-----+ +-----+ >>> |MAG1'| |MAG2'| >>> +-----+ +-----+ >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> -------------------------------------------------------------------------------- >> >> If people prefer to use administrative domain, we can replace all PMIPv6 domain in the proposed text with *administrative domain*, Welcome your bash,:-) >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Marco Liebsch" >> To: >> Cc: ; >> Sent: Wednesday, September 09, 2009 11:07 PM >> Subject: Re: [netext] [Netext] localized route optimization - roaming issue >> >> >> >>> Hi Raj, >>> >>> yes, agreed, that's why it has been proposed to add a section on this in >>> the PS. The picture >>> could be based on what I sent some mails ago. We're currently preparing >>> some text, but >>> I think it makes sense to discuss and agree on the text before it goes >>> to the PS draft. >>> >>> marco >>> >>> Basavaraj.Patil@nokia.com wrote: >>> >>>> Hi Marco, >>>> >>>> One of the issues that we got hung up at IETF75 during the LR discussion was >>>> on roaming. It would be good to have a clear description of the relationship >>>> between the MAG and LMA in the context of a PMIP6 domain especially when you >>>> consider home and visited network scenarios wherein the MAG/LMA entities are >>>> in different domains. >>>> >>>> The PMIP6 domain definition in RFC5213: >>>> " >>>> Proxy Mobile IPv6 domain refers to the network where the mobility >>>> management of a mobile node is handled using the Proxy Mobile IPv6 >>>> protocol as defined in this specification. The Proxy Mobile IPv6 >>>> domain includes local mobility anchors and mobile access gateways >>>> between which security associations can be set up and >>>> authorization for sending Proxy Binding Updates on behalf of the >>>> mobile nodes can be ensured. >>>> " >>>> >>>> does not have any references to home/visited network concepts. The only >>>> criteria for an entity (MAG/LMA) being considered being a part of the PMIP6 >>>> domain is the existence of a security association. It would be good to >>>> elaborate how this maps to the current discussion in LR. >>>> >>>> -Raj >>>> > From Marco.Liebsch@nw.neclab.eu Fri Sep 11 02:24:17 2009 Return-Path: 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 DB8CB3A68DA for ; Fri, 11 Sep 2009 02:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 8q9nP2LYnh3e for ; Fri, 11 Sep 2009 02:24:16 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 33A763A6833 for ; Fri, 11 Sep 2009 02:24:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 580F62C0012C6; Fri, 11 Sep 2009 11:24:52 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q80KX5eFBb2N; Fri, 11 Sep 2009 11:24:52 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id C50FE2C0002FE; Fri, 11 Sep 2009 11:24:31 +0200 (CEST) Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 11:24:31 +0200 Message-ID: <4AAA1750.7030405@nw.neclab.eu> Date: Fri, 11 Sep 2009 11:24:32 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Qin Wu References: <4AA7C4CE.1030305@nw.neclab.eu> <041f01ca3212$6881af10$260ca40a@china.huawei.com> <4AA8F7FA.3050805@nw.neclab.eu> <012301ca3286$cb1c5ac0$260ca40a@china.huawei.com> In-Reply-To: <012301ca3286$cb1c5ac0$260ca40a@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Sep 2009 09:24:31.0641 (UTC) FILETIME=[AB3C4090:01CA32C1] Cc: netext@ietf.org, Mohana.Jeyatharan@sg.panasonic.com, Basavaraj.Patil@nokia.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 09:24:17 -0000 Hi Qin, please see inline. Qin Wu wrote: > Hi, Marco and all: > ----- Original Message ----- > From: "Marco Liebsch" > To: "Qin Wu" > Cc: ; ; > Sent: Thursday, September 10, 2009 8:58 PM > Subject: Re: [Netext] roaming issue-proposed text for roaming section > > > >> Hi Qin, >> >> thanks for proposing some text. I think it's a good starting point. >> Please see for a comment inline. >> >> marco >> >> Qin Wu wrote: >> >>> Hi, all: >>> Since folks has no objection to add a section to talk about roaming issues. I would like to propose >>> some texts based on roaming picture proposed by Marco. The proposed text is as follows: >>> " >>> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) can be distributed into different PMIPv6 domains. In order to support localized routing, it is required that MAGs to which MN and CN connect are within the same PMIPv6 domain and each MAG setup security relationship respectively with corresponding LMAs which maintain specific context to which MN and CN belong. >>> >> I am not sure if we can say that the two MAGs belong to the same PMIP >> domain, can we? Look at the picture: MAG1' and MAG2' (roaming case) >> belong to one PLMN (or administrative domain), I think that was the >> requirement we talked about some time ago. Now, MN is attached to MAG1' >> and registered with LMA1, whereas CN is attached to MAG2' and registered >> with LMA2 or LMA2'. MAG1' and LMA1 build one PMIP domain, MAG2' >> and LMA2/LMA2' build one PMIP domain. I don't think this implies that >> MAG1' and MAG2' are in the same PMIP domain. This also means that >> we cannot assume that MAG1 has an SA with LMA2/LMA2'. Hence, MN >> and CN are attached to different PMIPv6 domains. That's at least my view. >> > > [Qin]: I know your concerns. I think we have some misunderstanding on PMIPv6 domain or *administrative domain* > In my mind, *Administrative A, B,C* are really *PMIPv6 domain A, B,C* I understand respectively. In this way, we can see > 1.LMA1,LMA2,MAG1,MAG2 do not leave PMIPv6 domain A > 2. LMA2' does not leave PMIPv6 domain B > 3. MAG1',MAG2' do not leave PMIPv6 domain C. > Only MN and CN can roam within one PMIPv6 domain or roam over different PMIPv6 domain. whatever MN move around, MN still belong to the same PMIPv6 domain as LMA which maintains MN's context information. > > As regarding whether MAG1' and LMA1 build one PMIP domain, MAG2' and LMA2/LMA2' build one PMIP domain, > I have the same understanding as you before. But from the discussion in the ML, I have new understanding. > I don't understand why, as the PMIPv6 domain is clearly defined. Sri posted in the context of this discussion the definition which says inter alia "...From the protocol perspective, as long as there is a SA between the LMA and MAG, that defines the PMIPv6 domain..." So, according to my understanding, if a MAG-LMA combination supports network-based mobility for a node, this defines the PMIPv6 of the node. > In my opinion, MAG1' belongs to PMIPv6 domain C, when MN is attached to the MAG1', MN will be achcored to LMA1 in the PMIPv6 domain A(i.e., MN's home PMIPv6 domain) through MAG1' in the PMIPv6 domain C(i.e., one visited PMIPv6 domain). In this sense, MAG1' still belong to PMIPv6 domain C and MN and MN's LMA(i.e., LMA1) still belong to the PMIPv6 domain A. So it seems not reasonable to say we build one new PMIPv6 domain containing MAG1' and LMA1. > So my conclusion is PMIPv6 domain can be understand as PLMN, I see, hmm, so roaming seems to be moving between PMIPv6 domains in your understanding, right? I think we have different views here and may need more opinions. I think it's difficult to stick to PMIP domains only and not talk about administrative domains or PLMNs if folks want to discuss roaming cases for localized routing. marco > we can allow two different PMIPv6 domains are interconnected with each other, but we are not necessary to understand them as one big PMIPv6 domain. > > On the other hand, MAGs in one PMIPv6 domain can be attached by MN which belongs to the same PMIPv6 domain as these MAGs. > and MAGs in one PMIPv6 domain also can be attached by MN moving from another PMIPv6 domain, in other words MN and MAGs may belong to different PMIPv6 domains although MN communicates with LMAs through these MAGs. > So if MAGs does not leave one PMIPv6 domain, these MAGs can be understood to belong to this PMIPv6 domain. And these MAGs can be used to access LMAs by MNs which belong to different PMIPv6 domain. > > Does this make sense? > > > > > >>> It is not required that LMAs anchored by MN and CN are part of PMIPv6 domain as MAGs attached by MN and CN. MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or over different PMIPv6 domains(i.e., MN's visited domains). CN should stay with MN within the same PMIPv6 domain. Figure x shows PMIPv6 roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 domain. In this figure, four PMIPv6 roaming cases need to be taken into account. >>> Roaming case 1: >>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located in the same PMIPv6 domain A as described in the figure 2. >>> Roaming case 2: >>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B. >>> Roaming case 3: >>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A >>> Roaming case 4: >>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is located in the PMIPv6 domain B >>> >>> " >>> >>> >>> -------------------------------------------------------------------------------- >>> >>> >>> >>> >>>> | >>>> +-----+ +-----+ | +-----+ >>>> |LMA1 | |LMA2 | | |LMA2'| >>>> +-----+ +-----+ | +-----+ >>>> | >>>> | >>>> | >>>> | >>>> +-----+ +-----+ | >>>> |MAG1 | |MAG2 | | >>>> +-----+ +-----+ | >>>> | >>>> | >>>> A | B >>>> ------------------------------+------------------------------- >>>> C >>>> >>>> >>>> +-----+ +-----+ >>>> |MAG1'| |MAG2'| >>>> +-----+ +-----+ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> -------------------------------------------------------------------------------- >>> >>> If people prefer to use administrative domain, we can replace all PMIPv6 domain in the proposed text with *administrative domain*, Welcome your bash,:-) >>> Regards! >>> -Qin >>> ----- Original Message ----- >>> From: "Marco Liebsch" >>> To: >>> Cc: ; >>> Sent: Wednesday, September 09, 2009 11:07 PM >>> Subject: Re: [netext] [Netext] localized route optimization - roaming issue >>> >>> >>> >>> >>>> Hi Raj, >>>> >>>> yes, agreed, that's why it has been proposed to add a section on this in >>>> the PS. The picture >>>> could be based on what I sent some mails ago. We're currently preparing >>>> some text, but >>>> I think it makes sense to discuss and agree on the text before it goes >>>> to the PS draft. >>>> >>>> marco >>>> >>>> Basavaraj.Patil@nokia.com wrote: >>>> >>>> >>>>> Hi Marco, >>>>> >>>>> One of the issues that we got hung up at IETF75 during the LR discussion was >>>>> on roaming. It would be good to have a clear description of the relationship >>>>> between the MAG and LMA in the context of a PMIP6 domain especially when you >>>>> consider home and visited network scenarios wherein the MAG/LMA entities are >>>>> in different domains. >>>>> >>>>> The PMIP6 domain definition in RFC5213: >>>>> " >>>>> Proxy Mobile IPv6 domain refers to the network where the mobility >>>>> management of a mobile node is handled using the Proxy Mobile IPv6 >>>>> protocol as defined in this specification. The Proxy Mobile IPv6 >>>>> domain includes local mobility anchors and mobile access gateways >>>>> between which security associations can be set up and >>>>> authorization for sending Proxy Binding Updates on behalf of the >>>>> mobile nodes can be ensured. >>>>> " >>>>> >>>>> does not have any references to home/visited network concepts. The only >>>>> criteria for an entity (MAG/LMA) being considered being a part of the PMIP6 >>>>> domain is the existence of a security association. It would be good to >>>>> elaborate how this maps to the current discussion in LR. >>>>> >>>>> -Raj >>>>> >>>>> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From sunseawq@huawei.com Fri Sep 11 03:08:54 2009 Return-Path: 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 92CC13A6950 for ; Fri, 11 Sep 2009 03:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.434 X-Spam-Level: X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_63=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] 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 6ZM5snrmN0tX for ; Fri, 11 Sep 2009 03:08:53 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4EE043A68F5 for ; Fri, 11 Sep 2009 03:08:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPS00MVOXIRCK@szxga04-in.huawei.com> for netext@ietf.org; Fri, 11 Sep 2009 18:08:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPS00AZ4XIR0O@szxga04-in.huawei.com> for netext@ietf.org; Fri, 11 Sep 2009 18:08:51 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPS00FMBXIR20@szxml04-in.huawei.com> for netext@ietf.org; Fri, 11 Sep 2009 18:08:51 +0800 (CST) Date: Fri, 11 Sep 2009 18:08:50 +0800 From: Qin Wu To: Marco Liebsch Message-id: <020101ca32c7$dc220c20$260ca40a@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: <4AA7C4CE.1030305@nw.neclab.eu> <041f01ca3212$6881af10$260ca40a@china.huawei.com> <4AA8F7FA.3050805@nw.neclab.eu> <012301ca3286$cb1c5ac0$260ca40a@china.huawei.com> <4AAA1750.7030405@nw.neclab.eu> Cc: netext@ietf.org, Mohana.Jeyatharan@sg.panasonic.com, Basavaraj.Patil@nokia.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 10:08:54 -0000 Hi, Marco: ----- Original Message ----- From: "Marco Liebsch" To: "Qin Wu" Cc: ; ; Sent: Friday, September 11, 2009 5:24 PM Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section > Hi Qin, > > please see inline. > > Qin Wu wrote: >> Hi, Marco and all: >> ----- Original Message ----- >> From: "Marco Liebsch" >> To: "Qin Wu" >> Cc: ; ; >> Sent: Thursday, September 10, 2009 8:58 PM >> Subject: Re: [Netext] roaming issue-proposed text for roaming section >> >> >> >>> Hi Qin, >>> >>> thanks for proposing some text. I think it's a good starting point. >>> Please see for a comment inline. >>> >>> marco >>> >>> Qin Wu wrote: >>> >>>> Hi, all: >>>> Since folks has no objection to add a section to talk about roaming issues. I would like to propose >>>> some texts based on roaming picture proposed by Marco. The proposed text is as follows: >>>> " >>>> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) can be distributed into different PMIPv6 domains. In order to support localized routing, it is required that MAGs to which MN and CN connect are within the same PMIPv6 domain and each MAG setup security relationship respectively with corresponding LMAs which maintain specific context to which MN and CN belong. >>>> >>> I am not sure if we can say that the two MAGs belong to the same PMIP >>> domain, can we? Look at the picture: MAG1' and MAG2' (roaming case) >>> belong to one PLMN (or administrative domain), I think that was the >>> requirement we talked about some time ago. Now, MN is attached to MAG1' >>> and registered with LMA1, whereas CN is attached to MAG2' and registered >>> with LMA2 or LMA2'. MAG1' and LMA1 build one PMIP domain, MAG2' >>> and LMA2/LMA2' build one PMIP domain. I don't think this implies that >>> MAG1' and MAG2' are in the same PMIP domain. This also means that >>> we cannot assume that MAG1 has an SA with LMA2/LMA2'. Hence, MN >>> and CN are attached to different PMIPv6 domains. That's at least my view. >>> >> >> [Qin]: I know your concerns. I think we have some misunderstanding on PMIPv6 domain or *administrative domain* >> In my mind, *Administrative A, B,C* are really *PMIPv6 domain A, B,C* I understand respectively. In this way, we can see >> 1.LMA1,LMA2,MAG1,MAG2 do not leave PMIPv6 domain A >> 2. LMA2' does not leave PMIPv6 domain B >> 3. MAG1',MAG2' do not leave PMIPv6 domain C. >> Only MN and CN can roam within one PMIPv6 domain or roam over different PMIPv6 domain. whatever MN move around, MN still belong to the same PMIPv6 domain as LMA which maintains MN's context information. >> >> As regarding whether MAG1' and LMA1 build one PMIP domain, MAG2' and LMA2/LMA2' build one PMIP domain, >> I have the same understanding as you before. But from the discussion in the ML, I have new understanding. >> > I don't understand why, as the PMIPv6 domain is clearly defined. Sri > posted in the context of > this discussion the definition which says inter alia "...From the > protocol perspective, as long as > there is a SA between the LMA and MAG, that defines the PMIPv6 > domain..." [Qin]: There is no confusion here. In my understanding, the PMIPv6 domain mentioned above is LMA's PMIPv6 domain. Because MN does not change LMA but MN can frequently change its MAG when inter-MAG handover occurs.MAG may belong to the same PMIPv6 domain as LMA, also MAG may belong to another PMIPv6 domain . So It does not matter MAG is located in the MN's home PMIPv6 domain to which MN's LMA belong or MAG is located in the MN's visited PMIPv6 domain to which MN's LMA does not belong. In this sense, wherever MN moves around, MN does not change its home PMIPv6 domain and LMA. Am I right? >So, according to > my understanding, if a MAG-LMA combination supports network-based > mobility for a node, > this defines the PMIPv6 of the node. [Qin]: In my understanding, each PMIPv6 domain has its boundary. otherwise, we can say there are millions of PMIPv6 domains. Because we can find millions of MAG-LMA combinations. > >> In my opinion, MAG1' belongs to PMIPv6 domain C, when MN is attached to the MAG1', MN will be achcored to LMA1 in the PMIPv6 domain A(i.e., MN's home PMIPv6 domain) through MAG1' in the PMIPv6 domain C(i.e., one visited PMIPv6 domain). In this sense, MAG1' still belong to PMIPv6 domain C and MN and MN's LMA(i.e., LMA1) still belong to the PMIPv6 domain A. So it seems not reasonable to say we build one new PMIPv6 domain containing MAG1' and LMA1. >> So my conclusion is PMIPv6 domain can be understand as PLMN, > I see, hmm, so roaming seems to be moving between PMIPv6 domains in your > understanding, right? [Qin] Yes, but you can call this kind of PMIPv6 domain as *administrative domain*. > I think we have different views here and may need more opinions. [Qin]: Agree. We need more opinions on this. > I think it's difficult to stick to PMIP domains only and not talk about > administrative domains or PLMNs > if folks want to discuss roaming cases for localized routing. [Qin]: I am not sure whether it is necessary to define new terminology. But I agree using administrative domains helps us well understand romaing issues. > marco > >> we can allow two different PMIPv6 domains are interconnected with each other, but we are not necessary to understand them as one big PMIPv6 domain. >> >> On the other hand, MAGs in one PMIPv6 domain can be attached by MN which belongs to the same PMIPv6 domain as these MAGs. >> and MAGs in one PMIPv6 domain also can be attached by MN moving from another PMIPv6 domain, in other words MN and MAGs may belong to different PMIPv6 domains although MN communicates with LMAs through these MAGs. >> So if MAGs does not leave one PMIPv6 domain, these MAGs can be understood to belong to this PMIPv6 domain. And these MAGs can be used to access LMAs by MNs which belong to different PMIPv6 domain. >> >> Does this make sense? >> >> >> >> >> >>>> It is not required that LMAs anchored by MN and CN are part of PMIPv6 domain as MAGs attached by MN and CN. MN is allowed to roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is located) or over different PMIPv6 domains(i.e., MN's visited domains). CN should stay with MN within the same PMIPv6 domain. Figure x shows PMIPv6 roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 domain. In this figure, four PMIPv6 roaming cases need to be taken into account. >>>> Roaming case 1: >>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located in the same PMIPv6 domain A as described in the figure 2. >>>> Roaming case 2: >>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B. >>>> Roaming case 3: >>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A >>>> Roaming case 4: >>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is located in the PMIPv6 domain B >>>> >>>> " >>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> >>>> >>>> >>>>> | >>>>> +-----+ +-----+ | +-----+ >>>>> |LMA1 | |LMA2 | | |LMA2'| >>>>> +-----+ +-----+ | +-----+ >>>>> | >>>>> | >>>>> | >>>>> | >>>>> +-----+ +-----+ | >>>>> |MAG1 | |MAG2 | | >>>>> +-----+ +-----+ | >>>>> | >>>>> | >>>>> A | B >>>>> ------------------------------+------------------------------- >>>>> C >>>>> >>>>> >>>>> +-----+ +-----+ >>>>> |MAG1'| |MAG2'| >>>>> +-----+ +-----+ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> If people prefer to use administrative domain, we can replace all PMIPv6 domain in the proposed text with *administrative domain*, Welcome your bash,:-) >>>> Regards! >>>> -Qin >>>> ----- Original Message ----- >>>> From: "Marco Liebsch" >>>> To: >>>> Cc: ; >>>> Sent: Wednesday, September 09, 2009 11:07 PM >>>> Subject: Re: [netext] [Netext] localized route optimization - roaming issue >>>> >>>> >>>> >>>> >>>>> Hi Raj, >>>>> >>>>> yes, agreed, that's why it has been proposed to add a section on this in >>>>> the PS. The picture >>>>> could be based on what I sent some mails ago. We're currently preparing >>>>> some text, but >>>>> I think it makes sense to discuss and agree on the text before it goes >>>>> to the PS draft. >>>>> >>>>> marco >>>>> >>>>> Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> >>>>>> Hi Marco, >>>>>> >>>>>> One of the issues that we got hung up at IETF75 during the LR discussion was >>>>>> on roaming. It would be good to have a clear description of the relationship >>>>>> between the MAG and LMA in the context of a PMIP6 domain especially when you >>>>>> consider home and visited network scenarios wherein the MAG/LMA entities are >>>>>> in different domains. >>>>>> >>>>>> The PMIP6 domain definition in RFC5213: >>>>>> " >>>>>> Proxy Mobile IPv6 domain refers to the network where the mobility >>>>>> management of a mobile node is handled using the Proxy Mobile IPv6 >>>>>> protocol as defined in this specification. The Proxy Mobile IPv6 >>>>>> domain includes local mobility anchors and mobile access gateways >>>>>> between which security associations can be set up and >>>>>> authorization for sending Proxy Binding Updates on behalf of the >>>>>> mobile nodes can be ensured. >>>>>> " >>>>>> >>>>>> does not have any references to home/visited network concepts. The only >>>>>> criteria for an entity (MAG/LMA) being considered being a part of the PMIP6 >>>>>> domain is the existence of a security association. It would be good to >>>>>> elaborate how this maps to the current discussion in LR. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > From jouni.nospam@gmail.com Tue Sep 15 00:23:36 2009 Return-Path: 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 F315A3A6861 for ; Tue, 15 Sep 2009 00:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 44+6dgJ6p7PP for ; Tue, 15 Sep 2009 00:23:35 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id F275F3A67F4 for ; Tue, 15 Sep 2009 00:23:34 -0700 (PDT) Received: by ewy3 with SMTP id 3so3530368ewy.42 for ; Tue, 15 Sep 2009 00:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :references:x-mailer; bh=4wXLdvBVuGb6HM2l6dah0XGXWmw4rvElfsEU72/bxhc=; b=ZqEUg29s+NtGR47oUbjbLsLLtzhqaa0jASmvtmkL3H3USiFy6/dim7DWJ3GK5P8IOw hB7Alc7wJgqo8bMlxGSaehFvXntWe001gkDRqA1yBdCIWZBkKLoS+yJHnS59+ceQdDmB vfE0XathXcY1yNP+qRPbdPx9Ft7lbUMw9gKbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:references:x-mailer; b=hv3DRNhnpw9x3vkO7pd/aImBeDQWQ66kz2krdazWGH+JCtqiXhIs1gnqKX8Zf6bbTA XxRolvYmz4fD2/ChIBXqk3AIut0gLWAV3MxwfxUFPD+sOTMqqVbinc6/jMOJUHxhR+32 YP73qUHn+wn4rdLvVEJEhs7NQbIO9xuApHHYM= Received: by 10.211.160.4 with SMTP id m4mr7949991ebo.24.1252999456358; Tue, 15 Sep 2009 00:24:16 -0700 (PDT) Received: from ?10.254.0.79? ([192.100.123.77]) by mx.google.com with ESMTPS id 5sm4989410eyh.35.2009.09.15.00.24.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Sep 2009 00:24:16 -0700 (PDT) Message-Id: From: jouni korhonen To: netext@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Sep 2009 10:24:12 +0300 References: <20090909225906.CE4253A6918@core3.amsl.com> X-Mailer: Apple Mail (2.936) Subject: [netext] FW: New Version Notification for draft-korhonen-netext-redirect-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 07:23:36 -0000 FYI We submitted an updated version of the Runtime LMA Assignment I-D a while ago. This revision should address the comments we received in Stockholm or at least add the basis for further work on those areas. Cheers, Jouni Begin forwarded message: > From: IETF I-D Submission Tool > Date: September 10, 2009 1:59:06 AM GMT+03:00 > To: jouni.nospam@gmail.com > Cc: sri.gundavelli@cisco.com,yokota@kddilabs.jp > Subject: New Version Notification for draft-korhonen-netext- > redirect-03 > > > A new version of I-D, draft-korhonen-netext-redirect-03.txt has been > successfuly submitted by Jouni Korhonen and posted to the IETF > repository. > > Filename: draft-korhonen-netext-redirect > Revision: 03 > Title: Runtime LMA Assignment Support for Proxy Mobile IPv6 > Creation_date: 2009-09-10 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > This document describes a redirect functionality and corresponding > mobility options for Proxy Mobile IPv6. The redirect functionality > allows a dynamic runtime assignment of a Local Mobility Anchor and > redirecting the mobility session to the assigned Local Mobility > Anchor. > > > > The IETF Secretariat. > > From Mohana.Jeyatharan@sg.panasonic.com Tue Sep 15 00:49:06 2009 Return-Path: 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 93DB23A6A8C for ; Tue, 15 Sep 2009 00:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.56 X-Spam-Level: * X-Spam-Status: No, score=1.56 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6] 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 I102oGdaf3vO for ; Tue, 15 Sep 2009 00:49:05 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 28E9E3A69D3 for ; Tue, 15 Sep 2009 00:49:02 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n8F7nU2U011596; Tue, 15 Sep 2009 16:49:30 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id n8F7nRu04070; Tue, 15 Sep 2009 16:49:28 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Sep 2009 15:45:54 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> In-Reply-To: <041f01ca3212$6881af10$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netext] roaming issue-proposed text for roaming section Thread-Index: AcoyEfP8iOZQj0q/Q7utnro8YcQtyQDxHTog From: "Mohana Jeyatharan" To: "Qin Wu" , "Marco Liebsch" , Cc: netext@ietf.org Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 07:49:06 -0000 Hi Qin, Sorry wanted to comment on your text, but here are some comments. =20 I think we should stick to the definition of PMIPv6 domain as in RFC 5213 and not change it. That is, as long as the MAG-LMA tunnel can be created, it is considered as one PMIPv6 domain of MN. While being attached to such PMIPv6 domain, the MN may change administrative domain. i.e. move from home domain to another administrative domain (foreign domain). Now, please see some comments on the text proposed. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Thursday, September 10, 2009 8:30 PM > To: Marco Liebsch; Basavaraj.Patil@nokia.com > Cc: netext@ietf.org; Mohana Jeyatharan > Subject: Re: [Netext] roaming issue-proposed text for roaming section >=20 > Hi, all: > Since folks has no objection to add a section to talk about roaming issues. > I would like to propose > some texts based on roaming picture proposed by Marco. The proposed text > is as follows: > " > In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) [Mohana: tied to a given MN]can be > distributed into different PMIPv6 domains[Mohana: adminsitrative domain. Example LMA placed in one administrative domain and MAG placed in another administrative domain]. In order to support localized > routing, it is required that MAGs to which MN and CN connect are within > the same PMIPv6 domain [Mohana: within the same administrative domain.]and each MAG setup security relationship > respectively with corresponding LMAs which maintain specific context to > which MN and CN belong. It is not required that LMAs anchored by MN and CN > are part of PMIPv6 domain [Mohana:administrative domain] as MAGs attached by MN and CN. MN is allowed to > roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is > located) or over different PMIPv6 domains(i.e., MN's visited domains). [Mohana: I would say MN is allowed to roam from home adminsitartive domain to visted administrative domain all tied to a single PMIPv6 domain of Mn] CN > should stay with MN within the same PMIPv6 domain [Mohana: administrative domain]. =20 Figure x shows PMIPv6 > roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 > domain. In this figure, four PMIPv6 roaming cases need to be taken into > account. > Roaming case 1: > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located > in the same PMIPv6 domain A as described in the figure 2. > Roaming case 2: > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same > PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B. > Roaming case 3: > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A > Roaming case 4: > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while > MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is > located in the PMIPv6 domain B >=20 > " [Mohana] I think, where description is made regarding MN and CN placement in a certain PMIPv6 domain, it is better to say in the same administrative domain. It is just that MN is roaming in its PMIPv6 domain and CN is roaming in its PMIPv6 domain, and local MAG routing canbe performed when MN's MAG and CN's MAG are the same or are placed in the same adminstrative domain. I think such things need to be captued.=20 >=20 > ------------------------------------------------------------------------ -- > ------ >=20 >=20 > > > > > > | > > +-----+ +-----+ | +-----+ > > |LMA1 | |LMA2 | | |LMA2'| > > +-----+ +-----+ | +-----+ > > | > > | > > | > > | > > +-----+ +-----+ | > > |MAG1 | |MAG2 | | > > +-----+ +-----+ | > > | > > | > > A | B > > ------------------------------+------------------------------- > > C > > > > > > +-----+ +-----+ > > |MAG1'| |MAG2'| > > +-----+ +-----+ > > > > > > > > > > > > > > >=20 >=20 > ------------------------------------------------------------------------ -- > ------ >=20 > If people prefer to use administrative domain, we can replace all PMIPv6 > domain in the proposed text with *administrative domain*, Welcome your > bash,:-) > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: > Cc: ; > Sent: Wednesday, September 09, 2009 11:07 PM > Subject: Re: [netext] [Netext] localized route optimization - roaming > issue >=20 >=20 > > Hi Raj, > > > > yes, agreed, that's why it has been proposed to add a section on this in > > the PS. The picture > > could be based on what I sent some mails ago. We're currently preparing > > some text, but > > I think it makes sense to discuss and agree on the text before it goes > > to the PS draft. > > > > marco > > > > Basavaraj.Patil@nokia.com wrote: > >> Hi Marco, > >> > >> One of the issues that we got hung up at IETF75 during the LR > discussion was > >> on roaming. It would be good to have a clear description of the > relationship > >> between the MAG and LMA in the context of a PMIP6 domain especially > when you > >> consider home and visited network scenarios wherein the MAG/LMA > entities are > >> in different domains. > >> > >> The PMIP6 domain definition in RFC5213: > >> " > >> Proxy Mobile IPv6 domain refers to the network where the mobility > >> management of a mobile node is handled using the Proxy Mobile > IPv6 > >> protocol as defined in this specification. The Proxy Mobile IPv6 > >> domain includes local mobility anchors and mobile access gateways > >> between which security associations can be set up and > >> authorization for sending Proxy Binding Updates on behalf of the > >> mobile nodes can be ensured. > >> " > >> > >> does not have any references to home/visited network concepts. The only > >> criteria for an entity (MAG/LMA) being considered being a part of the > PMIP6 > >> domain is the existence of a security association. It would be good to > >> elaborate how this maps to the current discussion in LR. > >> > >> -Raj From sunseawq@huawei.com Tue Sep 15 01:24:40 2009 Return-Path: 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 4C51D3A68AB for ; Tue, 15 Sep 2009 01:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.158 X-Spam-Level: X-Spam-Status: No, score=-0.158 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 iYQ9M+tD9gwV for ; Tue, 15 Sep 2009 01:24:39 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2AFB43A659C for ; Tue, 15 Sep 2009 01:23:31 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ00009U78KL0@szxga02-in.huawei.com> for netext@ietf.org; Tue, 15 Sep 2009 16:21:56 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ0006YB78KUV@szxga02-in.huawei.com> for netext@ietf.org; Tue, 15 Sep 2009 16:21:56 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ000IKA78J6J@szxml06-in.huawei.com> for netext@ietf.org; Tue, 15 Sep 2009 16:21:56 +0800 (CST) Date: Tue, 15 Sep 2009 16:21:55 +0800 From: Qin Wu To: Mohana Jeyatharan , Marco Liebsch , Basavaraj.Patil@nokia.com Message-id: <03d101ca35dd$9663d510$260ca40a@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: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> Cc: netext@ietf.org Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 08:24:40 -0000 Hi, Mohana: Thank for your reply. ----- Original Message ----- From: "Mohana Jeyatharan" To: "Qin Wu" ; "Marco Liebsch" ; Cc: Sent: Tuesday, September 15, 2009 3:45 PM Subject: RE: [Netext] roaming issue-proposed text for roaming section Hi Qin, Sorry wanted to comment on your text, but here are some comments. I think we should stick to the definition of PMIPv6 domain as in RFC 5213 and not change it. That is, as long as the MAG-LMA tunnel can be created, it is considered as one PMIPv6 domain of MN. [Qin]: you are right, wherever MN moves around, MN does not change the PMIPv6 domain to which MN belongs, i.e., MN's home PMIPv6 domain. While being attached to such PMIPv6 domain, the MN may change administrative domain. i.e. move from home domain to another administrative domain (foreign domain). [Qin]: Another administrative domain you mentioned above can be viewed as MN's visited PMIPv6 domain. that is to say, although MN changes from one visited PMIPv6 domain to another, MN does not change its home PMIPv6 domain, does this sounds reasonable? Anyway, you can stick to use administrative to describe roaming if you like. Now, please see some comments on the text proposed. BR, Mohana > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Thursday, September 10, 2009 8:30 PM > To: Marco Liebsch; Basavaraj.Patil@nokia.com > Cc: netext@ietf.org; Mohana Jeyatharan > Subject: Re: [Netext] roaming issue-proposed text for roaming section > > Hi, all: > Since folks has no objection to add a section to talk about roaming issues. > I would like to propose > some texts based on roaming picture proposed by Marco. The proposed text > is as follows: > " > In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) [Mohana: tied to a given MN] [Qin]:Okay. can be > distributed into different PMIPv6 domains [Mohana: adminsitrative domain. Example LMA placed in one administrative domain and MAG placed in another administrative domain]. [Qin]: I think we have two choices to describe roaming: 1) define administrative domain 2) Separate PMIPv6 domains into PMIPv6 home domain and PMIPv6 visited domain Both can be used to describe roaming, in my mind. >In order to support localized > routing, it is required that MAGs to which MN and CN connect are within > the same PMIPv6 domain [Mohana: within the same administrative domain.]and each MAG setup security relationship > respectively with corresponding LMAs which maintain specific context to > which MN and CN belong. It is not required that LMAs anchored by MN and CN > are part of PMIPv6 domain [Mohana:administrative domain] as MAGs attached by MN and CN. MN is allowed to > roam within its PMIPv6 domain (i.e, MN's home domain in which MN's LMA is > located) or over different PMIPv6 domains(i.e., MN's visited domains). [Mohana: I would say MN is allowed to roam from home adminsitartive domain to visted administrative domain all tied to a single PMIPv6 domain of Mn] [Qin]: see above. CN > should stay with MN within the same PMIPv6 domain [Mohana: administrative domain]. Figure x shows PMIPv6 > roaming cases where MAGs attached by MN and CN belong to the same PMIPv6 > domain. In this figure, four PMIPv6 roaming cases need to be taken into > account. > Roaming case 1: > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are located > in the same PMIPv6 domain A as described in the figure 2. > Roaming case 2: > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located in the same > PMIPv6 domain A while CN's LMA(LMA2') is located in the PMIPv6 domain B. > Roaming case 3: > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A > Roaming case 4: > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C while > MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) is > located in the PMIPv6 domain B > > " [Mohana] I think, where description is made regarding MN and CN placement in a certain PMIPv6 domain, it is better to say in the same administrative domain. [Qin] I think for now some people support this, some not. It is just that MN is roaming in its PMIPv6 domain and CN is roaming in its PMIPv6 domain, and local MAG routing canbe performed when MN's MAG and CN's MAG are the same or are placed in the same adminstrative domain. I think such things need to be captued. [Qin] Right. > ------------------------------------------------------------------------ -- > ------ > > > > > > > > | > > +-----+ +-----+ | +-----+ > > |LMA1 | |LMA2 | | |LMA2'| > > +-----+ +-----+ | +-----+ > > | > > | > > | > > | > > +-----+ +-----+ | > > |MAG1 | |MAG2 | | > > +-----+ +-----+ | > > | > > | > > A | B > > ------------------------------+------------------------------- > > C > > > > > > +-----+ +-----+ > > |MAG1'| |MAG2'| > > +-----+ +-----+ > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ -- > ------ > > If people prefer to use administrative domain, we can replace all PMIPv6 > domain in the proposed text with *administrative domain*, Welcome your > bash,:-) > Regards! > -Qin > ----- Original Message ----- > From: "Marco Liebsch" > To: > Cc: ; > Sent: Wednesday, September 09, 2009 11:07 PM > Subject: Re: [netext] [Netext] localized route optimization - roaming > issue > > > > Hi Raj, > > > > yes, agreed, that's why it has been proposed to add a section on this in > > the PS. The picture > > could be based on what I sent some mails ago. We're currently preparing > > some text, but > > I think it makes sense to discuss and agree on the text before it goes > > to the PS draft. > > > > marco > > > > Basavaraj.Patil@nokia.com wrote: > >> Hi Marco, > >> > >> One of the issues that we got hung up at IETF75 during the LR > discussion was > >> on roaming. It would be good to have a clear description of the > relationship > >> between the MAG and LMA in the context of a PMIP6 domain especially > when you > >> consider home and visited network scenarios wherein the MAG/LMA > entities are > >> in different domains. > >> > >> The PMIP6 domain definition in RFC5213: > >> " > >> Proxy Mobile IPv6 domain refers to the network where the mobility > >> management of a mobile node is handled using the Proxy Mobile > IPv6 > >> protocol as defined in this specification. The Proxy Mobile IPv6 > >> domain includes local mobility anchors and mobile access gateways > >> between which security associations can be set up and > >> authorization for sending Proxy Binding Updates on behalf of the > >> mobile nodes can be ensured. > >> " > >> > >> does not have any references to home/visited network concepts. The only > >> criteria for an entity (MAG/LMA) being considered being a part of the > PMIP6 > >> domain is the existence of a security association. It would be good to > >> elaborate how this maps to the current discussion in LR. > >> > >> -Raj From w52006@huawei.com Tue Sep 15 01:36:58 2009 Return-Path: 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 74E503A67F3 for ; Tue, 15 Sep 2009 01:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 K7+ExX+RI7k7 for ; Tue, 15 Sep 2009 01:36:57 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 95D673A67B5 for ; Tue, 15 Sep 2009 01:36:57 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ0000Q07SLL0@szxga02-in.huawei.com> for netext@ietf.org; Tue, 15 Sep 2009 16:33:57 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ0006457SLUV@szxga02-in.huawei.com> for netext@ietf.org; Tue, 15 Sep 2009 16:33:57 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ000IMN7SL6J@szxml06-in.huawei.com> for netext@ietf.org; Tue, 15 Sep 2009 16:33:57 +0800 (CST) Date: Tue, 15 Sep 2009 16:33:56 +0800 From: Yungui Wang In-reply-to: To: 'jouni korhonen' Message-id: <000001ca35df$44476830$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco11aQLyL3aLeqZQyiGWwYjY6rLQAABXoLQ Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 08:36:58 -0000 Hello Jouni It is observed that the assigned r2LMA would be stored/updated into the MN's profile on the policy store. May I know when it happens and who does? B.R. Yungui > -----Original Message----- > From: netext-bounces@ietf.org > [mailto:netext-bounces@ietf.org] On Behalf Of jouni korhonen > Sent: Tuesday, September 15, 2009 3:24 PM > To: netext@ietf.org > Subject: [netext] FW: New Version Notification > fordraft-korhonen-netext-redirect-03 > > FYI > > We submitted an updated version of the Runtime LMA Assignment I-D a > while ago. This revision should address the comments we received in > Stockholm or at least add the basis for further work on those areas. > > Cheers, > Jouni > > > > Begin forwarded message: > > > From: IETF I-D Submission Tool > > Date: September 10, 2009 1:59:06 AM GMT+03:00 > > To: jouni.nospam@gmail.com > > Cc: sri.gundavelli@cisco.com,yokota@kddilabs.jp > > Subject: New Version Notification for draft-korhonen-netext- > > redirect-03 > > > > > > A new version of I-D, draft-korhonen-netext-redirect-03.txt > has been > > successfuly submitted by Jouni Korhonen and posted to the IETF > > repository. > > > > Filename: draft-korhonen-netext-redirect > > Revision: 03 > > Title: Runtime LMA Assignment Support for > Proxy Mobile IPv6 > > Creation_date: 2009-09-10 > > WG ID: Independent Submission > > Number_of_pages: 23 > > > > Abstract: > > This document describes a redirect functionality and corresponding > > mobility options for Proxy Mobile IPv6. The redirect functionality > > allows a dynamic runtime assignment of a Local Mobility Anchor and > > redirecting the mobility session to the assigned Local Mobility > > Anchor. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From jouni.nospam@gmail.com Tue Sep 15 03:10:23 2009 Return-Path: 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 11BA13A67B6 for ; Tue, 15 Sep 2009 03:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 5lISxeR+aECH for ; Tue, 15 Sep 2009 03:10:21 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 6A93C3A672E for ; Tue, 15 Sep 2009 03:10:21 -0700 (PDT) Received: by ewy3 with SMTP id 3so3696597ewy.42 for ; Tue, 15 Sep 2009 03:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=7LSx+ukJJreVyCx60xwmptC+bc7bUgCBvz0QbARsChg=; b=j0vDHkWLQ/NOWSZEIvUz8gaDYqFYL7/CNm9grtZO9lai4TAiNXZN/VqVvNFpTB3F38 AsDmIlwLiuCCPwGqFrUVlpoUx96QnSr9llp0wqDQmZuymYQ1Aah/41Jop+90TRqwFeEe J1T12wRO4OBu3pS4ipD7HwAtaS9/XYi/IBMNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=xxhtPB/sJ9B1dQKZkEQEGRhzXiW1e7bdWh1AW76IEm+UuE7YMSNl0IR3BrSDSZdVda osZIq+vzNggULD7JADX5TdmTTjfQwoWnGZEzPBUnD/PJMpkEDoFhoW6DXb+Z55XtQ9z0 lgex+g/tG1avRCsn2CpMTMtMHCaqWlfu9iv8Q= Received: by 10.216.23.10 with SMTP id u10mr1224112weu.29.1253009464401; Tue, 15 Sep 2009 03:11:04 -0700 (PDT) Received: from ?10.254.0.79? ([192.100.123.77]) by mx.google.com with ESMTPS id 7sm1447178eyg.10.2009.09.15.03.11.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Sep 2009 03:11:04 -0700 (PDT) Message-Id: From: jouni korhonen To: w52006@huawei.com In-Reply-To: <000001ca35df$44476830$110ca40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 15 Sep 2009 13:11:00 +0300 References: <000001ca35df$44476830$110ca40a@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 10:10:23 -0000 Hi, On Sep 15, 2009, at 11:33 AM, Yungui Wang wrote: > Hello Jouni > > It is observed that the assigned r2LMA would be stored/updated into > the MN's > profile on the policy store. May I know when it happens and who does? Yes, r2LMA information would be stored into the policy profile. On the MAG side this would happen when the PBA containing the Redirect mobility option arrives. If the remote policy store needs to be updated, it would be done e.g. by r2LMA using the LMA-HAAA interface described in draft-ietf-dime-pmip6. I will add some text to the I-D regarding the policy profile update. Cheers, Jouni > > B.R. > Yungui > > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of jouni korhonen >> Sent: Tuesday, September 15, 2009 3:24 PM >> To: netext@ietf.org >> Subject: [netext] FW: New Version Notification >> fordraft-korhonen-netext-redirect-03 >> >> FYI >> >> We submitted an updated version of the Runtime LMA Assignment I-D a >> while ago. This revision should address the comments we received in >> Stockholm or at least add the basis for further work on those areas. >> >> Cheers, >> Jouni >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool >>> Date: September 10, 2009 1:59:06 AM GMT+03:00 >>> To: jouni.nospam@gmail.com >>> Cc: sri.gundavelli@cisco.com,yokota@kddilabs.jp >>> Subject: New Version Notification for draft-korhonen-netext- >>> redirect-03 >>> >>> >>> A new version of I-D, draft-korhonen-netext-redirect-03.txt >> has been >>> successfuly submitted by Jouni Korhonen and posted to the IETF >>> repository. >>> >>> Filename: draft-korhonen-netext-redirect >>> Revision: 03 >>> Title: Runtime LMA Assignment Support for >> Proxy Mobile IPv6 >>> Creation_date: 2009-09-10 >>> WG ID: Independent Submission >>> Number_of_pages: 23 >>> >>> Abstract: >>> This document describes a redirect functionality and corresponding >>> mobility options for Proxy Mobile IPv6. The redirect functionality >>> allows a dynamic runtime assignment of a Local Mobility Anchor and >>> redirecting the mobility session to the assigned Local Mobility >>> Anchor. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > From rkoodli@starentnetworks.com Tue Sep 15 09:28:23 2009 Return-Path: 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 3C48F28C106 for ; Tue, 15 Sep 2009 09:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3K9ilOuiza6o for ; Tue, 15 Sep 2009 09:28:21 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 9DA6A3A6A24 for ; Tue, 15 Sep 2009 09:28:21 -0700 (PDT) X-ASG-Debug-ID: 1253032145-05ea00560002-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 5E338EFC090 for ; Tue, 15 Sep 2009 12:29:05 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id AHlyzP2k97vwN8HG for ; Tue, 15 Sep 2009 12:29:05 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Sep 2009 12:27:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] [Netext] roaming issue-proposed text for roamingsection Date: Tue, 15 Sep 2009 12:26:58 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> In-Reply-To: <03d101ca35dd$9663d510$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [Netext] roaming issue-proposed text for roamingsection Thread-Index: Aco13eZpe9tnGQEmTa+HX32LBqfLTAAQh9SQ References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 15 Sep 2009 16:27:39.0353 (UTC) FILETIME=[7124AC90:01CA3621] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1253032145 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 16:28:23 -0000 =20 Hello folks, There has been some good discussion on this topic. Here's my take to converge and make progress. Please read all the point below before responding. 1. We do not deviate from the definition of a PMIPv6 domain as in RFC 5213. 2. No new definitions of "domain" 3. Roaming is simply defined as "access to the Internet when the MAG and LMA are in different provider domains" (We do not need to explain the underlying reasons IMO. "Access to the Internet" means the traditional connectivity via MAG and LMA as in RFC 5213; we should not delve into "service-specific" definitions here) 4. If an SA exists between a MAG and an LMA, there will be packet forwarding (i.e., MAG and LMA can be in different provider domains) 5. We need to state somewhere that for the roaming case, localized routing is subject to policy governing the service level agreements between the providers. This means that merely having an SA between a (visited) MAG and a (home) LMA does not translate to enabling localized routing when (at least) one of the MN's is roaming. What do you think? Regards, -Rajeev =20 > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu > Sent: Tuesday, September 15, 2009 1:22 AM > To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com > Cc: netext@ietf.org > Subject: Re: [netext] [Netext] roaming issue-proposed text=20 > for roamingsection >=20 > Hi, Mohana: > Thank for your reply. > ----- Original Message ----- > From: "Mohana Jeyatharan" > To: "Qin Wu" ; "Marco Liebsch"=20 > ; > Cc: > Sent: Tuesday, September 15, 2009 3:45 PM > Subject: RE: [Netext] roaming issue-proposed text for roaming section >=20 >=20 > Hi Qin, >=20 > Sorry wanted to comment on your text, but here are some comments. =20 >=20 > I think we should stick to the definition of PMIPv6 domain as in RFC > 5213 and not change it. That is, as long as the MAG-LMA tunnel can be > created, it is considered as one PMIPv6 domain of MN.=20 >=20 > [Qin]: you are right, wherever MN moves around, MN does not=20 > change the PMIPv6 domain to which MN belongs, > i.e., MN's home PMIPv6 domain. >=20 > While being attached to such PMIPv6 domain, the MN may change=20 > administrative domain. > i.e. move from home domain to another administrative domain (foreign > domain). =20 >=20 > [Qin]: Another administrative domain you mentioned above can=20 > be viewed as MN's visited PMIPv6 domain. > that is to say, although MN changes from one visited PMIPv6=20 > domain to another, MN does not change its home=20 > PMIPv6 domain, does this sounds reasonable? Anyway, you can=20 > stick to use administrative to describe roaming if > you like. >=20 > Now, please see some comments on the text proposed. >=20 >=20 > BR, > Mohana >=20 > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Thursday, September 10, 2009 8:30 PM > > To: Marco Liebsch; Basavaraj.Patil@nokia.com > > Cc: netext@ietf.org; Mohana Jeyatharan > > Subject: Re: [Netext] roaming issue-proposed text for=20 > roaming section > >=20 > > Hi, all: > > Since folks has no objection to add a section to talk about roaming > issues. > > I would like to propose > > some texts based on roaming picture proposed by Marco. The proposed > text > > is as follows: > > " > > In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) > [Mohana: tied to a given MN]=20 >=20 > [Qin]:Okay. >=20 > can be > > distributed into different PMIPv6 domains > [Mohana: adminsitrative > domain. Example LMA placed in one administrative domain and MAG placed > in another administrative domain].=20 >=20 > [Qin]: I think we have two choices to describe roaming: > 1) define administrative domain=20 > 2) Separate PMIPv6 domains into PMIPv6 home domain and PMIPv6=20 > visited domain > Both can be used to describe roaming, in my mind. >=20 > >In order to support localized > > routing, it is required that MAGs to which MN and CN connect are > within > > the same PMIPv6 domain [Mohana: within the same administrative > domain.]and each MAG setup security relationship > > respectively with corresponding LMAs which maintain specific context > to > > which MN and CN belong. It is not required that LMAs anchored by MN > and CN > > are part of PMIPv6 domain [Mohana:administrative domain] as MAGs > attached by MN and CN. MN is allowed to > > roam within its PMIPv6 domain (i.e, MN's home domain in=20 > which MN's LMA > is > > located) or over different PMIPv6 domains(i.e., MN's=20 > visited domains). >=20 > [Mohana: I would say MN is allowed to roam from home adminsitartive > domain to visted administrative domain all tied to a single PMIPv6 > domain of Mn]=20 >=20 > [Qin]: see above. >=20 > CN > > should stay with MN within the same PMIPv6 domain [Mohana: > administrative domain]. =20 >=20 >=20 > Figure x shows PMIPv6 > > roaming cases where MAGs attached by MN and CN belong to the same > PMIPv6 > > domain. In this figure, four PMIPv6 roaming cases need to be taken > into > > account. > > Roaming case 1: > > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are > located > > in the same PMIPv6 domain A as described in the figure 2. > > Roaming case 2: > > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located=20 > in the same > > PMIPv6 domain A while CN's LMA(LMA2') is located in the=20 > PMIPv6 domain > B. > > Roaming case 3: > > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C > while > > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A > > Roaming case 4: > > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C > while > > MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) > is > > located in the PMIPv6 domain B > >=20 > > " > [Mohana] I think, where description is made regarding MN and CN > placement in a certain PMIPv6 domain, it is better to say in the same > administrative domain. =20 >=20 > [Qin] I think for now some people support this, some not. >=20 > It is just that MN is roaming in its PMIPv6 domain and CN is=20 > roaming in its PMIPv6 domain, and local MAG routing > canbe performed when MN's MAG and CN's MAG are the same or=20 > are placed in > the same adminstrative domain. I think such things need to=20 > be captued.=20 >=20 > [Qin] Right. >=20 > > > -------------------------------------------------------------- > ---------- > -- > > ------ > >=20 > >=20 > > > > > > > > > | > > > +-----+ +-----+ | +-----+ > > > |LMA1 | |LMA2 | | |LMA2'| > > > +-----+ +-----+ | +-----+ > > > | > > > | > > > | > > > | > > > +-----+ +-----+ | > > > |MAG1 | |MAG2 | | > > > +-----+ +-----+ | > > > | > > > | > > > A | B > > > =20 > ------------------------------+------------------------------- > > > C > > > > > > > > > +-----+ +-----+ > > > |MAG1'| |MAG2'| > > > +-----+ +-----+ > > > > > > > > > > > > > > > > > > > > > > >=20 > >=20 > > > -------------------------------------------------------------- > ---------- > -- > > ------ > >=20 > > If people prefer to use administrative domain, we can replace all > PMIPv6 > > domain in the proposed text with *administrative domain*,=20 > Welcome your > > bash,:-) > > Regards! > > -Qin > > ----- Original Message ----- > > From: "Marco Liebsch" > > To: > > Cc: ; > > Sent: Wednesday, September 09, 2009 11:07 PM > > Subject: Re: [netext] [Netext] localized route optimization=20 > - roaming > > issue > >=20 > >=20 > > > Hi Raj, > > > > > > yes, agreed, that's why it has been proposed to add a section on > this in > > > the PS. The picture > > > could be based on what I sent some mails ago. We're currently > preparing > > > some text, but > > > I think it makes sense to discuss and agree on the text before it > goes > > > to the PS draft. > > > > > > marco > > > > > > Basavaraj.Patil@nokia.com wrote: > > >> Hi Marco, > > >> > > >> One of the issues that we got hung up at IETF75 during the LR > > discussion was > > >> on roaming. It would be good to have a clear description of the > > relationship > > >> between the MAG and LMA in the context of a PMIP6 domain=20 > especially > > when you > > >> consider home and visited network scenarios wherein the MAG/LMA > > entities are > > >> in different domains. > > >> > > >> The PMIP6 domain definition in RFC5213: > > >> " > > >> Proxy Mobile IPv6 domain refers to the network where the > mobility > > >> management of a mobile node is handled using the=20 > Proxy Mobile > > IPv6 > > >> protocol as defined in this specification. The=20 > Proxy Mobile > IPv6 > > >> domain includes local mobility anchors and mobile access > gateways > > >> between which security associations can be set up and > > >> authorization for sending Proxy Binding Updates on=20 > behalf of > the > > >> mobile nodes can be ensured. > > >> " > > >> > > >> does not have any references to home/visited network=20 > concepts. The > only > > >> criteria for an entity (MAG/LMA) being considered being a part of > the > > PMIP6 > > >> domain is the existence of a security association. It=20 > would be good > to > > >> elaborate how this maps to the current discussion in LR. > > >> > > >> -Raj > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20 From w52006@huawei.com Tue Sep 15 18:16:37 2009 Return-Path: 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 BBD083A6778 for ; Tue, 15 Sep 2009 18:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 g4yNlVYUzFYS for ; Tue, 15 Sep 2009 18:16:36 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id AF5693A635F for ; Tue, 15 Sep 2009 18:16:36 -0700 (PDT) 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 <0KQ10069QI8QLQ@szxga01-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 09:17:14 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1006JGI8Q90@szxga01-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 09:17:14 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ100CP8I8PCB@szxml06-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 09:17:13 +0800 (CST) Date: Wed, 16 Sep 2009 09:17:13 +0800 From: Yungui Wang In-reply-to: To: 'jouni korhonen' Message-id: <005a01ca366b$6c3bf630$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco17Pc8Tl8b0ZBkQ06InBDD1pThugAd1zgg Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 01:16:37 -0000 Hello That's okey. There are other two minor comments. 1, I think, the 'Redirect-Capability Mobility Option' is not essential. In my understanding, the common MIP/PMIP system has provided the general capability negotiation mechanism. That's, if there is an extended mobility option is not supported or identified, the receiver can just discard it silently. Isn't it? On the other side, even if the LMA doesn't return the 'Redirect Mobility Option', for implementation, the MAG which has enabled the redirection function may re-register the MN to another LMA when it receives a failed PBA, e.g. 130. Therefore, for simplification, the capability option can be removed. 2, I can't catch the logic of SA check described in the section 5.3.2. (at the 3th and 4th paragraph) In my understanding, if there is no SA between the MAG and the r2LMA, how can the r2LMA accept the PBU and create the mobility session at before? On the other hand, the SA check is necessary to another case described in 5.4. However, I don't see how the MAG does that. Are there some local policies on the MAG, or does the MAG check it according to the MN's profile downloaded from policy store, or ...? B.R. Yungui > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Tuesday, September 15, 2009 6:11 PM > To: w52006@huawei.com > Cc: netext@ietf.org > Subject: Re: [netext] FW: New Version Notification > fordraft-korhonen-netext-redirect-03 > > Hi, > > On Sep 15, 2009, at 11:33 AM, Yungui Wang wrote: > > > Hello Jouni > > > > It is observed that the assigned r2LMA would be > stored/updated into > > the MN's > > profile on the policy store. May I know when it happens and > who does? > > Yes, r2LMA information would be stored into the policy > profile. On the > MAG side this would happen when the PBA containing the Redirect > mobility option arrives. If the remote policy store needs to be > updated, it would be done e.g. by r2LMA using the LMA-HAAA interface > described in draft-ietf-dime-pmip6. > > I will add some text to the I-D regarding the policy profile update. > > Cheers, > Jouni > > > > > > B.R. > > Yungui > > > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org > >> [mailto:netext-bounces@ietf.org] On Behalf Of jouni korhonen > >> Sent: Tuesday, September 15, 2009 3:24 PM > >> To: netext@ietf.org > >> Subject: [netext] FW: New Version Notification > >> fordraft-korhonen-netext-redirect-03 > >> > >> FYI > >> > >> We submitted an updated version of the Runtime LMA Assignment I-D a > >> while ago. This revision should address the comments we received in > >> Stockholm or at least add the basis for further work on > those areas. > >> > >> Cheers, > >> Jouni > >> > >> > >> > >> Begin forwarded message: > >> > >>> From: IETF I-D Submission Tool > >>> Date: September 10, 2009 1:59:06 AM GMT+03:00 > >>> To: jouni.nospam@gmail.com > >>> Cc: sri.gundavelli@cisco.com,yokota@kddilabs.jp > >>> Subject: New Version Notification for draft-korhonen-netext- > >>> redirect-03 > >>> > >>> > >>> A new version of I-D, draft-korhonen-netext-redirect-03.txt > >> has been > >>> successfuly submitted by Jouni Korhonen and posted to the IETF > >>> repository. > >>> > >>> Filename: draft-korhonen-netext-redirect > >>> Revision: 03 > >>> Title: Runtime LMA Assignment Support for > >> Proxy Mobile IPv6 > >>> Creation_date: 2009-09-10 > >>> WG ID: Independent Submission > >>> Number_of_pages: 23 > >>> > >>> Abstract: > >>> This document describes a redirect functionality and corresponding > >>> mobility options for Proxy Mobile IPv6. The redirect > functionality > >>> allows a dynamic runtime assignment of a Local Mobility Anchor and > >>> redirecting the mobility session to the assigned Local Mobility > >>> Anchor. > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > > > From sunseawq@huawei.com Tue Sep 15 19:17:38 2009 Return-Path: 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 D54D03A6B69 for ; Tue, 15 Sep 2009 19:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=1.379, 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 NAQAlERzMHe8 for ; Tue, 15 Sep 2009 19:17:37 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3CBB73A6B50 for ; Tue, 15 Sep 2009 19:17:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1000D8L2LL5@szxga03-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 10:18:22 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1001Y9L2LR1@szxga03-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 10:18:21 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ1003TSL2G87@szxml04-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 10:18:21 +0800 (CST) Date: Wed, 16 Sep 2009 10:18:15 +0800 From: Qin Wu To: "Koodli, Rajeev" , netext@ietf.org Message-id: <00b101ca3673$f5ee6220$260ca40a@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: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 02:17:38 -0000 > 5. We need to state somewhere that for the roaming case, localized > routing is subject to policy governing the service level agreements > between the providers. This means that merely having an SA between a > (visited) MAG and a (home) LMA does not translate to enabling localized > routing when (at least) one of the MN's is roaming. [Qin]: So I think if policy governing the SLA can afffect localized routing directly, the MN's MAG and MN's LMA should belong to different domain. In this sense, if MN's MAG and MN's LMA are located in the same domain, SLA policy can not affect localize routing, am I right? Furthermore, besides SLA policy, I think there are other policies that also affect localized routing e.g., in roaming scenario even though MAG and LMA are located in the same domain, having SA between MAG and LMA does not mean localized routing can be performed, because use of local routing may be subject to accounting and routing policies relating to the mobile node, , therefore localized routing signaling between MAG and LMA is required to negotiate localized routing policy information and enable/disable localized routing. Am I right? > What do you think? > > Regards, > > -Rajeev > > > > > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu >> Sent: Tuesday, September 15, 2009 1:22 AM >> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com >> Cc: netext@ietf.org >> Subject: Re: [netext] [Netext] roaming issue-proposed text >> for roamingsection >> >> Hi, Mohana: >> Thank for your reply. >> ----- Original Message ----- >> From: "Mohana Jeyatharan" >> To: "Qin Wu" ; "Marco Liebsch" >> ; >> Cc: >> Sent: Tuesday, September 15, 2009 3:45 PM >> Subject: RE: [Netext] roaming issue-proposed text for roaming section >> >> >> Hi Qin, >> >> Sorry wanted to comment on your text, but here are some comments. >> >> I think we should stick to the definition of PMIPv6 domain as in RFC >> 5213 and not change it. That is, as long as the MAG-LMA tunnel can be >> created, it is considered as one PMIPv6 domain of MN. >> >> [Qin]: you are right, wherever MN moves around, MN does not >> change the PMIPv6 domain to which MN belongs, >> i.e., MN's home PMIPv6 domain. >> >> While being attached to such PMIPv6 domain, the MN may change >> administrative domain. >> i.e. move from home domain to another administrative domain (foreign >> domain). >> >> [Qin]: Another administrative domain you mentioned above can >> be viewed as MN's visited PMIPv6 domain. >> that is to say, although MN changes from one visited PMIPv6 >> domain to another, MN does not change its home >> PMIPv6 domain, does this sounds reasonable? Anyway, you can >> stick to use administrative to describe roaming if >> you like. >> >> Now, please see some comments on the text proposed. >> >> >> BR, >> Mohana >> >> > -----Original Message----- >> > From: Qin Wu [mailto:sunseawq@huawei.com] >> > Sent: Thursday, September 10, 2009 8:30 PM >> > To: Marco Liebsch; Basavaraj.Patil@nokia.com >> > Cc: netext@ietf.org; Mohana Jeyatharan >> > Subject: Re: [Netext] roaming issue-proposed text for >> roaming section >> > >> > Hi, all: >> > Since folks has no objection to add a section to talk about roaming >> issues. >> > I would like to propose >> > some texts based on roaming picture proposed by Marco. The proposed >> text >> > is as follows: >> > " >> > In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) >> [Mohana: tied to a given MN] >> >> [Qin]:Okay. >> >> can be >> > distributed into different PMIPv6 domains >> [Mohana: adminsitrative >> domain. Example LMA placed in one administrative domain and MAG placed >> in another administrative domain]. >> >> [Qin]: I think we have two choices to describe roaming: >> 1) define administrative domain >> 2) Separate PMIPv6 domains into PMIPv6 home domain and PMIPv6 >> visited domain >> Both can be used to describe roaming, in my mind. >> >> >In order to support localized >> > routing, it is required that MAGs to which MN and CN connect are >> within >> > the same PMIPv6 domain [Mohana: within the same administrative >> domain.]and each MAG setup security relationship >> > respectively with corresponding LMAs which maintain specific context >> to >> > which MN and CN belong. It is not required that LMAs anchored by MN >> and CN >> > are part of PMIPv6 domain [Mohana:administrative domain] as MAGs >> attached by MN and CN. MN is allowed to >> > roam within its PMIPv6 domain (i.e, MN's home domain in >> which MN's LMA >> is >> > located) or over different PMIPv6 domains(i.e., MN's >> visited domains). >> >> [Mohana: I would say MN is allowed to roam from home adminsitartive >> domain to visted administrative domain all tied to a single PMIPv6 >> domain of Mn] >> >> [Qin]: see above. >> >> CN >> > should stay with MN within the same PMIPv6 domain [Mohana: >> administrative domain]. >> >> >> Figure x shows PMIPv6 >> > roaming cases where MAGs attached by MN and CN belong to the same >> PMIPv6 >> > domain. In this figure, four PMIPv6 roaming cases need to be taken >> into >> > account. >> > Roaming case 1: >> > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are >> located >> > in the same PMIPv6 domain A as described in the figure 2. >> > Roaming case 2: >> > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located >> in the same >> > PMIPv6 domain A while CN's LMA(LMA2') is located in the >> PMIPv6 domain >> B. >> > Roaming case 3: >> > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C >> while >> > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A >> > Roaming case 4: >> > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C >> while >> > MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) >> is >> > located in the PMIPv6 domain B >> > >> > " >> [Mohana] I think, where description is made regarding MN and CN >> placement in a certain PMIPv6 domain, it is better to say in the same >> administrative domain. >> >> [Qin] I think for now some people support this, some not. >> >> It is just that MN is roaming in its PMIPv6 domain and CN is >> roaming in its PMIPv6 domain, and local MAG routing >> canbe performed when MN's MAG and CN's MAG are the same or >> are placed in >> the same adminstrative domain. I think such things need to >> be captued. >> >> [Qin] Right. >> >> > >> -------------------------------------------------------------- >> ---------- >> -- >> > ------ >> > >> > >> > > >> > > >> > > | >> > > +-----+ +-----+ | +-----+ >> > > |LMA1 | |LMA2 | | |LMA2'| >> > > +-----+ +-----+ | +-----+ >> > > | >> > > | >> > > | >> > > | >> > > +-----+ +-----+ | >> > > |MAG1 | |MAG2 | | >> > > +-----+ +-----+ | >> > > | >> > > | >> > > A | B >> > > >> ------------------------------+------------------------------- >> > > C >> > > >> > > >> > > +-----+ +-----+ >> > > |MAG1'| |MAG2'| >> > > +-----+ +-----+ >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> -------------------------------------------------------------- >> ---------- >> -- >> > ------ >> > >> > If people prefer to use administrative domain, we can replace all >> PMIPv6 >> > domain in the proposed text with *administrative domain*, >> Welcome your >> > bash,:-) >> > Regards! >> > -Qin >> > ----- Original Message ----- >> > From: "Marco Liebsch" >> > To: >> > Cc: ; >> > Sent: Wednesday, September 09, 2009 11:07 PM >> > Subject: Re: [netext] [Netext] localized route optimization >> - roaming >> > issue >> > >> > >> > > Hi Raj, >> > > >> > > yes, agreed, that's why it has been proposed to add a section on >> this in >> > > the PS. The picture >> > > could be based on what I sent some mails ago. We're currently >> preparing >> > > some text, but >> > > I think it makes sense to discuss and agree on the text before it >> goes >> > > to the PS draft. >> > > >> > > marco >> > > >> > > Basavaraj.Patil@nokia.com wrote: >> > >> Hi Marco, >> > >> >> > >> One of the issues that we got hung up at IETF75 during the LR >> > discussion was >> > >> on roaming. It would be good to have a clear description of the >> > relationship >> > >> between the MAG and LMA in the context of a PMIP6 domain >> especially >> > when you >> > >> consider home and visited network scenarios wherein the MAG/LMA >> > entities are >> > >> in different domains. >> > >> >> > >> The PMIP6 domain definition in RFC5213: >> > >> " >> > >> Proxy Mobile IPv6 domain refers to the network where the >> mobility >> > >> management of a mobile node is handled using the >> Proxy Mobile >> > IPv6 >> > >> protocol as defined in this specification. The >> Proxy Mobile >> IPv6 >> > >> domain includes local mobility anchors and mobile access >> gateways >> > >> between which security associations can be set up and >> > >> authorization for sending Proxy Binding Updates on >> behalf of >> the >> > >> mobile nodes can be ensured. >> > >> " >> > >> >> > >> does not have any references to home/visited network >> concepts. The >> only >> > >> criteria for an entity (MAG/LMA) being considered being a part of >> the >> > PMIP6 >> > >> domain is the existence of a security association. It >> would be good >> to >> > >> elaborate how this maps to the current discussion in LR. >> > >> >> > >> -Raj >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Tue Sep 15 19:40:26 2009 Return-Path: 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 686EF3A693D for ; Tue, 15 Sep 2009 19:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 QqrBN8bwIeoH for ; Tue, 15 Sep 2009 19:40:24 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 790093A685C for ; Tue, 15 Sep 2009 19:40:24 -0700 (PDT) X-ASG-Debug-ID: 1253068870-3c1a00000000-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 37A96EFC036 for ; Tue, 15 Sep 2009 22:41:10 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id U79NiUPvUFYUqqUn for ; Tue, 15 Sep 2009 22:41:10 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Sep 2009 22:39:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] [Netext] roaming issue-proposed text for roamingsection Date: Tue, 15 Sep 2009 22:39:44 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> In-Reply-To: <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [Netext] roaming issue-proposed text for roamingsection Thread-Index: Aco2c8fD2PzMDFyCQpGycVcv8Ck7bAAA1tiw References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 16 Sep 2009 02:39:44.0651 (UTC) FILETIME=[F3206DB0:01CA3676] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1253068870 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 02:40:26 -0000 =20 Hi, > [Qin]: So I think if policy governing the SLA can afffect=20 > localized routing directly, the MN's MAG and MN's LMA should=20 > belong to different domain. > In this sense, if MN's MAG and MN's LMA are located in the=20 > same domain, SLA policy can not affect localize routing, am I right? Well, typically SLAs are between provider domains; at least that's how I was referring to. >=20 > Furthermore, besides SLA policy, I think there are other=20 > policies that also affect localized routing e.g., in roaming=20 > scenario even though MAG and LMA are located in the same=20 > domain, having SA between MAG and LMA does not mean localized=20 > routing can be performed, because use of local routing may be=20 > subject to accounting and routing policies relating to the=20 > mobile node, , therefore localized routing signaling between=20 > MAG and LMA is required to negotiate localized routing policy=20 > information and enable/disable localized routing. Am I right? >=20 Yes, localized routing is subject to policy constraints regardless of roaming. My point was specific to roaming when the policy allows a MAG to provide localized routing. I do not think we need to design signaling for exchanging this policy, with or without roaming. Since LMA is the control entity, we can assume it to exert such policy control by instructing the MAG to provide localized routing. Regards, -Rajeev >=20 > > What do you think? > >=20 > > Regards, > >=20 > > -Rajeev > >=20 > >=20 > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: netext-bounces@ietf.org > >> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu > >> Sent: Tuesday, September 15, 2009 1:22 AM > >> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com > >> Cc: netext@ietf.org > >> Subject: Re: [netext] [Netext] roaming issue-proposed text for=20 > >> roamingsection > >>=20 > >> Hi, Mohana: > >> Thank for your reply. > >> ----- Original Message ----- > >> From: "Mohana Jeyatharan" > >> To: "Qin Wu" ; "Marco Liebsch"=20 > >> ; > >> Cc: > >> Sent: Tuesday, September 15, 2009 3:45 PM > >> Subject: RE: [Netext] roaming issue-proposed text for=20 > roaming section > >>=20 > >>=20 > >> Hi Qin, > >>=20 > >> Sorry wanted to comment on your text, but here are some comments. =20 > >>=20 > >> I think we should stick to the definition of PMIPv6 domain=20 > as in RFC > >> 5213 and not change it. That is, as long as the MAG-LMA=20 > tunnel can be=20 > >> created, it is considered as one PMIPv6 domain of MN. > >>=20 > >> [Qin]: you are right, wherever MN moves around, MN does not change=20 > >> the PMIPv6 domain to which MN belongs, i.e., MN's home=20 > PMIPv6 domain. > >>=20 > >> While being attached to such PMIPv6 domain, the MN may change=20 > >> administrative domain. > >> i.e. move from home domain to another administrative=20 > domain (foreign=20 > >> domain). > >>=20 > >> [Qin]: Another administrative domain you mentioned above can be=20 > >> viewed as MN's visited PMIPv6 domain. > >> that is to say, although MN changes from one visited=20 > PMIPv6 domain to=20 > >> another, MN does not change its home > >> PMIPv6 domain, does this sounds reasonable? Anyway, you=20 > can stick to=20 > >> use administrative to describe roaming if you like. > >>=20 > >> Now, please see some comments on the text proposed. > >>=20 > >>=20 > >> BR, > >> Mohana > >>=20 > >> > -----Original Message----- > >> > From: Qin Wu [mailto:sunseawq@huawei.com] > >> > Sent: Thursday, September 10, 2009 8:30 PM > >> > To: Marco Liebsch; Basavaraj.Patil@nokia.com > >> > Cc: netext@ietf.org; Mohana Jeyatharan > >> > Subject: Re: [Netext] roaming issue-proposed text for > >> roaming section > >> >=20 > >> > Hi, all: > >> > Since folks has no objection to add a section to talk=20 > about roaming > >> issues. > >> > I would like to propose > >> > some texts based on roaming picture proposed by Marco.=20 > The proposed > >> text > >> > is as follows: > >> > " > >> > In the real PMIPv6 deployment, PMIPv6 components(e.g.,=20 > LMAs, MAGs) > >> [Mohana: tied to a given MN] > >>=20 > >> [Qin]:Okay. > >>=20 > >> can be > >> > distributed into different PMIPv6 domains > >> [Mohana: adminsitrative > >> domain. Example LMA placed in one administrative domain and MAG=20 > >> placed in another administrative domain]. > >>=20 > >> [Qin]: I think we have two choices to describe roaming: > >> 1) define administrative domain > >> 2) Separate PMIPv6 domains into PMIPv6 home domain and=20 > PMIPv6 visited=20 > >> domain Both can be used to describe roaming, in my mind. > >>=20 > >> >In order to support localized > >> > routing, it is required that MAGs to which MN and CN connect are > >> within > >> > the same PMIPv6 domain [Mohana: within the same administrative > >> domain.]and each MAG setup security relationship > >> > respectively with corresponding LMAs which maintain specific=20 > >> > context > >> to > >> > which MN and CN belong. It is not required that LMAs=20 > anchored by MN > >> and CN > >> > are part of PMIPv6 domain [Mohana:administrative domain] as MAGs > >> attached by MN and CN. MN is allowed to > >> > roam within its PMIPv6 domain (i.e, MN's home domain in > >> which MN's LMA > >> is > >> > located) or over different PMIPv6 domains(i.e., MN's > >> visited domains). > >>=20 > >> [Mohana: I would say MN is allowed to roam from home=20 > adminsitartive=20 > >> domain to visted administrative domain all tied to a single PMIPv6=20 > >> domain of Mn] > >>=20 > >> [Qin]: see above. > >>=20 > >> CN > >> > should stay with MN within the same PMIPv6 domain [Mohana: > >> administrative domain]. =20 > >>=20 > >>=20 > >> Figure x shows PMIPv6 > >> > roaming cases where MAGs attached by MN and CN belong to the same > >> PMIPv6 > >> > domain. In this figure, four PMIPv6 roaming cases need=20 > to be taken > >> into > >> > account. > >> > Roaming case 1: > >> > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are > >> located > >> > in the same PMIPv6 domain A as described in the figure 2. > >> > Roaming case 2: > >> > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located > >> in the same > >> > PMIPv6 domain A while CN's LMA(LMA2') is located in the > >> PMIPv6 domain > >> B. > >> > Roaming case 3: > >> > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the=20 > PMIPv6 domain C > >> while > >> > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the=20 > PMIPv6 domain=20 > >> > A Roaming case 4: > >> > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the=20 > PMIPv6 domain C > >> while > >> > MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's=20 > >> > LMA(LMA2) > >> is > >> > located in the PMIPv6 domain B > >> >=20 > >> > " > >> [Mohana] I think, where description is made regarding MN and CN=20 > >> placement in a certain PMIPv6 domain, it is better to say=20 > in the same=20 > >> administrative domain. > >>=20 > >> [Qin] I think for now some people support this, some not. > >>=20 > >> It is just that MN is roaming in its PMIPv6 domain and CN=20 > is roaming=20 > >> in its PMIPv6 domain, and local MAG routing canbe=20 > performed when MN's=20 > >> MAG and CN's MAG are the same or are placed in the same=20 > adminstrative=20 > >> domain. I think such things need to be captued. > >>=20 > >> [Qin] Right. > >>=20 > >> > > >> -------------------------------------------------------------- > >> ---------- > >> -- > >> > ------ > >> >=20 > >> >=20 > >> > > > >> > > > >> > > | > >> > > +-----+ +-----+ | +-----+ > >> > > |LMA1 | |LMA2 | | |LMA2'| > >> > > +-----+ +-----+ | +-----+ > >> > > | > >> > > | > >> > > | > >> > > | > >> > > +-----+ +-----+ | > >> > > |MAG1 | |MAG2 | | > >> > > +-----+ +-----+ | > >> > > | > >> > > | > >> > > A | B > >> > > =20 > >> ------------------------------+------------------------------- > >> > > C > >> > > > >> > > > >> > > +-----+ +-----+ > >> > > |MAG1'| |MAG2'| > >> > > +-----+ +-----+ > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> >=20 > >> >=20 > >> > > >> -------------------------------------------------------------- > >> ---------- > >> -- > >> > ------ > >> >=20 > >> > If people prefer to use administrative domain, we can replace all > >> PMIPv6 > >> > domain in the proposed text with *administrative domain*, > >> Welcome your > >> > bash,:-) > >> > Regards! > >> > -Qin > >> > ----- Original Message ----- > >> > From: "Marco Liebsch" > >> > To: > >> > Cc: ; > >> > Sent: Wednesday, September 09, 2009 11:07 PM > >> > Subject: Re: [netext] [Netext] localized route optimization > >> - roaming > >> > issue > >> >=20 > >> >=20 > >> > > Hi Raj, > >> > > > >> > > yes, agreed, that's why it has been proposed to add a=20 > section on > >> this in > >> > > the PS. The picture > >> > > could be based on what I sent some mails ago. We're currently > >> preparing > >> > > some text, but > >> > > I think it makes sense to discuss and agree on the=20 > text before it > >> goes > >> > > to the PS draft. > >> > > > >> > > marco > >> > > > >> > > Basavaraj.Patil@nokia.com wrote: > >> > >> Hi Marco, > >> > >> > >> > >> One of the issues that we got hung up at IETF75 during the LR > >> > discussion was > >> > >> on roaming. It would be good to have a clear=20 > description of the > >> > relationship > >> > >> between the MAG and LMA in the context of a PMIP6 domain > >> especially > >> > when you > >> > >> consider home and visited network scenarios wherein=20 > the MAG/LMA > >> > entities are > >> > >> in different domains. > >> > >> > >> > >> The PMIP6 domain definition in RFC5213: > >> > >> " > >> > >> Proxy Mobile IPv6 domain refers to the network where the > >> mobility > >> > >> management of a mobile node is handled using the > >> Proxy Mobile > >> > IPv6 > >> > >> protocol as defined in this specification. The > >> Proxy Mobile > >> IPv6 > >> > >> domain includes local mobility anchors and mobile access > >> gateways > >> > >> between which security associations can be set up and > >> > >> authorization for sending Proxy Binding Updates on > >> behalf of > >> the > >> > >> mobile nodes can be ensured. > >> > >> " > >> > >> > >> > >> does not have any references to home/visited network > >> concepts. The > >> only > >> > >> criteria for an entity (MAG/LMA) being considered=20 > being a part=20 > >> > >> of > >> the > >> > PMIP6 > >> > >> domain is the existence of a security association. It > >> would be good > >> to > >> > >> elaborate how this maps to the current discussion in LR. > >> > >> > >> > >> -Raj > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >>=20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext >=20 From sunseawq@huawei.com Tue Sep 15 20:01:02 2009 Return-Path: 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 ABC3D3A6812 for ; Tue, 15 Sep 2009 20:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 1U4Soo5TXnsV for ; Tue, 15 Sep 2009 20:01:01 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A8EA63A6843 for ; Tue, 15 Sep 2009 20:01:00 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ1002AZN2QUL@szxga04-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 11:01:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ100AG9N2QSB@szxga04-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 11:01:38 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ1004H6N2OXY@szxml04-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 11:01:38 +0800 (CST) Date: Wed, 16 Sep 2009 11:01:37 +0800 From: Qin Wu To: "Koodli, Rajeev" , netext@ietf.org Message-id: <00dc01ca367a$01c18450$260ca40a@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: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 03:01:02 -0000 Hi, ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Wednesday, September 16, 2009 10:39 AM Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection > > Hi, > >> [Qin]: So I think if policy governing the SLA can afffect >> localized routing directly, the MN's MAG and MN's LMA should >> belong to different domain. >> In this sense, if MN's MAG and MN's LMA are located in the >> same domain, SLA policy can not affect localize routing, am I right? > > Well, typically SLAs are between provider domains; at least that's how I > was referring to. [Qin]: I agree. >> >> Furthermore, besides SLA policy, I think there are other >> policies that also affect localized routing e.g., in roaming >> scenario even though MAG and LMA are located in the same >> domain, having SA between MAG and LMA does not mean localized >> routing can be performed, because use of local routing may be >> subject to accounting and routing policies relating to the >> mobile node, , therefore localized routing signaling between >> MAG and LMA is required to negotiate localized routing policy >> information and enable/disable localized routing. Am I right? >> > > Yes, localized routing is subject to policy constraints regardless of > roaming. > > My point was specific to roaming when the policy allows a MAG to provide > localized routing. > > I do not think we need to design signaling for exchanging this policy, > with or without roaming. [Qin]: Okay, that is to say information exchange between MAG and LMA is required, But the information is not necessary to be taken as any policy. am I right? > Since LMA is the control entity, we can assume it to exert such policy > control by instructing the MAG to provide localized routing. [Qin]: I am wondering whether instructing the MAG to or not to provide localized routing (i.e., enable/disable localized routing) can be viewed as *policy*? > Regards, > > -Rajeev > > > >> >> > What do you think? >> > >> > Regards, >> > >> > -Rajeev >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: netext-bounces@ietf.org >> >> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu >> >> Sent: Tuesday, September 15, 2009 1:22 AM >> >> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com >> >> Cc: netext@ietf.org >> >> Subject: Re: [netext] [Netext] roaming issue-proposed text for >> >> roamingsection >> >> >> >> Hi, Mohana: >> >> Thank for your reply. >> >> ----- Original Message ----- >> >> From: "Mohana Jeyatharan" >> >> To: "Qin Wu" ; "Marco Liebsch" >> >> ; >> >> Cc: >> >> Sent: Tuesday, September 15, 2009 3:45 PM >> >> Subject: RE: [Netext] roaming issue-proposed text for >> roaming section >> >> >> >> >> >> Hi Qin, >> >> >> >> Sorry wanted to comment on your text, but here are some comments. >> >> >> >> I think we should stick to the definition of PMIPv6 domain >> as in RFC >> >> 5213 and not change it. That is, as long as the MAG-LMA >> tunnel can be >> >> created, it is considered as one PMIPv6 domain of MN. >> >> >> >> [Qin]: you are right, wherever MN moves around, MN does not change >> >> the PMIPv6 domain to which MN belongs, i.e., MN's home >> PMIPv6 domain. >> >> >> >> While being attached to such PMIPv6 domain, the MN may change >> >> administrative domain. >> >> i.e. move from home domain to another administrative >> domain (foreign >> >> domain). >> >> >> >> [Qin]: Another administrative domain you mentioned above can be >> >> viewed as MN's visited PMIPv6 domain. >> >> that is to say, although MN changes from one visited >> PMIPv6 domain to >> >> another, MN does not change its home >> >> PMIPv6 domain, does this sounds reasonable? Anyway, you >> can stick to >> >> use administrative to describe roaming if you like. >> >> >> >> Now, please see some comments on the text proposed. >> >> >> >> >> >> BR, >> >> Mohana >> >> >> >> > -----Original Message----- >> >> > From: Qin Wu [mailto:sunseawq@huawei.com] >> >> > Sent: Thursday, September 10, 2009 8:30 PM >> >> > To: Marco Liebsch; Basavaraj.Patil@nokia.com >> >> > Cc: netext@ietf.org; Mohana Jeyatharan >> >> > Subject: Re: [Netext] roaming issue-proposed text for >> >> roaming section >> >> > >> >> > Hi, all: >> >> > Since folks has no objection to add a section to talk >> about roaming >> >> issues. >> >> > I would like to propose >> >> > some texts based on roaming picture proposed by Marco. >> The proposed >> >> text >> >> > is as follows: >> >> > " >> >> > In the real PMIPv6 deployment, PMIPv6 components(e.g., >> LMAs, MAGs) >> >> [Mohana: tied to a given MN] >> >> >> >> [Qin]:Okay. >> >> >> >> can be >> >> > distributed into different PMIPv6 domains >> >> [Mohana: adminsitrative >> >> domain. Example LMA placed in one administrative domain and MAG >> >> placed in another administrative domain]. >> >> >> >> [Qin]: I think we have two choices to describe roaming: >> >> 1) define administrative domain >> >> 2) Separate PMIPv6 domains into PMIPv6 home domain and >> PMIPv6 visited >> >> domain Both can be used to describe roaming, in my mind. >> >> >> >> >In order to support localized >> >> > routing, it is required that MAGs to which MN and CN connect are >> >> within >> >> > the same PMIPv6 domain [Mohana: within the same administrative >> >> domain.]and each MAG setup security relationship >> >> > respectively with corresponding LMAs which maintain specific >> >> > context >> >> to >> >> > which MN and CN belong. It is not required that LMAs >> anchored by MN >> >> and CN >> >> > are part of PMIPv6 domain [Mohana:administrative domain] as MAGs >> >> attached by MN and CN. MN is allowed to >> >> > roam within its PMIPv6 domain (i.e, MN's home domain in >> >> which MN's LMA >> >> is >> >> > located) or over different PMIPv6 domains(i.e., MN's >> >> visited domains). >> >> >> >> [Mohana: I would say MN is allowed to roam from home >> adminsitartive >> >> domain to visted administrative domain all tied to a single PMIPv6 >> >> domain of Mn] >> >> >> >> [Qin]: see above. >> >> >> >> CN >> >> > should stay with MN within the same PMIPv6 domain [Mohana: >> >> administrative domain]. >> >> >> >> >> >> Figure x shows PMIPv6 >> >> > roaming cases where MAGs attached by MN and CN belong to the same >> >> PMIPv6 >> >> > domain. In this figure, four PMIPv6 roaming cases need >> to be taken >> >> into >> >> > account. >> >> > Roaming case 1: >> >> > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are >> >> located >> >> > in the same PMIPv6 domain A as described in the figure 2. >> >> > Roaming case 2: >> >> > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located >> >> in the same >> >> > PMIPv6 domain A while CN's LMA(LMA2') is located in the >> >> PMIPv6 domain >> >> B. >> >> > Roaming case 3: >> >> > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the >> PMIPv6 domain C >> >> while >> >> > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the >> PMIPv6 domain >> >> > A Roaming case 4: >> >> > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the >> PMIPv6 domain C >> >> while >> >> > MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's >> >> > LMA(LMA2) >> >> is >> >> > located in the PMIPv6 domain B >> >> > >> >> > " >> >> [Mohana] I think, where description is made regarding MN and CN >> >> placement in a certain PMIPv6 domain, it is better to say >> in the same >> >> administrative domain. >> >> >> >> [Qin] I think for now some people support this, some not. >> >> >> >> It is just that MN is roaming in its PMIPv6 domain and CN >> is roaming >> >> in its PMIPv6 domain, and local MAG routing canbe >> performed when MN's >> >> MAG and CN's MAG are the same or are placed in the same >> adminstrative >> >> domain. I think such things need to be captued. >> >> >> >> [Qin] Right. >> >> >> >> > >> >> -------------------------------------------------------------- >> >> ---------- >> >> -- >> >> > ------ >> >> > >> >> > >> >> > > >> >> > > >> >> > > | >> >> > > +-----+ +-----+ | +-----+ >> >> > > |LMA1 | |LMA2 | | |LMA2'| >> >> > > +-----+ +-----+ | +-----+ >> >> > > | >> >> > > | >> >> > > | >> >> > > | >> >> > > +-----+ +-----+ | >> >> > > |MAG1 | |MAG2 | | >> >> > > +-----+ +-----+ | >> >> > > | >> >> > > | >> >> > > A | B >> >> > > >> >> ------------------------------+------------------------------- >> >> > > C >> >> > > >> >> > > >> >> > > +-----+ +-----+ >> >> > > |MAG1'| |MAG2'| >> >> > > +-----+ +-----+ >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -------------------------------------------------------------- >> >> ---------- >> >> -- >> >> > ------ >> >> > >> >> > If people prefer to use administrative domain, we can replace all >> >> PMIPv6 >> >> > domain in the proposed text with *administrative domain*, >> >> Welcome your >> >> > bash,:-) >> >> > Regards! >> >> > -Qin >> >> > ----- Original Message ----- >> >> > From: "Marco Liebsch" >> >> > To: >> >> > Cc: ; >> >> > Sent: Wednesday, September 09, 2009 11:07 PM >> >> > Subject: Re: [netext] [Netext] localized route optimization >> >> - roaming >> >> > issue >> >> > >> >> > >> >> > > Hi Raj, >> >> > > >> >> > > yes, agreed, that's why it has been proposed to add a >> section on >> >> this in >> >> > > the PS. The picture >> >> > > could be based on what I sent some mails ago. We're currently >> >> preparing >> >> > > some text, but >> >> > > I think it makes sense to discuss and agree on the >> text before it >> >> goes >> >> > > to the PS draft. >> >> > > >> >> > > marco >> >> > > >> >> > > Basavaraj.Patil@nokia.com wrote: >> >> > >> Hi Marco, >> >> > >> >> >> > >> One of the issues that we got hung up at IETF75 during the LR >> >> > discussion was >> >> > >> on roaming. It would be good to have a clear >> description of the >> >> > relationship >> >> > >> between the MAG and LMA in the context of a PMIP6 domain >> >> especially >> >> > when you >> >> > >> consider home and visited network scenarios wherein >> the MAG/LMA >> >> > entities are >> >> > >> in different domains. >> >> > >> >> >> > >> The PMIP6 domain definition in RFC5213: >> >> > >> " >> >> > >> Proxy Mobile IPv6 domain refers to the network where the >> >> mobility >> >> > >> management of a mobile node is handled using the >> >> Proxy Mobile >> >> > IPv6 >> >> > >> protocol as defined in this specification. The >> >> Proxy Mobile >> >> IPv6 >> >> > >> domain includes local mobility anchors and mobile access >> >> gateways >> >> > >> between which security associations can be set up and >> >> > >> authorization for sending Proxy Binding Updates on >> >> behalf of >> >> the >> >> > >> mobile nodes can be ensured. >> >> > >> " >> >> > >> >> >> > >> does not have any references to home/visited network >> >> concepts. The >> >> only >> >> > >> criteria for an entity (MAG/LMA) being considered >> being a part >> >> > >> of >> >> the >> >> > PMIP6 >> >> > >> domain is the existence of a security association. It >> >> would be good >> >> to >> >> > >> elaborate how this maps to the current discussion in LR. >> >> > >> >> >> > >> -Raj >> >> _______________________________________________ >> >> netext mailing list >> >> netext@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netext >> >> >> > _______________________________________________ >> > netext mailing list >> > netext@ietf.org >> > https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From jouni.nospam@gmail.com Tue Sep 15 22:53:04 2009 Return-Path: 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 CD4763A690E for ; Tue, 15 Sep 2009 22:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 laryysV9ObJz for ; Tue, 15 Sep 2009 22:53:03 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 4B7763A67D1 for ; Tue, 15 Sep 2009 22:53:03 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so936145fga.13 for ; Tue, 15 Sep 2009 22:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=MxgqRip4XXKoKv51isVLaesgRBDnQiUoKL28XFymKjQ=; b=FATKH/vjKKzqN3tGJu3HOp9P58JU0Zs0/bjqlLJlwSYiHSGbgi7QjsC3IoQMDZK7l7 zZNJrvW5YDjoU2LOi44stQmE0QBV3EytIZbYUCffr2P00VpXzeb5RhRajht4Xo/etZS/ eHPvqn8ztsizh4xjUu6vuZN+8z9dnPr8c++1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=QAYX1gnWQFrinqxuBm7frmBdIQCXRP56U4rbNFYyZUy6S39gln4CmfHRBZ/Onieopd ltbN365DDwqRfWRxiMiniu4IRTFphcYwvktqnXqWSbGWOx8HFmZ6nxxhwPuxdEQDstNi qKJ7M1WVLib2w2/JEwDHKlYXDzMYQLniD/POU= Received: by 10.86.17.29 with SMTP id 29mr7050379fgq.38.1253080428922; Tue, 15 Sep 2009 22:53:48 -0700 (PDT) Received: from a83-245-215-138.elisa-laajakaista.fi (a83-245-215-138.elisa-laajakaista.fi [83.245.215.138]) by mx.google.com with ESMTPS id l19sm1092527fgb.22.2009.09.15.22.53.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Sep 2009 22:53:48 -0700 (PDT) Message-Id: From: jouni korhonen To: w52006@huawei.com In-Reply-To: <005a01ca366b$6c3bf630$110ca40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Sep 2009 08:53:47 +0300 References: <005a01ca366b$6c3bf630$110ca40a@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 05:53:04 -0000 Hi, Thanks for feedback. See some answers inline. On Sep 16, 2009, at 4:17 AM, Yungui Wang wrote: > Hello > > That's okey. There are other two minor comments. > > 1, I think, the 'Redirect-Capability Mobility Option' is not > essential. In > my understanding, the common MIP/PMIP system has provided the general > capability negotiation mechanism. That's, if there is an extended > mobility By common capability negotiation mechanism do you mean flags in PBU/ PBA headers? If so, it was a design choice not to allocate more of those. > option is not supported or identified, the receiver can just discard > it > silently. Isn't it? On the other side, even if the LMA doesn't > return the The current design makes use of this behavior that LMAs silently ignore mobility options they do not understand. In that way a MAG supporting redirection and a LMA not supporting redirection can fallback to RFC5213 normal operation. > 'Redirect Mobility Option', for implementation, the MAG which has > enabled > the redirection function may re-register the MN to another LMA when it > receives a failed PBA, e.g. 130. This is of course possible already within RFC5213 scope but that is a MAG implementation specific fallback operation rather than a guided redirection. > Therefore, for simplification, the capability option can be removed. Hmmm.. I don't fully agree with this. The Redirect-Capability option is also used as an indication from a MAG if it wants to be redirected or not. Also we currently embed IPv4 information on that option. Of course this could be achieved with PBU/PBA flags but so far I am not convinced that those would be better than using a mobility option. > > 2, I can't catch the logic of SA check described in the section > 5.3.2. (at > the 3th and 4th paragraph) > In my understanding, if there is no SA between the MAG and the > r2LMA, how > can the r2LMA accept the PBU and create the mobility session at > before? On Good point. This is an obvious error and needs to be fixed. > the other hand, the SA check is necessary to another case described > in 5.4. > However, I don't see how the MAG does that. Are there some local > policies on > the MAG, or does the MAG check it according to the MN's profile > downloaded > from policy store, or ...? The MAG is supposed to know with whom it has SAs with by configuration. That would be a normal SAD/SPD lookup. If none of the existing SAs match, then either the PBU/PBA exchange fails or the dynamic creation of the SA is initiated. Cheers, Jouni > > B.R. > Yungui > >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Tuesday, September 15, 2009 6:11 PM >> To: w52006@huawei.com >> Cc: netext@ietf.org >> Subject: Re: [netext] FW: New Version Notification >> fordraft-korhonen-netext-redirect-03 >> >> Hi, >> >> On Sep 15, 2009, at 11:33 AM, Yungui Wang wrote: >> >>> Hello Jouni >>> >>> It is observed that the assigned r2LMA would be >> stored/updated into >>> the MN's >>> profile on the policy store. May I know when it happens and >> who does? >> >> Yes, r2LMA information would be stored into the policy >> profile. On the >> MAG side this would happen when the PBA containing the Redirect >> mobility option arrives. If the remote policy store needs to be >> updated, it would be done e.g. by r2LMA using the LMA-HAAA interface >> described in draft-ietf-dime-pmip6. >> >> I will add some text to the I-D regarding the policy profile update. >> >> Cheers, >> Jouni >> >> >>> >>> B.R. >>> Yungui >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org >>>> [mailto:netext-bounces@ietf.org] On Behalf Of jouni korhonen >>>> Sent: Tuesday, September 15, 2009 3:24 PM >>>> To: netext@ietf.org >>>> Subject: [netext] FW: New Version Notification >>>> fordraft-korhonen-netext-redirect-03 >>>> >>>> FYI >>>> >>>> We submitted an updated version of the Runtime LMA Assignment I-D a >>>> while ago. This revision should address the comments we received in >>>> Stockholm or at least add the basis for further work on >> those areas. >>>> >>>> Cheers, >>>> Jouni >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: IETF I-D Submission Tool >>>>> Date: September 10, 2009 1:59:06 AM GMT+03:00 >>>>> To: jouni.nospam@gmail.com >>>>> Cc: sri.gundavelli@cisco.com,yokota@kddilabs.jp >>>>> Subject: New Version Notification for draft-korhonen-netext- >>>>> redirect-03 >>>>> >>>>> >>>>> A new version of I-D, draft-korhonen-netext-redirect-03.txt >>>> has been >>>>> successfuly submitted by Jouni Korhonen and posted to the IETF >>>>> repository. >>>>> >>>>> Filename: draft-korhonen-netext-redirect >>>>> Revision: 03 >>>>> Title: Runtime LMA Assignment Support for >>>> Proxy Mobile IPv6 >>>>> Creation_date: 2009-09-10 >>>>> WG ID: Independent Submission >>>>> Number_of_pages: 23 >>>>> >>>>> Abstract: >>>>> This document describes a redirect functionality and corresponding >>>>> mobility options for Proxy Mobile IPv6. The redirect >> functionality >>>>> allows a dynamic runtime assignment of a Local Mobility Anchor and >>>>> redirecting the mobility session to the assigned Local Mobility >>>>> Anchor. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >>> >> > From w52006@huawei.com Wed Sep 16 01:14:55 2009 Return-Path: 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 B41C73A69BD for ; Wed, 16 Sep 2009 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=1.160, 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 x8O3RdAVnelO for ; Wed, 16 Sep 2009 01:14:55 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C5A563A6782 for ; Wed, 16 Sep 2009 01:14:54 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ20070C1GHED@szxga03-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 16:12:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ20026M1GHS1@szxga03-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 16:12:17 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ2004761GGXQ@szxml04-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 16:12:17 +0800 (CST) Date: Wed, 16 Sep 2009 16:12:16 +0800 From: Yungui Wang In-reply-to: To: 'jouni korhonen' Message-id: <007501ca36a5$67c26fa0$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco2khKuSzWtD6JUSoOO9OUJ4dBYjgAAW4dw Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 08:14:55 -0000 Hello > > Therefore, for simplification, the capability option can be removed. > > Hmmm.. I don't fully agree with this. The Redirect-Capability option > is also used as an indication from a MAG if it wants to be > redirected or not. I am confused about that. In my mind, the Capability option is just used to tell the rfLMA by the MAG that 'supports' the following 'Redirect mobility option'. Isn't it? The motivation that the rfLMA decides to redirect the session should be dependent on the blade architecture or the rfLMA self's load, etc. as described in the section 1. I don't think the Capability option will affect its motivation. At this point, the Capability option is actually useless for the rfLMA. Hence, the MAG doesn't need to tell it to the rfLMA. > Also we currently embed IPv4 information on that option. > Of course this could be achieved with PBU/PBA flags but so far I am not > convinced that those would be better than using a mobility option. > Please see above. No flags needed too. > > > > 2, I can't catch the logic of SA check described in the section > > 5.3.2. (at > > the 3th and 4th paragraph) > > In my understanding, if there is no SA between the MAG and the > > r2LMA, how > > can the r2LMA accept the PBU and create the mobility session at > > before? On > > Good point. This is an obvious error and needs to be fixed. > That's Okey. > > > the other hand, the SA check is necessary to another case > described > > in 5.4. > > However, I don't see how the MAG does that. Are there some local > > policies on > > the MAG, or does the MAG check it according to the MN's profile > > downloaded > > from policy store, or ...? > > The MAG is supposed to know with whom it has SAs with by > configuration. That would be a normal SAD/SPD lookup. > If none of the > existing SAs match, then either the PBU/PBA exchange fails or the > dynamic creation of the SA is initiated. > Please see the detailed use case. In my understanding, there are three sets of LMA addresses on the MAG. The first (set_A) is coming from local configuration independent from the individual MN. The second (set_B) is for the special MN, e.g. acheived by draft-ietf-netlmm-lma-discovery mechanism. The third (set_C) is provided by this draft. You said configuration check seems a little ambiguous. I wonder if the MAG checks that the set_C belongs to both set_A and set_B. B.R. Yungui From Marco.Liebsch@nw.neclab.eu Wed Sep 16 01:58:10 2009 Return-Path: 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 8B2533A6AA3 for ; Wed, 16 Sep 2009 01:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 tuEnSp2DIB9L for ; Wed, 16 Sep 2009 01:58:09 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 835C43A6A98 for ; Wed, 16 Sep 2009 01:58:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id E2A3A2C0004DE; Wed, 16 Sep 2009 10:58:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBptj8WLcBSG; Wed, 16 Sep 2009 10:58:56 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id B35C22C0001AA; Wed, 16 Sep 2009 10:58:46 +0200 (CEST) Received: from [127.0.0.1] ([10.1.2.187]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 10:58:46 +0200 Message-ID: <4AB0A8C6.2080600@nw.neclab.eu> Date: Wed, 16 Sep 2009 10:58:46 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2009 08:58:46.0621 (UTC) FILETIME=[E665A8D0:01CA36AB] Cc: netext@ietf.org Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 08:58:10 -0000 Hi Rajeev, thanks for your take. Please find some comments inline. Koodli, Rajeev schrieb: > > Hello folks, > > There has been some good discussion on this topic. Here's my take to > converge and make progress. > Please read all the point below before responding. > > 1. We do not deviate from the definition of a PMIPv6 domain as in RFC > 5213. > Agree. > 2. No new definitions of "domain" > Which domain? If it's PMIPv6 domain, I agree and it's covered by 1. > 3. Roaming is simply defined as "access to the Internet when the MAG and > LMA are in different provider domains" > Provider domain is a new term on the table in the context of this discussion. Do we need to define it? Or is it clear, so we can just use it? I think the Provider domain is what we so far considered as Administrative domain,. > (We do not need to explain the underlying reasons IMO. "Access to the > Internet" means the traditional connectivity via MAG and LMA as in RFC > 5213; we should not delve into "service-specific" definitions here) > > 4. If an SA exists between a MAG and an LMA, there will be packet > forwarding (i.e., MAG and LMA can be in different provider domains) > . > 5. We need to state somewhere that for the roaming case, localized > routing is subject to policy governing the service level agreements > between the providers. This means that merely having an SA between a > (visited) MAG and a (home) LMA does not translate to enabling localized > routing when (at least) one of the MN's is roaming. > I think that all involved (home) LMAs needs to show green light for establishing localized routing between the MNs. And what RFC5213 sais in the context of single-MAG local routing is, that the LMA should control the setup. So, the LMA could initiate localized routing at a MAG in the visited network. According to the policy of the visited provider domain, the MAG can either accept or reject localized routing. Localized routing will be successful when both LMAs and both MAGs accept localized routing. For the protocol spec, I think we just need to consider status codes which allow LMAs/MAGs to *negative ack* a request to establish locaized routing. That reflects the SLAs on the mobility protocol layer. I don't think that the localized routing protocol needs to handle SLAs itself. Hope that makes sense. marco > What do you think? > > Regards, > > -Rajeev > > > > > > >> -----Original Message----- >> From: netext-bounces@ietf.org >> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu >> Sent: Tuesday, September 15, 2009 1:22 AM >> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com >> Cc: netext@ietf.org >> Subject: Re: [netext] [Netext] roaming issue-proposed text >> for roamingsection >> >> Hi, Mohana: >> Thank for your reply. >> ----- Original Message ----- >> From: "Mohana Jeyatharan" >> To: "Qin Wu" ; "Marco Liebsch" >> ; >> Cc: >> Sent: Tuesday, September 15, 2009 3:45 PM >> Subject: RE: [Netext] roaming issue-proposed text for roaming section >> >> >> Hi Qin, >> >> Sorry wanted to comment on your text, but here are some comments. >> >> I think we should stick to the definition of PMIPv6 domain as in RFC >> 5213 and not change it. That is, as long as the MAG-LMA tunnel can be >> created, it is considered as one PMIPv6 domain of MN. >> >> [Qin]: you are right, wherever MN moves around, MN does not >> change the PMIPv6 domain to which MN belongs, >> i.e., MN's home PMIPv6 domain. >> >> While being attached to such PMIPv6 domain, the MN may change >> administrative domain. >> i.e. move from home domain to another administrative domain (foreign >> domain). >> >> [Qin]: Another administrative domain you mentioned above can >> be viewed as MN's visited PMIPv6 domain. >> that is to say, although MN changes from one visited PMIPv6 >> domain to another, MN does not change its home >> PMIPv6 domain, does this sounds reasonable? Anyway, you can >> stick to use administrative to describe roaming if >> you like. >> >> Now, please see some comments on the text proposed. >> >> >> BR, >> Mohana >> >> >>> -----Original Message----- >>> From: Qin Wu [mailto:sunseawq@huawei.com] >>> Sent: Thursday, September 10, 2009 8:30 PM >>> To: Marco Liebsch; Basavaraj.Patil@nokia.com >>> Cc: netext@ietf.org; Mohana Jeyatharan >>> Subject: Re: [Netext] roaming issue-proposed text for >>> >> roaming section >> >>> Hi, all: >>> Since folks has no objection to add a section to talk about roaming >>> >> issues. >> >>> I would like to propose >>> some texts based on roaming picture proposed by Marco. The proposed >>> >> text >> >>> is as follows: >>> " >>> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) >>> >> [Mohana: tied to a given MN] >> >> [Qin]:Okay. >> >> can be >> >>> distributed into different PMIPv6 domains >>> >> [Mohana: adminsitrative >> domain. Example LMA placed in one administrative domain and MAG placed >> in another administrative domain]. >> >> [Qin]: I think we have two choices to describe roaming: >> 1) define administrative domain >> 2) Separate PMIPv6 domains into PMIPv6 home domain and PMIPv6 >> visited domain >> Both can be used to describe roaming, in my mind. >> >> >>> In order to support localized >>> routing, it is required that MAGs to which MN and CN connect are >>> >> within >> >>> the same PMIPv6 domain [Mohana: within the same administrative >>> >> domain.]and each MAG setup security relationship >> >>> respectively with corresponding LMAs which maintain specific context >>> >> to >> >>> which MN and CN belong. It is not required that LMAs anchored by MN >>> >> and CN >> >>> are part of PMIPv6 domain [Mohana:administrative domain] as MAGs >>> >> attached by MN and CN. MN is allowed to >> >>> roam within its PMIPv6 domain (i.e, MN's home domain in >>> >> which MN's LMA >> is >> >>> located) or over different PMIPv6 domains(i.e., MN's >>> >> visited domains). >> >> [Mohana: I would say MN is allowed to roam from home adminsitartive >> domain to visted administrative domain all tied to a single PMIPv6 >> domain of Mn] >> >> [Qin]: see above. >> >> CN >> >>> should stay with MN within the same PMIPv6 domain [Mohana: >>> >> administrative domain]. >> >> >> Figure x shows PMIPv6 >> >>> roaming cases where MAGs attached by MN and CN belong to the same >>> >> PMIPv6 >> >>> domain. In this figure, four PMIPv6 roaming cases need to be taken >>> >> into >> >>> account. >>> Roaming case 1: >>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are >>> >> located >> >>> in the same PMIPv6 domain A as described in the figure 2. >>> Roaming case 2: >>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located >>> >> in the same >> >>> PMIPv6 domain A while CN's LMA(LMA2') is located in the >>> >> PMIPv6 domain >> B. >> >>> Roaming case 3: >>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C >>> >> while >> >>> MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A >>> Roaming case 4: >>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C >>> >> while >> >>> MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) >>> >> is >> >>> located in the PMIPv6 domain B >>> >>> " >>> >> [Mohana] I think, where description is made regarding MN and CN >> placement in a certain PMIPv6 domain, it is better to say in the same >> administrative domain. >> >> [Qin] I think for now some people support this, some not. >> >> It is just that MN is roaming in its PMIPv6 domain and CN is >> roaming in its PMIPv6 domain, and local MAG routing >> canbe performed when MN's MAG and CN's MAG are the same or >> are placed in >> the same adminstrative domain. I think such things need to >> be captued. >> >> [Qin] Right. >> >> >> -------------------------------------------------------------- >> ---------- >> -- >> >>> ------ >>> >>> >>> >>>> | >>>> +-----+ +-----+ | +-----+ >>>> |LMA1 | |LMA2 | | |LMA2'| >>>> +-----+ +-----+ | +-----+ >>>> | >>>> | >>>> | >>>> | >>>> +-----+ +-----+ | >>>> |MAG1 | |MAG2 | | >>>> +-----+ +-----+ | >>>> | >>>> | >>>> A | B >>>> >>>> >> ------------------------------+------------------------------- >> >>>> C >>>> >>>> >>>> +-----+ +-----+ >>>> |MAG1'| |MAG2'| >>>> +-----+ +-----+ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> -------------------------------------------------------------- >> ---------- >> -- >> >>> ------ >>> >>> If people prefer to use administrative domain, we can replace all >>> >> PMIPv6 >> >>> domain in the proposed text with *administrative domain*, >>> >> Welcome your >> >>> bash,:-) >>> Regards! >>> -Qin >>> ----- Original Message ----- >>> From: "Marco Liebsch" >>> To: >>> Cc: ; >>> Sent: Wednesday, September 09, 2009 11:07 PM >>> Subject: Re: [netext] [Netext] localized route optimization >>> >> - roaming >> >>> issue >>> >>> >>> >>>> Hi Raj, >>>> >>>> yes, agreed, that's why it has been proposed to add a section on >>>> >> this in >> >>>> the PS. The picture >>>> could be based on what I sent some mails ago. We're currently >>>> >> preparing >> >>>> some text, but >>>> I think it makes sense to discuss and agree on the text before it >>>> >> goes >> >>>> to the PS draft. >>>> >>>> marco >>>> >>>> Basavaraj.Patil@nokia.com wrote: >>>> >>>>> Hi Marco, >>>>> >>>>> One of the issues that we got hung up at IETF75 during the LR >>>>> >>> discussion was >>> >>>>> on roaming. It would be good to have a clear description of the >>>>> >>> relationship >>> >>>>> between the MAG and LMA in the context of a PMIP6 domain >>>>> >> especially >> >>> when you >>> >>>>> consider home and visited network scenarios wherein the MAG/LMA >>>>> >>> entities are >>> >>>>> in different domains. >>>>> >>>>> The PMIP6 domain definition in RFC5213: >>>>> " >>>>> Proxy Mobile IPv6 domain refers to the network where the >>>>> >> mobility >> >>>>> management of a mobile node is handled using the >>>>> >> Proxy Mobile >> >>> IPv6 >>> >>>>> protocol as defined in this specification. The >>>>> >> Proxy Mobile >> IPv6 >> >>>>> domain includes local mobility anchors and mobile access >>>>> >> gateways >> >>>>> between which security associations can be set up and >>>>> authorization for sending Proxy Binding Updates on >>>>> >> behalf of >> the >> >>>>> mobile nodes can be ensured. >>>>> " >>>>> >>>>> does not have any references to home/visited network >>>>> >> concepts. The >> only >> >>>>> criteria for an entity (MAG/LMA) being considered being a part of >>>>> >> the >> >>> PMIP6 >>> >>>>> domain is the existence of a security association. It >>>>> >> would be good >> to >> >>>>> elaborate how this maps to the current discussion in LR. >>>>> >>>>> -Raj >>>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From jouni.nospam@gmail.com Wed Sep 16 02:33:25 2009 Return-Path: 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 392C93A68BF for ; Wed, 16 Sep 2009 02:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 sN8hQNZRji5A for ; Wed, 16 Sep 2009 02:33:24 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id E8FA13A67AB for ; Wed, 16 Sep 2009 02:33:23 -0700 (PDT) Received: by ewy3 with SMTP id 3so5089725ewy.42 for ; Wed, 16 Sep 2009 02:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=mTwcGa3XZL0IwrXdCCF2nRjZ7rRPkdauDBcb/OqKRms=; b=bAl7ZJIoiw0jaM2SSZypekvjAklufobvm8cvxh7R84gGZJvZmcF1rRBcUpqPVVq7zW kZzrt1Y7eq1RkfADgO0pRfXHZ2UOWVwFjcqwt6FS0WieZsytln0vVGX22yIS7cSEmMZk 4bQ0BXIApHhuSg4Yo85r80OpJEtAyQlK5k8q4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=bHEUoZKbB0Eo8K0tnFmLK13P5CS6pdpNtqWefPJc99nXls774vtX5mJMtH1vHThrkt 2xr7ujQrz1mCBqtr2jNqL7MwqvLgEKdmJEXLHzPtC4MMJ+okNmjGbY93qWjfJflwt7ef aKfFs4TaLCviustlXNxOacurypcqW1CK+fe00= Received: by 10.211.160.11 with SMTP id m11mr9709092ebo.79.1253093651699; Wed, 16 Sep 2009 02:34:11 -0700 (PDT) Received: from a83-245-215-138.elisa-laajakaista.fi (a83-245-215-138.elisa-laajakaista.fi [83.245.215.138]) by mx.google.com with ESMTPS id 10sm2275532eyz.26.2009.09.16.02.34.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Sep 2009 02:34:11 -0700 (PDT) Message-Id: From: jouni korhonen To: w52006@huawei.com In-Reply-To: <007501ca36a5$67c26fa0$110ca40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Sep 2009 12:34:09 +0300 References: <007501ca36a5$67c26fa0$110ca40a@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 09:33:25 -0000 Hi, On Sep 16, 2009, at 11:12 AM, Yungui Wang wrote: > Hello > >>> Therefore, for simplification, the capability option can be removed. >> >> Hmmm.. I don't fully agree with this. The Redirect-Capability option >> is also used as an indication from a MAG if it wants to be >> redirected or not. > > I am confused about that. In my mind, the Capability option is just > used to > tell the rfLMA by the MAG that 'supports' the following 'Redirect > mobility > option'. Isn't it? The motivation that the rfLMA decides to redirect > the So you agree the Redirect-Capability option is ok for indicating redirection support. > session should be dependent on the blade architecture or the rfLMA > self's > load, etc. as described in the section 1. I don't think the Capability > option will affect its motivation. At this point, the Capability > option is > actually useless for the rfLMA. Hence, the MAG doesn't need to tell > it to > the rfLMA. The rfLMA won't even try to do the redirection unless the MAG expresses its capability for it. In Section 3 we mandate that MAG-LMA do not "remember" the prior redirection capability indications. That allows e.g. the MAG to prohibit midsession redirections. The other reason is to get the same behavior of the protocol whether a MAG supports redirection or not. A MAG should never be redirected if it does not support the feature where as a LMA does. Therefore, the redirection may only be triggered when a MAG so indicates. > >> Also we currently embed IPv4 information on that option. >> Of course this could be achieved with PBU/PBA flags but so far I am >> not >> convinced that those would be better than using a mobility option. >> > > Please see above. No flags needed too. > >>> >>> 2, I can't catch the logic of SA check described in the section >>> 5.3.2. (at >>> the 3th and 4th paragraph) >>> In my understanding, if there is no SA between the MAG and the >>> r2LMA, how >>> can the r2LMA accept the PBU and create the mobility session at >>> before? On >> >> Good point. This is an obvious error and needs to be fixed. >> > > That's Okey. > >> >>> the other hand, the SA check is necessary to another case >> described >>> in 5.4. >>> However, I don't see how the MAG does that. Are there some local >>> policies on >>> the MAG, or does the MAG check it according to the MN's profile >>> downloaded >>> from policy store, or ...? >> >> The MAG is supposed to know with whom it has SAs with by >> configuration. That would be a normal SAD/SPD lookup. >> If none of the >> existing SAs match, then either the PBU/PBA exchange fails or the >> dynamic creation of the SA is initiated. >> > > Please see the detailed use case. > In my understanding, there are three sets of LMA addresses on the > MAG. The > first (set_A) is coming from local configuration independent from the > individual MN. The second (set_B) is for the special MN, e.g. > acheived by > draft-ietf-netlmm-lma-discovery mechanism. The third (set_C) is > provided by > this draft. > You said configuration check seems a little ambiguous. I wonder if > the MAG > checks that the set_C belongs to both set_A and set_B. I see your point. We can clarify this for sure. The check is against SAs, not address set_[AB]. At the end, SAs must be configured for all set_[ABC] addresses for the protocol to succeed. I am not sure whether we should mandate anything there other than saying that SAs must be in place. Cheers, Jouni > > B.R. > Yungui > From Marco.Liebsch@nw.neclab.eu Wed Sep 16 03:13:24 2009 Return-Path: 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 885C73A6944 for ; Wed, 16 Sep 2009 03:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 FaRxkO4rA4xj for ; Wed, 16 Sep 2009 03:13:23 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 6B6D53A67C2 for ; Wed, 16 Sep 2009 03:13:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 2A0212C0004DE; Wed, 16 Sep 2009 12:14:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFwS8-4ey7al; Wed, 16 Sep 2009 12:14:11 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id EDA6D2C0001AA; Wed, 16 Sep 2009 12:13:55 +0200 (CEST) Received: from [127.0.0.1] ([10.1.2.187]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Sep 2009 12:13:55 +0200 Message-ID: <4AB0BA63.9020507@nw.neclab.eu> Date: Wed, 16 Sep 2009 12:13:55 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Qin Wu References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> <00dc01ca367a$01c18450$260ca40a@china.huawei.com> In-Reply-To: <00dc01ca367a$01c18450$260ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Sep 2009 10:13:55.0892 (UTC) FILETIME=[6621CF40:01CA36B6] Cc: netext@ietf.org Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 10:13:24 -0000 Hi Qin, please see inline for my view. Qin Wu schrieb: > Hi, > ----- Original Message ----- > From: "Koodli, Rajeev" > To: > Sent: Wednesday, September 16, 2009 10:39 AM > Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection > > > >> Hi, >> >> >>> [Qin]: So I think if policy governing the SLA can afffect >>> localized routing directly, the MN's MAG and MN's LMA should >>> belong to different domain. >>> In this sense, if MN's MAG and MN's LMA are located in the >>> same domain, SLA policy can not affect localize routing, am I right? >>> >> Well, typically SLAs are between provider domains; at least that's how I >> was referring to. >> > > [Qin]: I agree. > > >>> Furthermore, besides SLA policy, I think there are other >>> policies that also affect localized routing e.g., in roaming >>> scenario even though MAG and LMA are located in the same >>> domain, having SA between MAG and LMA does not mean localized >>> routing can be performed, because use of local routing may be >>> subject to accounting and routing policies relating to the >>> mobile node, , therefore localized routing signaling between >>> MAG and LMA is required to negotiate localized routing policy >>> information and enable/disable localized routing. Am I right? >>> >>> >> Yes, localized routing is subject to policy constraints regardless of >> roaming. >> >> My point was specific to roaming when the policy allows a MAG to provide >> localized routing. >> >> I do not think we need to design signaling for exchanging this policy, >> with or without roaming. >> > > [Qin]: Okay, that is to say information exchange between MAG and LMA is required, > But the information is not necessary to be taken as any policy. am I right? > I don't think the protocol should not be used to echange policies, which even does not make sense to me to transfer e.g. provider policies beyond domains, as the remote provider may have different policies. I think components (LMA, MAG) must operate according to their provider's policy and the protocols should just reflect the policy by means of requests to set up localized routing, which can be accepted or not and indicated accordingly in a status/reason code. > >> Since LMA is the control entity, we can assume it to exert such policy >> control by instructing the MAG to provide localized routing. >> > > [Qin]: I am wondering whether instructing the MAG to or not to provide localized routing > (i.e., enable/disable localized routing) can be viewed as *policy*? > I think it's more that the LMA acts according to it's operator's policy. If the policy does not permit localized routing, the LMA would not send the request. The instruction/request itself does not convey policies, as I understand from your question. This is my view. marco > >> Regards, >> >> -Rajeev >> >> >> >> >>>> What do you think? >>>> >>>> Regards, >>>> >>>> -Rajeev >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: netext-bounces@ietf.org >>>>> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu >>>>> Sent: Tuesday, September 15, 2009 1:22 AM >>>>> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com >>>>> Cc: netext@ietf.org >>>>> Subject: Re: [netext] [Netext] roaming issue-proposed text for >>>>> roamingsection >>>>> >>>>> Hi, Mohana: >>>>> Thank for your reply. >>>>> ----- Original Message ----- >>>>> From: "Mohana Jeyatharan" >>>>> To: "Qin Wu" ; "Marco Liebsch" >>>>> ; >>>>> Cc: >>>>> Sent: Tuesday, September 15, 2009 3:45 PM >>>>> Subject: RE: [Netext] roaming issue-proposed text for >>>>> >>> roaming section >>> >>>>> Hi Qin, >>>>> >>>>> Sorry wanted to comment on your text, but here are some comments. >>>>> >>>>> I think we should stick to the definition of PMIPv6 domain >>>>> >>> as in RFC >>> >>>>> 5213 and not change it. That is, as long as the MAG-LMA >>>>> >>> tunnel can be >>> >>>>> created, it is considered as one PMIPv6 domain of MN. >>>>> >>>>> [Qin]: you are right, wherever MN moves around, MN does not change >>>>> the PMIPv6 domain to which MN belongs, i.e., MN's home >>>>> >>> PMIPv6 domain. >>> >>>>> While being attached to such PMIPv6 domain, the MN may change >>>>> administrative domain. >>>>> i.e. move from home domain to another administrative >>>>> >>> domain (foreign >>> >>>>> domain). >>>>> >>>>> [Qin]: Another administrative domain you mentioned above can be >>>>> viewed as MN's visited PMIPv6 domain. >>>>> that is to say, although MN changes from one visited >>>>> >>> PMIPv6 domain to >>> >>>>> another, MN does not change its home >>>>> PMIPv6 domain, does this sounds reasonable? Anyway, you >>>>> >>> can stick to >>> >>>>> use administrative to describe roaming if you like. >>>>> >>>>> Now, please see some comments on the text proposed. >>>>> >>>>> >>>>> BR, >>>>> Mohana >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Qin Wu [mailto:sunseawq@huawei.com] >>>>>> Sent: Thursday, September 10, 2009 8:30 PM >>>>>> To: Marco Liebsch; Basavaraj.Patil@nokia.com >>>>>> Cc: netext@ietf.org; Mohana Jeyatharan >>>>>> Subject: Re: [Netext] roaming issue-proposed text for >>>>>> >>>>> roaming section >>>>> >>>>>> Hi, all: >>>>>> Since folks has no objection to add a section to talk >>>>>> >>> about roaming >>> >>>>> issues. >>>>> >>>>>> I would like to propose >>>>>> some texts based on roaming picture proposed by Marco. >>>>>> >>> The proposed >>> >>>>> text >>>>> >>>>>> is as follows: >>>>>> " >>>>>> In the real PMIPv6 deployment, PMIPv6 components(e.g., >>>>>> >>> LMAs, MAGs) >>> >>>>> [Mohana: tied to a given MN] >>>>> >>>>> [Qin]:Okay. >>>>> >>>>> can be >>>>> >>>>>> distributed into different PMIPv6 domains >>>>>> >>>>> [Mohana: adminsitrative >>>>> domain. Example LMA placed in one administrative domain and MAG >>>>> placed in another administrative domain]. >>>>> >>>>> [Qin]: I think we have two choices to describe roaming: >>>>> 1) define administrative domain >>>>> 2) Separate PMIPv6 domains into PMIPv6 home domain and >>>>> >>> PMIPv6 visited >>> >>>>> domain Both can be used to describe roaming, in my mind. >>>>> >>>>> >>>>>> In order to support localized >>>>>> routing, it is required that MAGs to which MN and CN connect are >>>>>> >>>>> within >>>>> >>>>>> the same PMIPv6 domain [Mohana: within the same administrative >>>>>> >>>>> domain.]and each MAG setup security relationship >>>>> >>>>>> respectively with corresponding LMAs which maintain specific >>>>>> context >>>>>> >>>>> to >>>>> >>>>>> which MN and CN belong. It is not required that LMAs >>>>>> >>> anchored by MN >>> >>>>> and CN >>>>> >>>>>> are part of PMIPv6 domain [Mohana:administrative domain] as MAGs >>>>>> >>>>> attached by MN and CN. MN is allowed to >>>>> >>>>>> roam within its PMIPv6 domain (i.e, MN's home domain in >>>>>> >>>>> which MN's LMA >>>>> is >>>>> >>>>>> located) or over different PMIPv6 domains(i.e., MN's >>>>>> >>>>> visited domains). >>>>> >>>>> [Mohana: I would say MN is allowed to roam from home >>>>> >>> adminsitartive >>> >>>>> domain to visted administrative domain all tied to a single PMIPv6 >>>>> domain of Mn] >>>>> >>>>> [Qin]: see above. >>>>> >>>>> CN >>>>> >>>>>> should stay with MN within the same PMIPv6 domain [Mohana: >>>>>> >>>>> administrative domain]. >>>>> >>>>> >>>>> Figure x shows PMIPv6 >>>>> >>>>>> roaming cases where MAGs attached by MN and CN belong to the same >>>>>> >>>>> PMIPv6 >>>>> >>>>>> domain. In this figure, four PMIPv6 roaming cases need >>>>>> >>> to be taken >>> >>>>> into >>>>> >>>>>> account. >>>>>> Roaming case 1: >>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are >>>>>> >>>>> located >>>>> >>>>>> in the same PMIPv6 domain A as described in the figure 2. >>>>>> Roaming case 2: >>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located >>>>>> >>>>> in the same >>>>> >>>>>> PMIPv6 domain A while CN's LMA(LMA2') is located in the >>>>>> >>>>> PMIPv6 domain >>>>> B. >>>>> >>>>>> Roaming case 3: >>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the >>>>>> >>> PMIPv6 domain C >>> >>>>> while >>>>> >>>>>> MN's LMA(LMA1) and CN's LMA(LMA2) are located in the >>>>>> >>> PMIPv6 domain >>> >>>>>> A Roaming case 4: >>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the >>>>>> >>> PMIPv6 domain C >>> >>>>> while >>>>> >>>>>> MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's >>>>>> LMA(LMA2) >>>>>> >>>>> is >>>>> >>>>>> located in the PMIPv6 domain B >>>>>> >>>>>> " >>>>>> >>>>> [Mohana] I think, where description is made regarding MN and CN >>>>> placement in a certain PMIPv6 domain, it is better to say >>>>> >>> in the same >>> >>>>> administrative domain. >>>>> >>>>> [Qin] I think for now some people support this, some not. >>>>> >>>>> It is just that MN is roaming in its PMIPv6 domain and CN >>>>> >>> is roaming >>> >>>>> in its PMIPv6 domain, and local MAG routing canbe >>>>> >>> performed when MN's >>> >>>>> MAG and CN's MAG are the same or are placed in the same >>>>> >>> adminstrative >>> >>>>> domain. I think such things need to be captued. >>>>> >>>>> [Qin] Right. >>>>> >>>>> >>>>> -------------------------------------------------------------- >>>>> ---------- >>>>> -- >>>>> >>>>>> ------ >>>>>> >>>>>> >>>>>> >>>>>>> | >>>>>>> +-----+ +-----+ | +-----+ >>>>>>> |LMA1 | |LMA2 | | |LMA2'| >>>>>>> +-----+ +-----+ | +-----+ >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> +-----+ +-----+ | >>>>>>> |MAG1 | |MAG2 | | >>>>>>> +-----+ +-----+ | >>>>>>> | >>>>>>> | >>>>>>> A | B >>>>>>> >>>>>>> >>>>> ------------------------------+------------------------------- >>>>> >>>>>>> C >>>>>>> >>>>>>> >>>>>>> +-----+ +-----+ >>>>>>> |MAG1'| |MAG2'| >>>>>>> +-----+ +-----+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> -------------------------------------------------------------- >>>>> ---------- >>>>> -- >>>>> >>>>>> ------ >>>>>> >>>>>> If people prefer to use administrative domain, we can replace all >>>>>> >>>>> PMIPv6 >>>>> >>>>>> domain in the proposed text with *administrative domain*, >>>>>> >>>>> Welcome your >>>>> >>>>>> bash,:-) >>>>>> Regards! >>>>>> -Qin >>>>>> ----- Original Message ----- >>>>>> From: "Marco Liebsch" >>>>>> To: >>>>>> Cc: ; >>>>>> Sent: Wednesday, September 09, 2009 11:07 PM >>>>>> Subject: Re: [netext] [Netext] localized route optimization >>>>>> >>>>> - roaming >>>>> >>>>>> issue >>>>>> >>>>>> >>>>>> >>>>>>> Hi Raj, >>>>>>> >>>>>>> yes, agreed, that's why it has been proposed to add a >>>>>>> >>> section on >>> >>>>> this in >>>>> >>>>>>> the PS. The picture >>>>>>> could be based on what I sent some mails ago. We're currently >>>>>>> >>>>> preparing >>>>> >>>>>>> some text, but >>>>>>> I think it makes sense to discuss and agree on the >>>>>>> >>> text before it >>> >>>>> goes >>>>> >>>>>>> to the PS draft. >>>>>>> >>>>>>> marco >>>>>>> >>>>>>> Basavaraj.Patil@nokia.com wrote: >>>>>>> >>>>>>>> Hi Marco, >>>>>>>> >>>>>>>> One of the issues that we got hung up at IETF75 during the LR >>>>>>>> >>>>>> discussion was >>>>>> >>>>>>>> on roaming. It would be good to have a clear >>>>>>>> >>> description of the >>> >>>>>> relationship >>>>>> >>>>>>>> between the MAG and LMA in the context of a PMIP6 domain >>>>>>>> >>>>> especially >>>>> >>>>>> when you >>>>>> >>>>>>>> consider home and visited network scenarios wherein >>>>>>>> >>> the MAG/LMA >>> >>>>>> entities are >>>>>> >>>>>>>> in different domains. >>>>>>>> >>>>>>>> The PMIP6 domain definition in RFC5213: >>>>>>>> " >>>>>>>> Proxy Mobile IPv6 domain refers to the network where the >>>>>>>> >>>>> mobility >>>>> >>>>>>>> management of a mobile node is handled using the >>>>>>>> >>>>> Proxy Mobile >>>>> >>>>>> IPv6 >>>>>> >>>>>>>> protocol as defined in this specification. The >>>>>>>> >>>>> Proxy Mobile >>>>> IPv6 >>>>> >>>>>>>> domain includes local mobility anchors and mobile access >>>>>>>> >>>>> gateways >>>>> >>>>>>>> between which security associations can be set up and >>>>>>>> authorization for sending Proxy Binding Updates on >>>>>>>> >>>>> behalf of >>>>> the >>>>> >>>>>>>> mobile nodes can be ensured. >>>>>>>> " >>>>>>>> >>>>>>>> does not have any references to home/visited network >>>>>>>> >>>>> concepts. The >>>>> only >>>>> >>>>>>>> criteria for an entity (MAG/LMA) being considered >>>>>>>> >>> being a part >>> >>>>>>>> of >>>>>>>> >>>>> the >>>>> >>>>>> PMIP6 >>>>>> >>>>>>>> domain is the existence of a security association. It >>>>>>>> >>>>> would be good >>>>> to >>>>> >>>>>>>> elaborate how this maps to the current discussion in LR. >>>>>>>> >>>>>>>> -Raj >>>>>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>>>> >>>> _______________________________________________ >>>> netext mailing list >>>> netext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netext >>>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From sunseawq@huawei.com Wed Sep 16 05:22:40 2009 Return-Path: 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 972063A689F for ; Wed, 16 Sep 2009 05:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 FlhVkw0hxJWA for ; Wed, 16 Sep 2009 05:22:39 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8E4B23A6869 for ; Wed, 16 Sep 2009 05:22:38 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ2005PZD2TTT@szxga04-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 20:23:17 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ200MIKD2TCF@szxga04-in.huawei.com> for netext@ietf.org; Wed, 16 Sep 2009 20:23:17 +0800 (CST) Received: from 756BFB16836341A ([220.114.92.129]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ2003Z1D2IDK@szxml01-in.huawei.com>; Wed, 16 Sep 2009 20:23:17 +0800 (CST) Date: Wed, 16 Sep 2009 20:23:29 +0800 From: Qin Wu To: Marco Liebsch Message-id: <006d01ca36c8$84a845e0$2101a8c0@756BFB16836341A> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> <00dc01ca367a$01c18450$260ca40a@china.huawei.com> <4AB0BA63.9020507@nw.neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 12:22:40 -0000 Hi, Marco: ----- Original Message ----- From: "Marco Liebsch" To: "Qin Wu" Cc: "Koodli, Rajeev" ; Sent: Wednesday, September 16, 2009 6:13 PM Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection > Hi Qin, > > please see inline for my view. > > Qin Wu schrieb: >> Hi, >> ----- Original Message ----- >> From: "Koodli, Rajeev" >> To: >> Sent: Wednesday, September 16, 2009 10:39 AM >> Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection >> >> >> >>> Hi, >>> >>> >>>> [Qin]: So I think if policy governing the SLA can afffect >>>> localized routing directly, the MN's MAG and MN's LMA should >>>> belong to different domain. >>>> In this sense, if MN's MAG and MN's LMA are located in the >>>> same domain, SLA policy can not affect localize routing, am I right? >>>> >>> Well, typically SLAs are between provider domains; at least that's how I >>> was referring to. >>> >> >> [Qin]: I agree. >> >> >>>> Furthermore, besides SLA policy, I think there are other >>>> policies that also affect localized routing e.g., in roaming >>>> scenario even though MAG and LMA are located in the same >>>> domain, having SA between MAG and LMA does not mean localized >>>> routing can be performed, because use of local routing may be >>>> subject to accounting and routing policies relating to the >>>> mobile node, , therefore localized routing signaling between >>>> MAG and LMA is required to negotiate localized routing policy >>>> information and enable/disable localized routing. Am I right? >>>> >>>> >>> Yes, localized routing is subject to policy constraints regardless of >>> roaming. >>> >>> My point was specific to roaming when the policy allows a MAG to provide >>> localized routing. >>> >>> I do not think we need to design signaling for exchanging this policy, >>> with or without roaming. >>> >> >> [Qin]: Okay, that is to say information exchange between MAG and LMA is required, >> But the information is not necessary to be taken as any policy. am I right? >> > I don't think the protocol should not be used to echange policies, which > even does not make > sense to me to transfer e.g. provider policies beyond domains, as the > remote provider may > have different policies. I think components (LMA, MAG) must operate > according to their > provider's policy and the protocols should just reflect the policy by > means of requests > to set up localized routing, which can be accepted or not and indicated > accordingly in a > status/reason code. [Qin]: Right, that is to say, policy from different providers may affect localized routing, but it is not necessary to be reflected in the protocol design. policy enforcement information or instructions can be encapsulated in the localized routing signaling to indicate results to the MAGs. Whether we use status or reason code, it depends on specific the implementation. >> >>> Since LMA is the control entity, we can assume it to exert such policy >>> control by instructing the MAG to provide localized routing. >>> >> >> [Qin]: I am wondering whether instructing the MAG to or not to provide localized routing >> (i.e., enable/disable localized routing) can be viewed as *policy*? >> > I think it's more that the LMA acts according to it's operator's policy. > If the policy does not permit > localized routing, the LMA would not send the request. The > instruction/request itself does not > convey policies, as I understand from your question. This is my view. [Qin]: Well, I agree it is not policies but policies enforcement results that need to be exchanged. > marco > >> >>> Regards, >>> >>> -Rajeev >>> >>> >>> >>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> >>>>> -Rajeev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: netext-bounces@ietf.org >>>>>> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu >>>>>> Sent: Tuesday, September 15, 2009 1:22 AM >>>>>> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com >>>>>> Cc: netext@ietf.org >>>>>> Subject: Re: [netext] [Netext] roaming issue-proposed text for >>>>>> roamingsection >>>>>> >>>>>> Hi, Mohana: >>>>>> Thank for your reply. >>>>>> ----- Original Message ----- >>>>>> From: "Mohana Jeyatharan" >>>>>> To: "Qin Wu" ; "Marco Liebsch" >>>>>> ; >>>>>> Cc: >>>>>> Sent: Tuesday, September 15, 2009 3:45 PM >>>>>> Subject: RE: [Netext] roaming issue-proposed text for >>>>>> >>>> roaming section >>>> >>>>>> Hi Qin, >>>>>> >>>>>> Sorry wanted to comment on your text, but here are some comments. >>>>>> >>>>>> I think we should stick to the definition of PMIPv6 domain >>>>>> >>>> as in RFC >>>> >>>>>> 5213 and not change it. That is, as long as the MAG-LMA >>>>>> >>>> tunnel can be >>>> >>>>>> created, it is considered as one PMIPv6 domain of MN. >>>>>> >>>>>> [Qin]: you are right, wherever MN moves around, MN does not change >>>>>> the PMIPv6 domain to which MN belongs, i.e., MN's home >>>>>> >>>> PMIPv6 domain. >>>> >>>>>> While being attached to such PMIPv6 domain, the MN may change >>>>>> administrative domain. >>>>>> i.e. move from home domain to another administrative >>>>>> >>>> domain (foreign >>>> >>>>>> domain). >>>>>> >>>>>> [Qin]: Another administrative domain you mentioned above can be >>>>>> viewed as MN's visited PMIPv6 domain. >>>>>> that is to say, although MN changes from one visited >>>>>> >>>> PMIPv6 domain to >>>> >>>>>> another, MN does not change its home >>>>>> PMIPv6 domain, does this sounds reasonable? Anyway, you >>>>>> >>>> can stick to >>>> >>>>>> use administrative to describe roaming if you like. >>>>>> >>>>>> Now, please see some comments on the text proposed. >>>>>> >>>>>> >>>>>> BR, >>>>>> Mohana >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Qin Wu [mailto:sunseawq@huawei.com] >>>>>>> Sent: Thursday, September 10, 2009 8:30 PM >>>>>>> To: Marco Liebsch; Basavaraj.Patil@nokia.com >>>>>>> Cc: netext@ietf.org; Mohana Jeyatharan >>>>>>> Subject: Re: [Netext] roaming issue-proposed text for >>>>>>> >>>>>> roaming section >>>>>> >>>>>>> Hi, all: >>>>>>> Since folks has no objection to add a section to talk >>>>>>> >>>> about roaming >>>> >>>>>> issues. >>>>>> >>>>>>> I would like to propose >>>>>>> some texts based on roaming picture proposed by Marco. >>>>>>> >>>> The proposed >>>> >>>>>> text >>>>>> >>>>>>> is as follows: >>>>>>> " >>>>>>> In the real PMIPv6 deployment, PMIPv6 components(e.g., >>>>>>> >>>> LMAs, MAGs) >>>> >>>>>> [Mohana: tied to a given MN] >>>>>> >>>>>> [Qin]:Okay. >>>>>> >>>>>> can be >>>>>> >>>>>>> distributed into different PMIPv6 domains >>>>>>> >>>>>> [Mohana: adminsitrative >>>>>> domain. Example LMA placed in one administrative domain and MAG >>>>>> placed in another administrative domain]. >>>>>> >>>>>> [Qin]: I think we have two choices to describe roaming: >>>>>> 1) define administrative domain >>>>>> 2) Separate PMIPv6 domains into PMIPv6 home domain and >>>>>> >>>> PMIPv6 visited >>>> >>>>>> domain Both can be used to describe roaming, in my mind. >>>>>> >>>>>> >>>>>>> In order to support localized >>>>>>> routing, it is required that MAGs to which MN and CN connect are >>>>>>> >>>>>> within >>>>>> >>>>>>> the same PMIPv6 domain [Mohana: within the same administrative >>>>>>> >>>>>> domain.]and each MAG setup security relationship >>>>>> >>>>>>> respectively with corresponding LMAs which maintain specific >>>>>>> context >>>>>>> >>>>>> to >>>>>> >>>>>>> which MN and CN belong. It is not required that LMAs >>>>>>> >>>> anchored by MN >>>> >>>>>> and CN >>>>>> >>>>>>> are part of PMIPv6 domain [Mohana:administrative domain] as MAGs >>>>>>> >>>>>> attached by MN and CN. MN is allowed to >>>>>> >>>>>>> roam within its PMIPv6 domain (i.e, MN's home domain in >>>>>>> >>>>>> which MN's LMA >>>>>> is >>>>>> >>>>>>> located) or over different PMIPv6 domains(i.e., MN's >>>>>>> >>>>>> visited domains). >>>>>> >>>>>> [Mohana: I would say MN is allowed to roam from home >>>>>> >>>> adminsitartive >>>> >>>>>> domain to visted administrative domain all tied to a single PMIPv6 >>>>>> domain of Mn] >>>>>> >>>>>> [Qin]: see above. >>>>>> >>>>>> CN >>>>>> >>>>>>> should stay with MN within the same PMIPv6 domain [Mohana: >>>>>>> >>>>>> administrative domain]. >>>>>> >>>>>> >>>>>> Figure x shows PMIPv6 >>>>>> >>>>>>> roaming cases where MAGs attached by MN and CN belong to the same >>>>>>> >>>>>> PMIPv6 >>>>>> >>>>>>> domain. In this figure, four PMIPv6 roaming cases need >>>>>>> >>>> to be taken >>>> >>>>>> into >>>>>> >>>>>>> account. >>>>>>> Roaming case 1: >>>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are >>>>>>> >>>>>> located >>>>>> >>>>>>> in the same PMIPv6 domain A as described in the figure 2. >>>>>>> Roaming case 2: >>>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located >>>>>>> >>>>>> in the same >>>>>> >>>>>>> PMIPv6 domain A while CN's LMA(LMA2') is located in the >>>>>>> >>>>>> PMIPv6 domain >>>>>> B. >>>>>> >>>>>>> Roaming case 3: >>>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the >>>>>>> >>>> PMIPv6 domain C >>>> >>>>>> while >>>>>> >>>>>>> MN's LMA(LMA1) and CN's LMA(LMA2) are located in the >>>>>>> >>>> PMIPv6 domain >>>> >>>>>>> A Roaming case 4: >>>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the >>>>>>> >>>> PMIPv6 domain C >>>> >>>>>> while >>>>>> >>>>>>> MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's >>>>>>> LMA(LMA2) >>>>>>> >>>>>> is >>>>>> >>>>>>> located in the PMIPv6 domain B >>>>>>> >>>>>>> " >>>>>>> >>>>>> [Mohana] I think, where description is made regarding MN and CN >>>>>> placement in a certain PMIPv6 domain, it is better to say >>>>>> >>>> in the same >>>> >>>>>> administrative domain. >>>>>> >>>>>> [Qin] I think for now some people support this, some not. >>>>>> >>>>>> It is just that MN is roaming in its PMIPv6 domain and CN >>>>>> >>>> is roaming >>>> >>>>>> in its PMIPv6 domain, and local MAG routing canbe >>>>>> >>>> performed when MN's >>>> >>>>>> MAG and CN's MAG are the same or are placed in the same >>>>>> >>>> adminstrative >>>> >>>>>> domain. I think such things need to be captued. >>>>>> >>>>>> [Qin] Right. >>>>>> >>>>>> >>>>>> -------------------------------------------------------------- >>>>>> ---------- >>>>>> -- >>>>>> >>>>>>> ------ >>>>>>> >>>>>>> >>>>>>> >>>>>>>> | >>>>>>>> +-----+ +-----+ | +-----+ >>>>>>>> |LMA1 | |LMA2 | | |LMA2'| >>>>>>>> +-----+ +-----+ | +-----+ >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> +-----+ +-----+ | >>>>>>>> |MAG1 | |MAG2 | | >>>>>>>> +-----+ +-----+ | >>>>>>>> | >>>>>>>> | >>>>>>>> A | B >>>>>>>> >>>>>>>> >>>>>> ------------------------------+------------------------------- >>>>>> >>>>>>>> C >>>>>>>> >>>>>>>> >>>>>>>> +-----+ +-----+ >>>>>>>> |MAG1'| |MAG2'| >>>>>>>> +-----+ +-----+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> -------------------------------------------------------------- >>>>>> ---------- >>>>>> -- >>>>>> >>>>>>> ------ >>>>>>> >>>>>>> If people prefer to use administrative domain, we can replace all >>>>>>> >>>>>> PMIPv6 >>>>>> >>>>>>> domain in the proposed text with *administrative domain*, >>>>>>> >>>>>> Welcome your >>>>>> >>>>>>> bash,:-) >>>>>>> Regards! >>>>>>> -Qin >>>>>>> ----- Original Message ----- >>>>>>> From: "Marco Liebsch" >>>>>>> To: >>>>>>> Cc: ; >>>>>>> Sent: Wednesday, September 09, 2009 11:07 PM >>>>>>> Subject: Re: [netext] [Netext] localized route optimization >>>>>>> >>>>>> - roaming >>>>>> >>>>>>> issue >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Raj, >>>>>>>> >>>>>>>> yes, agreed, that's why it has been proposed to add a >>>>>>>> >>>> section on >>>> >>>>>> this in >>>>>> >>>>>>>> the PS. The picture >>>>>>>> could be based on what I sent some mails ago. We're currently >>>>>>>> >>>>>> preparing >>>>>> >>>>>>>> some text, but >>>>>>>> I think it makes sense to discuss and agree on the >>>>>>>> >>>> text before it >>>> >>>>>> goes >>>>>> >>>>>>>> to the PS draft. >>>>>>>> >>>>>>>> marco >>>>>>>> >>>>>>>> Basavaraj.Patil@nokia.com wrote: >>>>>>>> >>>>>>>>> Hi Marco, >>>>>>>>> >>>>>>>>> One of the issues that we got hung up at IETF75 during the LR >>>>>>>>> >>>>>>> discussion was >>>>>>> >>>>>>>>> on roaming. It would be good to have a clear >>>>>>>>> >>>> description of the >>>> >>>>>>> relationship >>>>>>> >>>>>>>>> between the MAG and LMA in the context of a PMIP6 domain >>>>>>>>> >>>>>> especially >>>>>> >>>>>>> when you >>>>>>> >>>>>>>>> consider home and visited network scenarios wherein >>>>>>>>> >>>> the MAG/LMA >>>> >>>>>>> entities are >>>>>>> >>>>>>>>> in different domains. >>>>>>>>> >>>>>>>>> The PMIP6 domain definition in RFC5213: >>>>>>>>> " >>>>>>>>> Proxy Mobile IPv6 domain refers to the network where the >>>>>>>>> >>>>>> mobility >>>>>> >>>>>>>>> management of a mobile node is handled using the >>>>>>>>> >>>>>> Proxy Mobile >>>>>> >>>>>>> IPv6 >>>>>>> >>>>>>>>> protocol as defined in this specification. The >>>>>>>>> >>>>>> Proxy Mobile >>>>>> IPv6 >>>>>> >>>>>>>>> domain includes local mobility anchors and mobile access >>>>>>>>> >>>>>> gateways >>>>>> >>>>>>>>> between which security associations can be set up and >>>>>>>>> authorization for sending Proxy Binding Updates on >>>>>>>>> >>>>>> behalf of >>>>>> the >>>>>> >>>>>>>>> mobile nodes can be ensured. >>>>>>>>> " >>>>>>>>> >>>>>>>>> does not have any references to home/visited network >>>>>>>>> >>>>>> concepts. The >>>>>> only >>>>>> >>>>>>>>> criteria for an entity (MAG/LMA) being considered >>>>>>>>> >>>> being a part >>>> >>>>>>>>> of >>>>>>>>> >>>>>> the >>>>>> >>>>>>> PMIP6 >>>>>>> >>>>>>>>> domain is the existence of a security association. It >>>>>>>>> >>>>>> would be good >>>>>> to >>>>>> >>>>>>>>> elaborate how this maps to the current discussion in LR. >>>>>>>>> >>>>>>>>> -Raj >>>>>>>>> >>>>>> _______________________________________________ >>>>>> netext mailing list >>>>>> netext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netext >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >>> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >> > > > From rkoodli@starentnetworks.com Wed Sep 16 09:13:09 2009 Return-Path: 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 BE91828C240 for ; Wed, 16 Sep 2009 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 dOt9WH+OwTEP for ; Wed, 16 Sep 2009 09:13:09 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id 0A56E28C188 for ; Wed, 16 Sep 2009 09:13:08 -0700 (PDT) X-ASG-Debug-ID: 1253117635-4865000f0006-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 1F488EFC036 for ; Wed, 16 Sep 2009 12:13:56 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id 3ltl2I2bg8XwOIpk for ; Wed, 16 Sep 2009 12:13:56 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Sep 2009 12:12:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] [Netext] roaming issue-proposed text for roamingsection Date: Wed, 16 Sep 2009 12:12:28 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660BDFF8FC@exchtewks3.starentnetworks.com> In-Reply-To: <00dc01ca367a$01c18450$260ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [Netext] roaming issue-proposed text for roamingsection Thread-Index: Aco2edKdwHMFbk53SBGAsmSDYDdiQwAbyYxA References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> <00dc01ca367a$01c18450$260ca40a@china.huawei.com> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 16 Sep 2009 16:12:28.0252 (UTC) FILETIME=[7C7F71C0:01CA36E8] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1253117636 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 16:13:09 -0000 =20 > > I do not think we need to design signaling for exchanging this policy,=20 > > with or without roaming. >=20 > [Qin]: Okay, that is to say information exchange between MAG=20 > and LMA is required, But the information is not necessary to=20 > be taken as any policy. am I right? Not sure what you mean. The signaling is for establishing localized routing, which is subject to policy constraints. We do not design policy exchange signaling here.=20 =20 > > Since LMA is the control entity, we can assume it to exert such policy=20 > > control by instructing the MAG to provide localized routing. >=20 > [Qin]: I am wondering whether instructing the MAG to or not=20 > to provide localized routing (i.e., enable/disable localized=20 > routing) can be viewed as *policy*? The trigger for LMA to initiate LR could be policy, yes. -Rajeev From behcetsarikaya@yahoo.com Wed Sep 16 09:16:43 2009 Return-Path: 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 BD3D328C24D for ; Wed, 16 Sep 2009 09:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 FajrQ03NYzfX for ; Wed, 16 Sep 2009 09:16:42 -0700 (PDT) Received: from web111402.mail.gq1.yahoo.com (web111402.mail.gq1.yahoo.com [67.195.15.138]) by core3.amsl.com (Postfix) with SMTP id 061F428C258 for ; Wed, 16 Sep 2009 09:16:40 -0700 (PDT) Received: (qmail 79992 invoked by uid 60001); 16 Sep 2009 16:17:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253117848; bh=/A/304sqozQR3ClWSSBz58tB/ztkzUxIFGPTDEmdpJI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MYplhv81yEbFhD8VN65umm182uaK+PWyQ230CDFvWSlQRJ1Rv10JkmO5JzmC1pZihSWd0lkv3H4WThVQYn2dbZm8eoP2KUwLi7Hk6e6w1Rkm7XI/D97y4uRBU+4nu8S348ZnMxMPZaNdbbFuMs1+fHJOGdg+A9JJOvPtMG2ZR5k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FicdZDO7rfhH3hoeMdZxMEX9HGWfvimFTChliMqbsS30/s4IFkvaLjuaytsmKD3nUtPm5OaCp654Re1EB+FGAS7F8g0WGv92BZBx84GqgWajREN9KeagjiaIlMpVvTurj9dcgEVERR+/SEW0EG7YA/8fARqfng5Y8FSG3EdI7Kk=; Message-ID: <566468.79298.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: izUUqgEVM1nZcw34B0EBCry3ZfvPNWhlb4GtjJpCvkL3_EZ4YRyGYcVCAxR8mASDYj2mkX7FXGJdaIBThyBtQvnOq3kokvhZUAXWBRUb48HRl6f6OYKCF6jL0jmWX8UXUPi1a2jQCKvvjy_OCRmlN1kvRhuBlUzyzXd4zM2Rc2ZnbSO11aszfJ5dQcEwxRKpbd98mnnziDDSuZL7hXTuJImRzHuAWDQ8ID8.jYKZ_MBOgWVTDoSv3HNluF.l63D74.WVsASF9isTd0YZAmpQQIRmvymA4sDVLunrTwTll9DqORLCNzfHJ3XiWQ-- Received: from [206.16.17.212] by web111402.mail.gq1.yahoo.com via HTTP; Wed, 16 Sep 2009 09:17:28 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 References: <005a01ca366b$6c3bf630$110ca40a@china.huawei.com> Date: Wed, 16 Sep 2009 09:17:28 -0700 (PDT) From: Behcet Sarikaya To: jouni korhonen In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 16:16:43 -0000 Hi Jouni, I noticed that you defined: Redirect-Capability Mobility Option such an option to me seems more like AAA issue and as such it should go to dime or radext. In RFC 5213, PCOs are defined such as EnableMAGLocalRouting for similar purposes. Regards, Behcet ----- Original Message ---- > From: jouni korhonen > To: w52006@huawei.com > Cc: netext@ietf.org > Sent: Wednesday, September 16, 2009 12:53:47 AM > Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 > > Hi, > > Thanks for feedback. See some answers inline. > > > On Sep 16, 2009, at 4:17 AM, Yungui Wang wrote: > > > Hello > > > > That's okey. There are other two minor comments. > > > > 1, I think, the 'Redirect-Capability Mobility Option' is not essential. In > > my understanding, the common MIP/PMIP system has provided the general > > capability negotiation mechanism. That's, if there is an extended mobility > > By common capability negotiation mechanism do you mean flags in PBU/PBA headers? > If so, it was a design choice not to allocate more of those. > > > option is not supported or identified, the receiver can just discard it > > silently. Isn't it? On the other side, even if the LMA doesn't return the > > The current design makes use of this behavior that LMAs silently ignore mobility > options they do not understand. In that way a MAG supporting redirection and a > LMA not supporting redirection can fallback to RFC5213 normal operation. > > > 'Redirect Mobility Option', for implementation, the MAG which has enabled > > the redirection function may re-register the MN to another LMA when it > > receives a failed PBA, e.g. 130. > > This is of course possible already within RFC5213 scope but that is a MAG > implementation specific fallback operation rather than a guided redirection. > > > Therefore, for simplification, the capability option can be removed. > > Hmmm.. I don't fully agree with this. The Redirect-Capability option is also > used as an indication from a MAG if it wants to be redirected or not. Also we > currently embed IPv4 information on that option. Of course this could be > achieved with PBU/PBA flags but so far I am not convinced that those would be > better than using a mobility option. > > > > > 2, I can't catch the logic of SA check described in the section 5.3.2. (at > > the 3th and 4th paragraph) > > In my understanding, if there is no SA between the MAG and the r2LMA, how > > can the r2LMA accept the PBU and create the mobility session at before? On > > Good point. This is an obvious error and needs to be fixed. > > > > the other hand, the SA check is necessary to another case described in 5.4. > > However, I don't see how the MAG does that. Are there some local policies on > > the MAG, or does the MAG check it according to the MN's profile downloaded > > from policy store, or ...? > > The MAG is supposed to know with whom it has SAs with by configuration. That > would be a normal SAD/SPD lookup. If none of the existing SAs match, then either > the PBU/PBA exchange fails or the dynamic creation of the SA is initiated. > > > Cheers, > Jouni > > > > > B.R. > > Yungui > > > >> -----Original Message----- > >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] > >> Sent: Tuesday, September 15, 2009 6:11 PM > >> To: w52006@huawei.com > >> Cc: netext@ietf.org > >> Subject: Re: [netext] FW: New Version Notification > >> fordraft-korhonen-netext-redirect-03 > >> > >> Hi, > >> > >> On Sep 15, 2009, at 11:33 AM, Yungui Wang wrote: > >> > >>> Hello Jouni > >>> > >>> It is observed that the assigned r2LMA would be > >> stored/updated into > >>> the MN's > >>> profile on the policy store. May I know when it happens and > >> who does? > >> > >> Yes, r2LMA information would be stored into the policy > >> profile. On the > >> MAG side this would happen when the PBA containing the Redirect > >> mobility option arrives. If the remote policy store needs to be > >> updated, it would be done e.g. by r2LMA using the LMA-HAAA interface > >> described in draft-ietf-dime-pmip6. > >> > >> I will add some text to the I-D regarding the policy profile update. > >> > >> Cheers, > >> Jouni > >> > >> > >>> > >>> B.R. > >>> Yungui > >>> > >>> > >>>> -----Original Message----- > >>>> From: netext-bounces@ietf.org > >>>> [mailto:netext-bounces@ietf.org] On Behalf Of jouni korhonen > >>>> Sent: Tuesday, September 15, 2009 3:24 PM > >>>> To: netext@ietf.org > >>>> Subject: [netext] FW: New Version Notification > >>>> fordraft-korhonen-netext-redirect-03 > >>>> > >>>> FYI > >>>> > >>>> We submitted an updated version of the Runtime LMA Assignment I-D a > >>>> while ago. This revision should address the comments we received in > >>>> Stockholm or at least add the basis for further work on > >> those areas. > >>>> > >>>> Cheers, > >>>> Jouni > >>>> > >>>> > >>>> > >>>> Begin forwarded message: > >>>> > >>>>> From: IETF I-D Submission Tool > >>>>> Date: September 10, 2009 1:59:06 AM GMT+03:00 > >>>>> To: jouni.nospam@gmail.com > >>>>> Cc: sri.gundavelli@cisco.com,yokota@kddilabs.jp > >>>>> Subject: New Version Notification for draft-korhonen-netext- > >>>>> redirect-03 > >>>>> > >>>>> > >>>>> A new version of I-D, draft-korhonen-netext-redirect-03.txt > >>>> has been > >>>>> successfuly submitted by Jouni Korhonen and posted to the IETF > >>>>> repository. > >>>>> > >>>>> Filename: draft-korhonen-netext-redirect > >>>>> Revision: 03 > >>>>> Title: Runtime LMA Assignment Support for > >>>> Proxy Mobile IPv6 > >>>>> Creation_date: 2009-09-10 > >>>>> WG ID: Independent Submission > >>>>> Number_of_pages: 23 > >>>>> > >>>>> Abstract: > >>>>> This document describes a redirect functionality and corresponding > >>>>> mobility options for Proxy Mobile IPv6. The redirect > >> functionality > >>>>> allows a dynamic runtime assignment of a Local Mobility Anchor and > >>>>> redirecting the mobility session to the assigned Local Mobility > >>>>> Anchor. > >>>>> > >>>>> > >>>>> > >>>>> The IETF Secretariat. > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>>> > >>> > >> > > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@starentnetworks.com Wed Sep 16 09:23:19 2009 Return-Path: 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 8A92228C13C for ; Wed, 16 Sep 2009 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 xaEALVqUkeb0 for ; Wed, 16 Sep 2009 09:23:18 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id B9A5D3A67A4 for ; Wed, 16 Sep 2009 09:23:17 -0700 (PDT) X-ASG-Debug-ID: 1253118247-5709000a0000-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 2FEB2EFC036 for ; Wed, 16 Sep 2009 12:24:07 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id kxQtpaxm450GEExt for ; Wed, 16 Sep 2009 12:24:07 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Sep 2009 12:22:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] [Netext] roaming issue-proposed text for roaming section Date: Wed, 16 Sep 2009 12:22:41 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660BE8F982@exchtewks3.starentnetworks.com> In-Reply-To: <4AB0A8C6.2080600@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [Netext] roaming issue-proposed text for roaming section Thread-Index: Aco2q7so3I2baggqRJ+7nyW95YuXfAAPgScg References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <4AB0A8C6.2080600@nw.neclab.eu> From: "Koodli, Rajeev" To: X-OriginalArrivalTime: 16 Sep 2009 16:22:40.0851 (UTC) FILETIME=[E9A2A230:01CA36E9] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1253118247 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Subject: Re: [netext] [Netext] roaming issue-proposed text for roaming section 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 16:23:19 -0000 =20 Hi, > > 2. No new definitions of "domain" > > =20 > Which domain? If it's PMIPv6 domain, I agree and it's covered by 1. Any domain. We should not be re-inventing any domain definitions.=20 > > 3. Roaming is simply defined as "access to the Internet when the MAG > > and LMA are in different provider domains" > > =20 > Provider domain is a new term on the table in the context of=20 > this discussion. > Do we need to define it? Or is it clear, so we can just use=20 > it? I think the Provider domain is what we so far considered=20 > as Administrative domain,. I see your point. Provider domain is what belongs to a provider. It is most relevant for roaming. I am okay if you state it.=20 > > 5. We need to state somewhere that for the roaming case, localized=20 > > routing is subject to policy governing the service level agreements=20 > > between the providers. This means that merely having an SA between a > > (visited) MAG and a (home) LMA does not translate to enabling=20 > > localized routing when (at least) one of the MN's is roaming. > > =20 > I think that all involved (home) LMAs needs to show green=20 > light for establishing localized routing between the MNs. And=20 > what RFC5213 sais in the context of single-MAG local routing=20 > is, that the LMA should control the setup. So, the LMA could=20 > initiate localized routing at a MAG in the visited network.=20 > According to the policy of the visited provider domain, the=20 > MAG can either accept or reject localized routing. Localized=20 > routing will be successful when both LMAs and both MAGs=20 > accept localized routing. Agree to LMA initiating the LR. Policy is not limited to visited network only (this is not a protocol issue for us BTW). The home LMA may not initiate LR if the policy does not allow.=20 >=20 > For the protocol spec, I think we just need to consider=20 > status codes which allow LMAs/MAGs to *negative ack* a=20 > request to establish locaized routing. That reflects the SLAs=20 > on the mobility protocol layer. I don't think that the=20 > localized routing protocol needs to handle SLAs itself. >=20 Agree, the LR design itself should not deal with any SLAs. -Rajeev =20 > Hope that makes sense. >=20 > marco >=20 > > What do you think? > > > > Regards, > > > > -Rajeev > > > > > > =20 > > > > > > =20 > >> -----Original Message----- > >> From: netext-bounces@ietf.org > >> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu > >> Sent: Tuesday, September 15, 2009 1:22 AM > >> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com > >> Cc: netext@ietf.org > >> Subject: Re: [netext] [Netext] roaming issue-proposed text for=20 > >> roamingsection > >> > >> Hi, Mohana: > >> Thank for your reply. > >> ----- Original Message ----- > >> From: "Mohana Jeyatharan" > >> To: "Qin Wu" ; "Marco Liebsch"=20 > >> ; > >> Cc: > >> Sent: Tuesday, September 15, 2009 3:45 PM > >> Subject: RE: [Netext] roaming issue-proposed text for=20 > roaming section > >> > >> > >> Hi Qin, > >> > >> Sorry wanted to comment on your text, but here are some comments. =20 > >> > >> I think we should stick to the definition of PMIPv6 domain=20 > as in RFC > >> 5213 and not change it. That is, as long as the MAG-LMA=20 > tunnel can be=20 > >> created, it is considered as one PMIPv6 domain of MN. > >> > >> [Qin]: you are right, wherever MN moves around, MN does not change=20 > >> the PMIPv6 domain to which MN belongs, i.e., MN's home=20 > PMIPv6 domain. > >> > >> While being attached to such PMIPv6 domain, the MN may change=20 > >> administrative domain. > >> i.e. move from home domain to another administrative=20 > domain (foreign=20 > >> domain). > >> > >> [Qin]: Another administrative domain you mentioned above can be=20 > >> viewed as MN's visited PMIPv6 domain. > >> that is to say, although MN changes from one visited=20 > PMIPv6 domain to=20 > >> another, MN does not change its home > >> PMIPv6 domain, does this sounds reasonable? Anyway, you=20 > can stick to=20 > >> use administrative to describe roaming if you like. > >> > >> Now, please see some comments on the text proposed. > >> > >> > >> BR, > >> Mohana > >> > >> =20 > >>> -----Original Message----- > >>> From: Qin Wu [mailto:sunseawq@huawei.com] > >>> Sent: Thursday, September 10, 2009 8:30 PM > >>> To: Marco Liebsch; Basavaraj.Patil@nokia.com > >>> Cc: netext@ietf.org; Mohana Jeyatharan > >>> Subject: Re: [Netext] roaming issue-proposed text for > >>> =20 > >> roaming section > >> =20 > >>> Hi, all: > >>> Since folks has no objection to add a section to talk=20 > about roaming > >>> =20 > >> issues. > >> =20 > >>> I would like to propose > >>> some texts based on roaming picture proposed by Marco.=20 > The proposed > >>> =20 > >> text > >> =20 > >>> is as follows: > >>> " > >>> In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) > >>> =20 > >> [Mohana: tied to a given MN] > >> > >> [Qin]:Okay. > >> > >> can be > >> =20 > >>> distributed into different PMIPv6 domains > >>> =20 > >> [Mohana: adminsitrative > >> domain. Example LMA placed in one administrative domain and MAG=20 > >> placed in another administrative domain]. > >> > >> [Qin]: I think we have two choices to describe roaming: > >> 1) define administrative domain > >> 2) Separate PMIPv6 domains into PMIPv6 home domain and=20 > PMIPv6 visited=20 > >> domain Both can be used to describe roaming, in my mind. > >> > >> =20 > >>> In order to support localized > >>> routing, it is required that MAGs to which MN and CN connect are > >>> =20 > >> within > >> =20 > >>> the same PMIPv6 domain [Mohana: within the same administrative > >>> =20 > >> domain.]and each MAG setup security relationship > >> =20 > >>> respectively with corresponding LMAs which maintain=20 > specific context > >>> =20 > >> to > >> =20 > >>> which MN and CN belong. It is not required that LMAs=20 > anchored by MN > >>> =20 > >> and CN > >> =20 > >>> are part of PMIPv6 domain [Mohana:administrative domain] as MAGs > >>> =20 > >> attached by MN and CN. MN is allowed to > >> =20 > >>> roam within its PMIPv6 domain (i.e, MN's home domain in > >>> =20 > >> which MN's LMA > >> is > >> =20 > >>> located) or over different PMIPv6 domains(i.e., MN's > >>> =20 > >> visited domains). > >> > >> [Mohana: I would say MN is allowed to roam from home=20 > adminsitartive=20 > >> domain to visted administrative domain all tied to a single PMIPv6=20 > >> domain of Mn] > >> > >> [Qin]: see above. > >> > >> CN > >> =20 > >>> should stay with MN within the same PMIPv6 domain [Mohana: > >>> =20 > >> administrative domain]. =20 > >> > >> > >> Figure x shows PMIPv6 > >> =20 > >>> roaming cases where MAGs attached by MN and CN belong to the same > >>> =20 > >> PMIPv6 > >> =20 > >>> domain. In this figure, four PMIPv6 roaming cases need to be taken > >>> =20 > >> into > >> =20 > >>> account. > >>> Roaming case 1: > >>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are > >>> =20 > >> located > >> =20 > >>> in the same PMIPv6 domain A as described in the figure 2. > >>> Roaming case 2: > >>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located > >>> =20 > >> in the same > >> =20 > >>> PMIPv6 domain A while CN's LMA(LMA2') is located in the > >>> =20 > >> PMIPv6 domain > >> B. > >> =20 > >>> Roaming case 3: > >>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the=20 > PMIPv6 domain C > >>> =20 > >> while > >> =20 > >>> MN's LMA(LMA1) and CN's LMA(LMA2) are located in the=20 > PMIPv6 domain A=20 > >>> Roaming case 4: > >>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the=20 > PMIPv6 domain C > >>> =20 > >> while > >> =20 > >>> MN's LMA(LMA1) is located in the PMIPv6 domain A, and=20 > CN's LMA(LMA2) > >>> =20 > >> is > >> =20 > >>> located in the PMIPv6 domain B > >>> > >>> " > >>> =20 > >> [Mohana] I think, where description is made regarding MN and CN=20 > >> placement in a certain PMIPv6 domain, it is better to say=20 > in the same=20 > >> administrative domain. > >> > >> [Qin] I think for now some people support this, some not. > >> > >> It is just that MN is roaming in its PMIPv6 domain and CN=20 > is roaming=20 > >> in its PMIPv6 domain, and local MAG routing canbe=20 > performed when MN's=20 > >> MAG and CN's MAG are the same or are placed in the same=20 > adminstrative=20 > >> domain. I think such things need to be captued. > >> > >> [Qin] Right. > >> > >> =20 > >> -------------------------------------------------------------- > >> ---------- > >> -- > >> =20 > >>> ------ > >>> > >>> > >>> =20 > >>>> | > >>>> +-----+ +-----+ | +-----+ > >>>> |LMA1 | |LMA2 | | |LMA2'| > >>>> +-----+ +-----+ | +-----+ > >>>> | > >>>> | > >>>> | > >>>> | > >>>> +-----+ +-----+ | > >>>> |MAG1 | |MAG2 | | > >>>> +-----+ +-----+ | > >>>> | > >>>> | > >>>> A | B > >>>> =20 > >>>> =20 > >> ------------------------------+------------------------------- > >> =20 > >>>> C > >>>> > >>>> > >>>> +-----+ +-----+ > >>>> |MAG1'| |MAG2'| > >>>> +-----+ +-----+ > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> =20 > >>> > >>> =20 > >> -------------------------------------------------------------- > >> ---------- > >> -- > >> =20 > >>> ------ > >>> > >>> If people prefer to use administrative domain, we can replace all > >>> =20 > >> PMIPv6 > >> =20 > >>> domain in the proposed text with *administrative domain*, > >>> =20 > >> Welcome your > >> =20 > >>> bash,:-) > >>> Regards! > >>> -Qin > >>> ----- Original Message ----- > >>> From: "Marco Liebsch" > >>> To: > >>> Cc: ; > >>> Sent: Wednesday, September 09, 2009 11:07 PM > >>> Subject: Re: [netext] [Netext] localized route optimization > >>> =20 > >> - roaming > >> =20 > >>> issue > >>> > >>> > >>> =20 > >>>> Hi Raj, > >>>> > >>>> yes, agreed, that's why it has been proposed to add a section on > >>>> =20 > >> this in > >> =20 > >>>> the PS. The picture > >>>> could be based on what I sent some mails ago. We're currently > >>>> =20 > >> preparing > >> =20 > >>>> some text, but > >>>> I think it makes sense to discuss and agree on the text before it > >>>> =20 > >> goes > >> =20 > >>>> to the PS draft. > >>>> > >>>> marco > >>>> > >>>> Basavaraj.Patil@nokia.com wrote: > >>>> =20 > >>>>> Hi Marco, > >>>>> > >>>>> One of the issues that we got hung up at IETF75 during the LR > >>>>> =20 > >>> discussion was > >>> =20 > >>>>> on roaming. It would be good to have a clear description of the > >>>>> =20 > >>> relationship > >>> =20 > >>>>> between the MAG and LMA in the context of a PMIP6 domain > >>>>> =20 > >> especially > >> =20 > >>> when you > >>> =20 > >>>>> consider home and visited network scenarios wherein the MAG/LMA > >>>>> =20 > >>> entities are > >>> =20 > >>>>> in different domains. > >>>>> > >>>>> The PMIP6 domain definition in RFC5213: > >>>>> " > >>>>> Proxy Mobile IPv6 domain refers to the network where the > >>>>> =20 > >> mobility > >> =20 > >>>>> management of a mobile node is handled using the > >>>>> =20 > >> Proxy Mobile > >> =20 > >>> IPv6 > >>> =20 > >>>>> protocol as defined in this specification. The > >>>>> =20 > >> Proxy Mobile > >> IPv6 > >> =20 > >>>>> domain includes local mobility anchors and mobile access > >>>>> =20 > >> gateways > >> =20 > >>>>> between which security associations can be set up and > >>>>> authorization for sending Proxy Binding Updates on > >>>>> =20 > >> behalf of > >> the > >> =20 > >>>>> mobile nodes can be ensured. > >>>>> " > >>>>> > >>>>> does not have any references to home/visited network > >>>>> =20 > >> concepts. The > >> only > >> =20 > >>>>> criteria for an entity (MAG/LMA) being considered being=20 > a part of > >>>>> =20 > >> the > >> =20 > >>> PMIP6 > >>> =20 > >>>>> domain is the existence of a security association. It > >>>>> =20 > >> would be good > >> to > >> =20 > >>>>> elaborate how this maps to the current discussion in LR. > >>>>> > >>>>> -Raj > >>>>> =20 > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > >> =20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > =20 >=20 >=20 >=20 From behcetsarikaya@yahoo.com Wed Sep 16 15:14:18 2009 Return-Path: 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 E4F693A6ACF for ; Wed, 16 Sep 2009 15:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 DYeIcPpwv6SW for ; Wed, 16 Sep 2009 15:14:18 -0700 (PDT) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id B5D2A3A68E6 for ; Wed, 16 Sep 2009 15:14:18 -0700 (PDT) Received: (qmail 44322 invoked by uid 60001); 16 Sep 2009 22:08:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253138909; bh=avYl/aoPuqT7C3Vb0qsEGwpd5DDKYtSo56203vFn0kg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=wTuOKq42ekhn3OyQQ39YxBZ9IzrFYfH7yfCIwYG+ZZ0efrZs+o+73LLfGArlT97JC44dPUpSVtvT6IWdRMgGheX37CVuZVwrKIutnrkr9RIZgqee36OrwKFvwuDh3JNo6kSFrP54tJ4dEluSz/dF2y0nrDjXhsJgpJpzcp5erKY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=f5VPueeX0s8sMEJUhbwvx/W4yF+7M4Drm3fdkSGgxAeFqHrSogEYD/Nkdbo+tstm7r5L9UDbYHvGYNeytIRMWxgPde2Uieljm4R8yl1owhiYXCv4PDYJJOe+CTy1UFHDgTagKNsPzjYNmEq6MtMS6BQvYd7jWpQHXBuxoxJ2woU=; Message-ID: <374686.44187.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: fkZdF7gVM1nZWeChdXSXUkkrLmde0uNabSg1g942tu3Abj9FkM.hKTbpRt8fxlyrsvn3CGDDt2BGRijoW27cnmt9PcfjAfvIIscTFmEyX4liiG4PHK8E.NMjgusuxPxPIftwPihTJwgw7KrOKNhTZCAnhJu6IgR1YFB.5y3.0tshpQBy40rLODfZ8YREM8t8So78kIYxKlbv5CxPha6fTUAm7H.E0dfiYZIcqdrSN2SqeLBVUvcJP9kJ7zIIhZbVRvUOjyTa93kN5nTZso6crxiHmVmKJnddW7PeZ2qYfJUbQ_mIAhli1hA- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Wed, 16 Sep 2009 15:08:29 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.347.2 Date: Wed, 16 Sep 2009 15:08:29 -0700 (PDT) From: Behcet Sarikaya To: netext@ietf.org, netlmm@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stig Venaas , multimob@ietf.org Subject: [netext] Multimob PMIPv6 Multicast Support drafts X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 22:14:19 -0000 Hello all, The newly formed Multimob WG has a charter item to publish a document explaining the use of multicast in PMIPv6. Currently we have these drafts (in alphabetic order): http://tools.ietf.org/id/draft-krishnan-multimob-pmip6basicmcast-solution-00.txt http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-01.txt http://tools.ietf.org/id/draft-sijeon-multimob-mms-pmip6-00.txt and we solicit reviews of these drafts from PMIPv6 people. They are short and easy to read. Please post your review on Multimob list (preferred), or send to the chairs soon. Thanks, Stig & Behcet From Mohana.Jeyatharan@sg.panasonic.com Wed Sep 16 17:13:20 2009 Return-Path: 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 F19C03A68C9 for ; Wed, 16 Sep 2009 17:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_24=0.6] 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 Pu2g90KKsQ8c for ; Wed, 16 Sep 2009 17:13:19 -0700 (PDT) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 68C8C3A6864 for ; Wed, 16 Sep 2009 17:13:18 -0700 (PDT) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile11) with ESMTP id n8H0E7L1000574; Thu, 17 Sep 2009 09:14:07 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id n8H0E5k25218; Thu, 17 Sep 2009 09:14:06 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Sep 2009 08:10:35 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD038D2BCC@pslexc01.psl.local> In-Reply-To: <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [Netext] roaming issue-proposed text for roamingsection Thread-Index: Aco13eZpe9tnGQEmTa+HX32LBqfLTAAQh9SQAEKSpjA= From: "Mohana Jeyatharan" To: "Koodli, Rajeev" , Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 00:13:21 -0000 Hi Rajeev, Please see some of my comments. Thanks. BR, Mohana > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of Koodli, Rajeev > Sent: Wednesday, September 16, 2009 12:27 AM > To: netext@ietf.org > Subject: Re: [netext] [Netext] roaming issue-proposed text for > roamingsection >=20 >=20 > Hello folks, >=20 > There has been some good discussion on this topic. Here's my take to > converge and make progress. > Please read all the point below before responding. >=20 > 1. We do not deviate from the definition of a PMIPv6 domain as in RFC > 5213. Yes, we should not redefine this for local MAG routing. The same definition must be used. > 2. No new definitions of "domain" Yes, this need not be redefined as well. It refers to administrative domain and it is well known. > 3. Roaming is simply defined as "access to the Internet when the MAG and > LMA are in different provider domains" > (We do not need to explain the underlying reasons IMO. "Access to the > Internet" means the traditional connectivity via MAG and LMA as in RFC > 5213; we should not delve into "service-specific" definitions here) Well, the definition is ok. It is something like roaming across adminsitrative domains while being connected to ones PMIPv6 domain. > 4. If an SA exists between a MAG and an LMA, there will be packet > forwarding (i.e., MAG and LMA can be in different provider domains) This is essential, otherwise we may not be able to implement local MAG routing. (Unless there are ways to implmenet it without any LMA support! I means MN's MAG and CN'sMAG identify each other independently) > 5. We need to state somewhere that for the roaming case, localized > routing is subject to policy governing the service level agreements > between the providers. This means that merely having an SA between a > (visited) MAG and a (home) LMA does not translate to enabling localized > routing when (at least) one of the MN's is roaming. Agree, already some of the solution drafts are mentioning such things and policy is essential to enable localized routing. Probably mentioning itsomewhere in the PS would be good. But, is there a need to mention only in roaming case. I guess, even in the home or non-roaming case, some policy needs to be activated. Ofcourse at home, since all entities belong to same admin domain, an explict policy may not be needed. It all depends on LMAs decision. =20 Such capturing is sufficient and we can make progress in the PS document. >=20 > What do you think? >=20 > Regards, >=20 > -Rajeev >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org > > [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu > > Sent: Tuesday, September 15, 2009 1:22 AM > > To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com > > Cc: netext@ietf.org > > Subject: Re: [netext] [Netext] roaming issue-proposed text > > for roamingsection > > > > Hi, Mohana: > > Thank for your reply. > > ----- Original Message ----- > > From: "Mohana Jeyatharan" > > To: "Qin Wu" ; "Marco Liebsch" > > ; > > Cc: > > Sent: Tuesday, September 15, 2009 3:45 PM > > Subject: RE: [Netext] roaming issue-proposed text for roaming section > > > > > > Hi Qin, > > > > Sorry wanted to comment on your text, but here are some comments. > > > > I think we should stick to the definition of PMIPv6 domain as in RFC > > 5213 and not change it. That is, as long as the MAG-LMA tunnel can be > > created, it is considered as one PMIPv6 domain of MN. > > > > [Qin]: you are right, wherever MN moves around, MN does not > > change the PMIPv6 domain to which MN belongs, > > i.e., MN's home PMIPv6 domain. > > > > While being attached to such PMIPv6 domain, the MN may change > > administrative domain. > > i.e. move from home domain to another administrative domain (foreign > > domain). > > > > [Qin]: Another administrative domain you mentioned above can > > be viewed as MN's visited PMIPv6 domain. > > that is to say, although MN changes from one visited PMIPv6 > > domain to another, MN does not change its home > > PMIPv6 domain, does this sounds reasonable? Anyway, you can > > stick to use administrative to describe roaming if > > you like. > > > > Now, please see some comments on the text proposed. > > > > > > BR, > > Mohana > > > > > -----Original Message----- > > > From: Qin Wu [mailto:sunseawq@huawei.com] > > > Sent: Thursday, September 10, 2009 8:30 PM > > > To: Marco Liebsch; Basavaraj.Patil@nokia.com > > > Cc: netext@ietf.org; Mohana Jeyatharan > > > Subject: Re: [Netext] roaming issue-proposed text for > > roaming section > > > > > > Hi, all: > > > Since folks has no objection to add a section to talk about roaming > > issues. > > > I would like to propose > > > some texts based on roaming picture proposed by Marco. The proposed > > text > > > is as follows: > > > " > > > In the real PMIPv6 deployment, PMIPv6 components(e.g., LMAs, MAGs) > > [Mohana: tied to a given MN] > > > > [Qin]:Okay. > > > > can be > > > distributed into different PMIPv6 domains > > [Mohana: adminsitrative > > domain. Example LMA placed in one administrative domain and MAG placed > > in another administrative domain]. > > > > [Qin]: I think we have two choices to describe roaming: > > 1) define administrative domain > > 2) Separate PMIPv6 domains into PMIPv6 home domain and PMIPv6 > > visited domain > > Both can be used to describe roaming, in my mind. > > > > >In order to support localized > > > routing, it is required that MAGs to which MN and CN connect are > > within > > > the same PMIPv6 domain [Mohana: within the same administrative > > domain.]and each MAG setup security relationship > > > respectively with corresponding LMAs which maintain specific context > > to > > > which MN and CN belong. It is not required that LMAs anchored by MN > > and CN > > > are part of PMIPv6 domain [Mohana:administrative domain] as MAGs > > attached by MN and CN. MN is allowed to > > > roam within its PMIPv6 domain (i.e, MN's home domain in > > which MN's LMA > > is > > > located) or over different PMIPv6 domains(i.e., MN's > > visited domains). > > > > [Mohana: I would say MN is allowed to roam from home adminsitartive > > domain to visted administrative domain all tied to a single PMIPv6 > > domain of Mn] > > > > [Qin]: see above. > > > > CN > > > should stay with MN within the same PMIPv6 domain [Mohana: > > administrative domain]. > > > > > > Figure x shows PMIPv6 > > > roaming cases where MAGs attached by MN and CN belong to the same > > PMIPv6 > > > domain. In this figure, four PMIPv6 roaming cases need to be taken > > into > > > account. > > > Roaming case 1: > > > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's LMA(LMA2) are > > located > > > in the same PMIPv6 domain A as described in the figure 2. > > > Roaming case 2: > > > MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located > > in the same > > > PMIPv6 domain A while CN's LMA(LMA2') is located in the > > PMIPv6 domain > > B. > > > Roaming case 3: > > > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C > > while > > > MN's LMA(LMA1) and CN's LMA(LMA2) are located in the PMIPv6 domain A > > > Roaming case 4: > > > MN's MAG(MAG1'), CN's MAG(MAG2') are located in the PMIPv6 domain C > > while > > > MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's LMA(LMA2) > > is > > > located in the PMIPv6 domain B > > > > > > " > > [Mohana] I think, where description is made regarding MN and CN > > placement in a certain PMIPv6 domain, it is better to say in the same > > administrative domain. > > > > [Qin] I think for now some people support this, some not. > > > > It is just that MN is roaming in its PMIPv6 domain and CN is > > roaming in its PMIPv6 domain, and local MAG routing > > canbe performed when MN's MAG and CN's MAG are the same or > > are placed in > > the same adminstrative domain. I think such things need to > > be captued. > > > > [Qin] Right. > > > > > > > -------------------------------------------------------------- > > ---------- > > -- > > > ------ > > > > > > > > > > > > > > > > > > | > > > > +-----+ +-----+ | +-----+ > > > > |LMA1 | |LMA2 | | |LMA2'| > > > > +-----+ +-----+ | +-----+ > > > > | > > > > | > > > > | > > > > | > > > > +-----+ +-----+ | > > > > |MAG1 | |MAG2 | | > > > > +-----+ +-----+ | > > > > | > > > > | > > > > A | B > > > > > > ------------------------------+------------------------------- > > > > C > > > > > > > > > > > > +-----+ +-----+ > > > > |MAG1'| |MAG2'| > > > > +-----+ +-----+ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > -- > > > ------ > > > > > > If people prefer to use administrative domain, we can replace all > > PMIPv6 > > > domain in the proposed text with *administrative domain*, > > Welcome your > > > bash,:-) > > > Regards! > > > -Qin > > > ----- Original Message ----- > > > From: "Marco Liebsch" > > > To: > > > Cc: ; > > > Sent: Wednesday, September 09, 2009 11:07 PM > > > Subject: Re: [netext] [Netext] localized route optimization > > - roaming > > > issue > > > > > > > > > > Hi Raj, > > > > > > > > yes, agreed, that's why it has been proposed to add a section on > > this in > > > > the PS. The picture > > > > could be based on what I sent some mails ago. We're currently > > preparing > > > > some text, but > > > > I think it makes sense to discuss and agree on the text before it > > goes > > > > to the PS draft. > > > > > > > > marco > > > > > > > > Basavaraj.Patil@nokia.com wrote: > > > >> Hi Marco, > > > >> > > > >> One of the issues that we got hung up at IETF75 during the LR > > > discussion was > > > >> on roaming. It would be good to have a clear description of the > > > relationship > > > >> between the MAG and LMA in the context of a PMIP6 domain > > especially > > > when you > > > >> consider home and visited network scenarios wherein the MAG/LMA > > > entities are > > > >> in different domains. > > > >> > > > >> The PMIP6 domain definition in RFC5213: > > > >> " > > > >> Proxy Mobile IPv6 domain refers to the network where the > > mobility > > > >> management of a mobile node is handled using the > > Proxy Mobile > > > IPv6 > > > >> protocol as defined in this specification. The > > Proxy Mobile > > IPv6 > > > >> domain includes local mobility anchors and mobile access > > gateways > > > >> between which security associations can be set up and > > > >> authorization for sending Proxy Binding Updates on > > behalf of > > the > > > >> mobile nodes can be ensured. > > > >> " > > > >> > > > >> does not have any references to home/visited network > > concepts. The > > only > > > >> criteria for an entity (MAG/LMA) being considered being a part of > > the > > > PMIP6 > > > >> domain is the existence of a security association. It > > would be good > > to > > > >> elaborate how this maps to the current discussion in LR. > > > >> > > > >> -Raj > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From sunseawq@huawei.com Wed Sep 16 18:00:31 2009 Return-Path: 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 75E3F3A68B0 for ; Wed, 16 Sep 2009 18:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.215 X-Spam-Level: X-Spam-Status: No, score=-0.215 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 arXg6SA-QsVT for ; Wed, 16 Sep 2009 18:00:30 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 96EC23A6407 for ; Wed, 16 Sep 2009 18:00:30 -0700 (PDT) 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 <0KQ300ATPC5Y1M@szxga01-in.huawei.com> for netext@ietf.org; Thu, 17 Sep 2009 09:01:10 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ300GKPC5YI0@szxga01-in.huawei.com> for netext@ietf.org; Thu, 17 Sep 2009 09:01:10 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ300MN4C5YYZ@szxml06-in.huawei.com> for netext@ietf.org; Thu, 17 Sep 2009 09:01:10 +0800 (CST) Date: Thu, 17 Sep 2009 09:01:24 +0800 From: Qin Wu To: "Koodli, Rajeev" , netext@ietf.org Message-id: <005401ca3732$61573c80$260ca40a@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: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> <00dc01ca367a$01c18450$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF8FC@exchtewks3.starentnetworks.com> Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 01:00:31 -0000 Hi, ----- Original Message ----- From: "Koodli, Rajeev" To: Sent: Thursday, September 17, 2009 12:12 AM Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection > > >> > I do not think we need to design signaling for exchanging this > policy, >> > with or without roaming. >> >> [Qin]: Okay, that is to say information exchange between MAG >> and LMA is required, But the information is not necessary to >> be taken as any policy. am I right? > > Not sure what you mean. The signaling is for establishing localized > routing, which is subject to policy constraints. > We do not design policy exchange signaling here. [Qin]: That's what I understand. Actually policies can be exchanged through out of band signaling ,e.g.,AAA signaling. >> > Since LMA is the control entity, we can assume it to exert such > policy >> > control by instructing the MAG to provide localized routing. >> >> [Qin]: I am wondering whether instructing the MAG to or not >> to provide localized routing (i.e., enable/disable localized >> routing) can be viewed as *policy*? > > The trigger for LMA to initiate LR could be policy, yes. [Qin]: Agree. > -Rajeev > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From w52006@huawei.com Wed Sep 16 18:53:31 2009 Return-Path: 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 5DC7E28C17C for ; Wed, 16 Sep 2009 18:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=0.994, 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 HloicXow6vwo for ; Wed, 16 Sep 2009 18:53:30 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 63BE028C14C for ; Wed, 16 Sep 2009 18:53:30 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ300E1GEMJ6C@szxga03-in.huawei.com> for netext@ietf.org; Thu, 17 Sep 2009 09:54:19 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ300L9YEMJME@szxga03-in.huawei.com> for netext@ietf.org; Thu, 17 Sep 2009 09:54:19 +0800 (CST) Received: from w52006d ([10.164.12.17]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ30062REMJFE@szxml04-in.huawei.com> for netext@ietf.org; Thu, 17 Sep 2009 09:54:19 +0800 (CST) Date: Thu, 17 Sep 2009 09:54:19 +0800 From: Yungui Wang In-reply-to: To: 'jouni korhonen' Message-id: <006c01ca3739$c52a0790$110ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Aco2sSWE78VR7oZUSW2B2kLBJecHnAAgLloA Cc: netext@ietf.org Subject: Re: [netext] FW: New Version Notification fordraft-korhonen-netext-redirect-03 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: w52006@huawei.com List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 01:53:31 -0000 Hello > > So you agree the Redirect-Capability option is ok for indicating > redirection support. > Agree. But I don't think it is useful for the rfLMA and the MAG. For the rfLMA, please see below. For the MAG, as I said in the previous mail, the MIP/PMIP protocol has addressed that new mobility option (here is the Redirect option) can be silently droped by the receiver. > > session should be dependent on the blade architecture or the rfLMA > > self's > > load, etc. as described in the section 1. I don't think the > Capability > > option will affect its motivation. At this point, the Capability > > option is > > actually useless for the rfLMA. Hence, the MAG doesn't need > to tell > > it to > > the rfLMA. > > The rfLMA won't even try to do the redirection unless the MAG > expresses its capability for it. Here I still don't understand what's the motivation of the rfLMA doing redirection. As you described, it seems that the rfLMA does redirect just because of the MAG supports it. In my mind, as described in section 1 of the draft, for example, if a load balancer acting as the rfLMA is located in the PMIPv6 system, the depolyment has decided what it can do is redirection. It doesn't need the Capability indication. Another case, for example, if the rfLMA is overloaded, it may do redirect too. > In Section 3 we mandate that MAG-LMA > do not "remember" the prior redirection capability indications. That > allows e.g. the MAG to prohibit midsession redirections. > > The other reason is to get the same behavior of the protocol whether a > MAG supports redirection or not. A MAG should never be redirected if > it does not support the feature where as a LMA does. I don't think that is useful/essential. Without the Capability indication, the rfLMA still has to return the failed PBA in the certaion situations. > > Please see the detailed use case. > > In my understanding, there are three sets of LMA addresses on the > > MAG. The > > first (set_A) is coming from local configuration > independent from the > > individual MN. The second (set_B) is for the special MN, e.g. > > acheived by > > draft-ietf-netlmm-lma-discovery mechanism. The third (set_C) is > > provided by > > this draft. > > You said configuration check seems a little ambiguous. I wonder if > > the MAG > > checks that the set_C belongs to both set_A and set_B. > > I see your point. We can clarify this for sure. The check is against > SAs, not address set_[AB]. At the end, SAs must be configured > for all set_[ABC] addresses for the protocol to succeed. Agree. > I am not sure whether > we should mandate anything there other than saying that SAs > must be in place. > It is easily convinced that the set_C always belongs to set_A. However, it may be possible that the set_C doesn't belong to set_B. Hence, there may exsit some issues. B.R. Yungui From sijeon79@gmail.com Thu Sep 17 03:42:07 2009 Return-Path: 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 F2B5F28C1F1; Thu, 17 Sep 2009 03:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 v5n+hTu8PXK7; Thu, 17 Sep 2009 03:42:03 -0700 (PDT) Received: from mail-px0-f181.google.com (mail-px0-f181.google.com [209.85.216.181]) by core3.amsl.com (Postfix) with ESMTP id DA48928C1F9; Thu, 17 Sep 2009 03:42:01 -0700 (PDT) Received: by pxi11 with SMTP id 11so4689985pxi.17 for ; Thu, 17 Sep 2009 03:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:reply-to:from:to:cc :references:subject:date:organization:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :x-mimeole:thread-index; bh=eXmWzH4dOSTMctX1MfzZHzLontDJM0niXPYWvik1xn8=; b=DplzNnGLrQLM6lPkjeCMjoK4z6Y98M9o1xRkCQsqmUli9AfZfWXI4UfMEdCTC5XdMY 5nd8bqGvtpBjH1tctpoNrwPLtUGwv0J/zscUcBjEBBoQZMa1369b2ryM7hVMLQMFa26I udrQ4bkjOsCJX8AKZMTDC10JH1sE2QL46UAwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :in-reply-to:x-mimeole:thread-index; b=U7FtqGoSRGXReR5qfzEr2RpFWs+xwR0hWyaxMvlhWrrX1l1897Ds1bG6Z9FoBlqhYF 1fqS8bQflZLNBvxRdC1gvHMMGbtQ5f/07YK78f4Pd6bdMvk6JiYnyL5iHVpAuPsyOvOQ lJcBjFYf8tnYvjMrvzw+uFHes/vqjJZCaaQSM= Received: by 10.114.6.3 with SMTP id 3mr18380442waf.166.1253184170829; Thu, 17 Sep 2009 03:42:50 -0700 (PDT) Received: from dcn0d4b06d5df0 ([220.149.84.226]) by mx.google.com with ESMTPS id 21sm1743703pzk.15.2009.09.17.03.42.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 03:42:49 -0700 (PDT) From: "Seil Jeon" To: "'Behcet Sarikaya'" , , References: <374686.44187.qm@web111406.mail.gq1.yahoo.com> Date: Thu, 17 Sep 2009 19:42:26 +0900 Organization: dcn Message-ID: <003601ca3783$8e1eff40$bf7113ac@dcn0d4b06d5df0> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <374686.44187.qm@web111406.mail.gq1.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Aco3Gj1DKCA2M9iMQ564UrQN+SBjIAAZVQMw Cc: 'Stig Venaas' , multimob@ietf.org Subject: Re: [netext] [netlmm] Multimob PMIPv6 Multicast Support drafts X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sijeon79@gmail.com List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 10:42:07 -0000 Hi all, I'm Seil Jeon, the author of this draft http://tools.ietf.org/id/draft- sijeon-multimob-mms-pmip6-00.txt Mainly other drafts propose the method using MAG or LMA as multicast router. However, we can know that there is serious tunnel convergence problem between MAG and LMA as Mobile IP approach. And we should consider igmp/mld delay for new joining when mobile if there are no subscribers. I think that they are critical factors for PMIPv6 multicast architecture to be designed and the burdens on PMIPv6 components should be minimized as possible. ============================================================================ # Error Notice As you see handover operation in section 4, PBU/PBA signaling that exchanging between N-MAG and MR (Multicast Router) is error. It should be exchanged between N-MAG and LMA. So, don't misunderstand. A MR is simple multicast router where we have already known. I would modify an error in (-01) version Best Regards, Seil Jeon -----Original Message----- From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, September 17, 2009 7:08 AM To: netext@ietf.org; netlmm@ietf.org Cc: Stig Venaas; multimob@ietf.org Subject: [netlmm] Multimob PMIPv6 Multicast Support drafts Hello all, The newly formed Multimob WG has a charter item to publish a document explaining the use of multicast in PMIPv6. Currently we have these drafts (in alphabetic order): http://tools.ietf.org/id/draft-krishnan-multimob-pmip6basicmcast-solution- 00.txt http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment- 01.txt http://tools.ietf.org/id/draft-sijeon-multimob-mms-pmip6-00.txt and we solicit reviews of these drafts from PMIPv6 people. They are short and easy to read. Please post your review on Multimob list (preferred), or send to the chairs soon. Thanks, Stig & Behcet _______________________________________________ netlmm mailing list netlmm@ietf.org https://www.ietf.org/mailman/listinfo/netlmm From rkoodli@starentnetworks.com Fri Sep 18 14:58:30 2009 Return-Path: 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 7C9E13A695A for ; Fri, 18 Sep 2009 14:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 1xyOUaWg3cM7 for ; Fri, 18 Sep 2009 14:58:28 -0700 (PDT) Received: from mx1.starentnetworks.com (mx1.starentnetworks.com [63.118.244.150]) by core3.amsl.com (Postfix) with ESMTP id A04473A6996 for ; Fri, 18 Sep 2009 14:58:28 -0700 (PDT) X-ASG-Debug-ID: 1253311163-283500340000-XzWF0g X-Barracuda-URL: http://63.118.244.150:8000/cgi-bin/mark.cgi Received: from exchtewks1.starentnetworks.com (localhost [127.0.0.1]) by mx1.starentnetworks.com (Spam & Virus Firewall) with ESMTP id 28698EFC036 for ; Fri, 18 Sep 2009 17:59:23 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx1.starentnetworks.com with ESMTP id MdfnBkUnHCJtHVQC for ; Fri, 18 Sep 2009 17:59:23 -0400 (EDT) X-Barracuda-Envelope-From: rkoodli@starentnetworks.com Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Sep 2009 17:57:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: [netext] [Netext] roaming issue-proposed text for roamingsection Date: Fri, 18 Sep 2009 17:57:51 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660BFA4DE6@exchtewks3.starentnetworks.com> In-Reply-To: <4AB0BA63.9020507@nw.neclab.eu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] [Netext] roaming issue-proposed text for roamingsection Thread-Index: Aco2tj2OPBh3EdfORhmEPxZggu/JzQB9fEOg References: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> <00dc01ca367a$01c18450$260ca40a@china.huawei.com> <4AB0BA63.9020507@nw.neclab.eu> From: "Koodli, Rajeev" To: "Marco Liebsch" , "Qin Wu" X-OriginalArrivalTime: 18 Sep 2009 21:57:51.0935 (UTC) FILETIME=[119A04F0:01CA38AB] X-Barracuda-Connect: exchtewks1.starentnetworks.com[10.2.4.28] X-Barracuda-Start-Time: 1253311163 X-Barracuda-Virus-Scanned: by Barracuda Spam & Virus Firewall at starentnetworks.com Cc: netext@ietf.org Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 21:58:30 -0000 So, when could we have a new version available? I also remember from the meeting that we are not going to have private IPv4 address support, NAT traversal etc.=20 Thanks, -Rajeev > -----Original Message----- > From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu]=20 > Sent: Wednesday, September 16, 2009 3:14 AM > To: Qin Wu > Cc: Koodli, Rajeev; netext@ietf.org > Subject: Re: [netext] [Netext] roaming issue-proposed text=20 > for roamingsection >=20 > Hi Qin, >=20 > please see inline for my view. >=20 > Qin Wu schrieb: > > Hi, > > ----- Original Message ----- > > From: "Koodli, Rajeev" > > To: > > Sent: Wednesday, September 16, 2009 10:39 AM > > Subject: Re: [netext] [Netext] roaming issue-proposed text for=20 > > roamingsection > > > > > > =20 > >> Hi, > >> > >> =20 > >>> [Qin]: So I think if policy governing the SLA can=20 > afffect localized=20 > >>> routing directly, the MN's MAG and MN's LMA should belong to=20 > >>> different domain. > >>> In this sense, if MN's MAG and MN's LMA are located in the same=20 > >>> domain, SLA policy can not affect localize routing, am I right? > >>> =20 > >> Well, typically SLAs are between provider domains; at least that's=20 > >> how I was referring to. > >> =20 > > > > [Qin]: I agree. > > > > =20 > >>> Furthermore, besides SLA policy, I think there are other policies=20 > >>> that also affect localized routing e.g., in roaming scenario even=20 > >>> though MAG and LMA are located in the same domain, having=20 > SA between=20 > >>> MAG and LMA does not mean localized routing can be performed,=20 > >>> because use of local routing may be subject to accounting and=20 > >>> routing policies relating to the mobile node, , therefore=20 > localized=20 > >>> routing signaling between MAG and LMA is required to negotiate=20 > >>> localized routing policy information and enable/disable localized=20 > >>> routing. Am I right? > >>> > >>> =20 > >> Yes, localized routing is subject to policy constraints=20 > regardless of=20 > >> roaming. > >> > >> My point was specific to roaming when the policy allows a MAG to=20 > >> provide localized routing. > >> > >> I do not think we need to design signaling for exchanging this=20 > >> policy, with or without roaming. > >> =20 > > > > [Qin]: Okay, that is to say information exchange between=20 > MAG and LMA=20 > > is required, But the information is not necessary to be=20 > taken as any policy. am I right? > > =20 > I don't think the protocol should not be used to echange=20 > policies, which even does not make sense to me to transfer=20 > e.g. provider policies beyond domains, as the remote provider=20 > may have different policies. I think components (LMA, MAG)=20 > must operate according to their provider's policy and the=20 > protocols should just reflect the policy by means of requests=20 > to set up localized routing, which can be accepted or not and=20 > indicated accordingly in a status/reason code. >=20 > > =20 > >> Since LMA is the control entity, we can assume it to exert=20 > such policy > >> control by instructing the MAG to provide localized routing. > >> =20 > > > > [Qin]: I am wondering whether instructing the MAG to or not=20 > to provide localized routing > > (i.e., enable/disable localized routing) can be viewed as *policy*? > > =20 > I think it's more that the LMA acts according to it's=20 > operator's policy.=20 > If the policy does not permit > localized routing, the LMA would not send the request. The=20 > instruction/request itself does not > convey policies, as I understand from your question. This is my view. >=20 > marco >=20 > > =20 > >> Regards, > >> > >> -Rajeev > >> > >> > >> > >> =20 > >>>> What do you think? > >>>> > >>>> Regards, > >>>> > >>>> -Rajeev > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> =20 > >>>>> -----Original Message----- > >>>>> From: netext-bounces@ietf.org > >>>>> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu > >>>>> Sent: Tuesday, September 15, 2009 1:22 AM > >>>>> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com > >>>>> Cc: netext@ietf.org > >>>>> Subject: Re: [netext] [Netext] roaming issue-proposed text for=20 > >>>>> roamingsection > >>>>> > >>>>> Hi, Mohana: > >>>>> Thank for your reply. > >>>>> ----- Original Message ----- > >>>>> From: "Mohana Jeyatharan" > >>>>> To: "Qin Wu" ; "Marco Liebsch"=20 > >>>>> ; > >>>>> Cc: > >>>>> Sent: Tuesday, September 15, 2009 3:45 PM > >>>>> Subject: RE: [Netext] roaming issue-proposed text for=20 > >>>>> =20 > >>> roaming section > >>> =20 > >>>>> Hi Qin, > >>>>> > >>>>> Sorry wanted to comment on your text, but here are some=20 > comments. =20 > >>>>> > >>>>> I think we should stick to the definition of PMIPv6 domain=20 > >>>>> =20 > >>> as in RFC > >>> =20 > >>>>> 5213 and not change it. That is, as long as the MAG-LMA=20 > >>>>> =20 > >>> tunnel can be=20 > >>> =20 > >>>>> created, it is considered as one PMIPv6 domain of MN. > >>>>> > >>>>> [Qin]: you are right, wherever MN moves around, MN does=20 > not change=20 > >>>>> the PMIPv6 domain to which MN belongs, i.e., MN's home=20 > >>>>> =20 > >>> PMIPv6 domain. > >>> =20 > >>>>> While being attached to such PMIPv6 domain, the MN may change=20 > >>>>> administrative domain. > >>>>> i.e. move from home domain to another administrative=20 > >>>>> =20 > >>> domain (foreign=20 > >>> =20 > >>>>> domain). > >>>>> > >>>>> [Qin]: Another administrative domain you mentioned above can be=20 > >>>>> viewed as MN's visited PMIPv6 domain. > >>>>> that is to say, although MN changes from one visited=20 > >>>>> =20 > >>> PMIPv6 domain to=20 > >>> =20 > >>>>> another, MN does not change its home > >>>>> PMIPv6 domain, does this sounds reasonable? Anyway, you=20 > >>>>> =20 > >>> can stick to=20 > >>> =20 > >>>>> use administrative to describe roaming if you like. > >>>>> > >>>>> Now, please see some comments on the text proposed. > >>>>> > >>>>> > >>>>> BR, > >>>>> Mohana > >>>>> > >>>>> =20 > >>>>>> -----Original Message----- > >>>>>> From: Qin Wu [mailto:sunseawq@huawei.com] > >>>>>> Sent: Thursday, September 10, 2009 8:30 PM > >>>>>> To: Marco Liebsch; Basavaraj.Patil@nokia.com > >>>>>> Cc: netext@ietf.org; Mohana Jeyatharan > >>>>>> Subject: Re: [Netext] roaming issue-proposed text for > >>>>>> =20 > >>>>> roaming section > >>>>> =20 > >>>>>> Hi, all: > >>>>>> Since folks has no objection to add a section to talk=20 > >>>>>> =20 > >>> about roaming > >>> =20 > >>>>> issues. > >>>>> =20 > >>>>>> I would like to propose > >>>>>> some texts based on roaming picture proposed by Marco.=20 > >>>>>> =20 > >>> The proposed > >>> =20 > >>>>> text > >>>>> =20 > >>>>>> is as follows: > >>>>>> " > >>>>>> In the real PMIPv6 deployment, PMIPv6 components(e.g.,=20 > >>>>>> =20 > >>> LMAs, MAGs) > >>> =20 > >>>>> [Mohana: tied to a given MN] > >>>>> > >>>>> [Qin]:Okay. > >>>>> > >>>>> can be > >>>>> =20 > >>>>>> distributed into different PMIPv6 domains > >>>>>> =20 > >>>>> [Mohana: adminsitrative > >>>>> domain. Example LMA placed in one administrative domain and MAG=20 > >>>>> placed in another administrative domain]. > >>>>> > >>>>> [Qin]: I think we have two choices to describe roaming: > >>>>> 1) define administrative domain > >>>>> 2) Separate PMIPv6 domains into PMIPv6 home domain and=20 > >>>>> =20 > >>> PMIPv6 visited=20 > >>> =20 > >>>>> domain Both can be used to describe roaming, in my mind. > >>>>> > >>>>> =20 > >>>>>> In order to support localized > >>>>>> routing, it is required that MAGs to which MN and CN=20 > connect are > >>>>>> =20 > >>>>> within > >>>>> =20 > >>>>>> the same PMIPv6 domain [Mohana: within the same administrative > >>>>>> =20 > >>>>> domain.]and each MAG setup security relationship > >>>>> =20 > >>>>>> respectively with corresponding LMAs which maintain specific=20 > >>>>>> context > >>>>>> =20 > >>>>> to > >>>>> =20 > >>>>>> which MN and CN belong. It is not required that LMAs=20 > >>>>>> =20 > >>> anchored by MN > >>> =20 > >>>>> and CN > >>>>> =20 > >>>>>> are part of PMIPv6 domain [Mohana:administrative=20 > domain] as MAGs > >>>>>> =20 > >>>>> attached by MN and CN. MN is allowed to > >>>>> =20 > >>>>>> roam within its PMIPv6 domain (i.e, MN's home domain in > >>>>>> =20 > >>>>> which MN's LMA > >>>>> is > >>>>> =20 > >>>>>> located) or over different PMIPv6 domains(i.e., MN's > >>>>>> =20 > >>>>> visited domains). > >>>>> > >>>>> [Mohana: I would say MN is allowed to roam from home=20 > >>>>> =20 > >>> adminsitartive=20 > >>> =20 > >>>>> domain to visted administrative domain all tied to a=20 > single PMIPv6=20 > >>>>> domain of Mn] > >>>>> > >>>>> [Qin]: see above. > >>>>> > >>>>> CN > >>>>> =20 > >>>>>> should stay with MN within the same PMIPv6 domain [Mohana: > >>>>>> =20 > >>>>> administrative domain]. =20 > >>>>> > >>>>> > >>>>> Figure x shows PMIPv6 > >>>>> =20 > >>>>>> roaming cases where MAGs attached by MN and CN belong=20 > to the same > >>>>>> =20 > >>>>> PMIPv6 > >>>>> =20 > >>>>>> domain. In this figure, four PMIPv6 roaming cases need=20 > >>>>>> =20 > >>> to be taken > >>> =20 > >>>>> into > >>>>> =20 > >>>>>> account. > >>>>>> Roaming case 1: > >>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's=20 > LMA(LMA2) are > >>>>>> =20 > >>>>> located > >>>>> =20 > >>>>>> in the same PMIPv6 domain A as described in the figure 2. > >>>>>> Roaming case 2: > >>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located > >>>>>> =20 > >>>>> in the same > >>>>> =20 > >>>>>> PMIPv6 domain A while CN's LMA(LMA2') is located in the > >>>>>> =20 > >>>>> PMIPv6 domain > >>>>> B. > >>>>> =20 > >>>>>> Roaming case 3: > >>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the=20 > >>>>>> =20 > >>> PMIPv6 domain C > >>> =20 > >>>>> while > >>>>> =20 > >>>>>> MN's LMA(LMA1) and CN's LMA(LMA2) are located in the=20 > >>>>>> =20 > >>> PMIPv6 domain=20 > >>> =20 > >>>>>> A Roaming case 4: > >>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the=20 > >>>>>> =20 > >>> PMIPv6 domain C > >>> =20 > >>>>> while > >>>>> =20 > >>>>>> MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's=20 > >>>>>> LMA(LMA2) > >>>>>> =20 > >>>>> is > >>>>> =20 > >>>>>> located in the PMIPv6 domain B > >>>>>> > >>>>>> " > >>>>>> =20 > >>>>> [Mohana] I think, where description is made regarding MN and CN=20 > >>>>> placement in a certain PMIPv6 domain, it is better to say=20 > >>>>> =20 > >>> in the same=20 > >>> =20 > >>>>> administrative domain. > >>>>> > >>>>> [Qin] I think for now some people support this, some not. > >>>>> > >>>>> It is just that MN is roaming in its PMIPv6 domain and CN=20 > >>>>> =20 > >>> is roaming=20 > >>> =20 > >>>>> in its PMIPv6 domain, and local MAG routing canbe=20 > >>>>> =20 > >>> performed when MN's=20 > >>> =20 > >>>>> MAG and CN's MAG are the same or are placed in the same=20 > >>>>> =20 > >>> adminstrative=20 > >>> =20 > >>>>> domain. I think such things need to be captued. > >>>>> > >>>>> [Qin] Right. > >>>>> > >>>>> =20 > >>>>> -------------------------------------------------------------- > >>>>> ---------- > >>>>> -- > >>>>> =20 > >>>>>> ------ > >>>>>> > >>>>>> > >>>>>> =20 > >>>>>>> | > >>>>>>> +-----+ +-----+ | +-----+ > >>>>>>> |LMA1 | |LMA2 | | |LMA2'| > >>>>>>> +-----+ +-----+ | +-----+ > >>>>>>> | > >>>>>>> | > >>>>>>> | > >>>>>>> | > >>>>>>> +-----+ +-----+ | > >>>>>>> |MAG1 | |MAG2 | | > >>>>>>> +-----+ +-----+ | > >>>>>>> | > >>>>>>> | > >>>>>>> A | B > >>>>>>> =20 > >>>>>>> =20 > >>>>> ------------------------------+------------------------------- > >>>>> =20 > >>>>>>> C > >>>>>>> > >>>>>>> > >>>>>>> +-----+ +-----+ > >>>>>>> |MAG1'| |MAG2'| > >>>>>>> +-----+ +-----+ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> =20 > >>>>>> > >>>>>> =20 > >>>>> -------------------------------------------------------------- > >>>>> ---------- > >>>>> -- > >>>>> =20 > >>>>>> ------ > >>>>>> > >>>>>> If people prefer to use administrative domain, we can=20 > replace all > >>>>>> =20 > >>>>> PMIPv6 > >>>>> =20 > >>>>>> domain in the proposed text with *administrative domain*, > >>>>>> =20 > >>>>> Welcome your > >>>>> =20 > >>>>>> bash,:-) > >>>>>> Regards! > >>>>>> -Qin > >>>>>> ----- Original Message ----- > >>>>>> From: "Marco Liebsch" > >>>>>> To: > >>>>>> Cc: ; > >>>>>> Sent: Wednesday, September 09, 2009 11:07 PM > >>>>>> Subject: Re: [netext] [Netext] localized route optimization > >>>>>> =20 > >>>>> - roaming > >>>>> =20 > >>>>>> issue > >>>>>> > >>>>>> > >>>>>> =20 > >>>>>>> Hi Raj, > >>>>>>> > >>>>>>> yes, agreed, that's why it has been proposed to add a=20 > >>>>>>> =20 > >>> section on > >>> =20 > >>>>> this in > >>>>> =20 > >>>>>>> the PS. The picture > >>>>>>> could be based on what I sent some mails ago. We're currently > >>>>>>> =20 > >>>>> preparing > >>>>> =20 > >>>>>>> some text, but > >>>>>>> I think it makes sense to discuss and agree on the=20 > >>>>>>> =20 > >>> text before it > >>> =20 > >>>>> goes > >>>>> =20 > >>>>>>> to the PS draft. > >>>>>>> > >>>>>>> marco > >>>>>>> > >>>>>>> Basavaraj.Patil@nokia.com wrote: > >>>>>>> =20 > >>>>>>>> Hi Marco, > >>>>>>>> > >>>>>>>> One of the issues that we got hung up at IETF75 during the LR > >>>>>>>> =20 > >>>>>> discussion was > >>>>>> =20 > >>>>>>>> on roaming. It would be good to have a clear=20 > >>>>>>>> =20 > >>> description of the > >>> =20 > >>>>>> relationship > >>>>>> =20 > >>>>>>>> between the MAG and LMA in the context of a PMIP6 domain > >>>>>>>> =20 > >>>>> especially > >>>>> =20 > >>>>>> when you > >>>>>> =20 > >>>>>>>> consider home and visited network scenarios wherein=20 > >>>>>>>> =20 > >>> the MAG/LMA > >>> =20 > >>>>>> entities are > >>>>>> =20 > >>>>>>>> in different domains. > >>>>>>>> > >>>>>>>> The PMIP6 domain definition in RFC5213: > >>>>>>>> " > >>>>>>>> Proxy Mobile IPv6 domain refers to the network=20 > where the > >>>>>>>> =20 > >>>>> mobility > >>>>> =20 > >>>>>>>> management of a mobile node is handled using the > >>>>>>>> =20 > >>>>> Proxy Mobile > >>>>> =20 > >>>>>> IPv6 > >>>>>> =20 > >>>>>>>> protocol as defined in this specification. The > >>>>>>>> =20 > >>>>> Proxy Mobile > >>>>> IPv6 > >>>>> =20 > >>>>>>>> domain includes local mobility anchors and=20 > mobile access > >>>>>>>> =20 > >>>>> gateways > >>>>> =20 > >>>>>>>> between which security associations can be set up and > >>>>>>>> authorization for sending Proxy Binding Updates on > >>>>>>>> =20 > >>>>> behalf of > >>>>> the > >>>>> =20 > >>>>>>>> mobile nodes can be ensured. > >>>>>>>> " > >>>>>>>> > >>>>>>>> does not have any references to home/visited network > >>>>>>>> =20 > >>>>> concepts. The > >>>>> only > >>>>> =20 > >>>>>>>> criteria for an entity (MAG/LMA) being considered=20 > >>>>>>>> =20 > >>> being a part=20 > >>> =20 > >>>>>>>> of > >>>>>>>> =20 > >>>>> the > >>>>> =20 > >>>>>> PMIP6 > >>>>>> =20 > >>>>>>>> domain is the existence of a security association. It > >>>>>>>> =20 > >>>>> would be good > >>>>> to > >>>>> =20 > >>>>>>>> elaborate how this maps to the current discussion in LR. > >>>>>>>> > >>>>>>>> -Raj > >>>>>>>> =20 > >>>>> _______________________________________________ > >>>>> netext mailing list > >>>>> netext@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netext > >>>>> > >>>>> =20 > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>>> =20 > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> =20 > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > =20 >=20 >=20 >=20 From sunseawq@huawei.com Fri Sep 18 18:05:08 2009 Return-Path: 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 916263A67A4 for ; Fri, 18 Sep 2009 18:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.223 X-Spam-Level: X-Spam-Status: No, score=-0.223 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 fngnf6AyH6sE for ; Fri, 18 Sep 2009 18:05:07 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 82A5D3A67A5 for ; Fri, 18 Sep 2009 18:05:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ7001JB1PRQT@szxga03-in.huawei.com> for netext@ietf.org; Sat, 19 Sep 2009 09:05:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ7005J21PRZE@szxga03-in.huawei.com> for netext@ietf.org; Sat, 19 Sep 2009 09:05:51 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ700EG51PQZH@szxml04-in.huawei.com> for netext@ietf.org; Sat, 19 Sep 2009 09:05:51 +0800 (CST) Date: Sat, 19 Sep 2009 09:05:56 +0800 From: Qin Wu To: "Koodli, Rajeev" , Marco Liebsch Message-id: <00bb01ca38c5$58276510$260ca40a@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: <5F09D220B62F79418461A978CA0921BD038D27F6@pslexc01.psl.local> <03d101ca35dd$9663d510$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFE90C@exchtewks3.starentnetworks.com> <00b101ca3673$f5ee6220$260ca40a@china.huawei.com> <4D35478224365146822AE9E3AD4A26660BDFF0A3@exchtewks3.starentnetworks.com> <00dc01ca367a$01c18450$260ca40a@china.huawei.com> <4AB0BA63.9020507@nw.neclab.eu> <4D35478224365146822AE9E3AD4A26660BFA4DE6$0001@exchtewks3.starentnetworks.com> Cc: netext@ietf.org Subject: Re: [netext] [Netext] roaming issue-proposed text for roamingsection 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 01:05:08 -0000 Hi, Koodli: Probably will publish the first draft by the end of this week, Marco will do this. Regards! -Qin ----- Original Message ----- From: "Koodli, Rajeev" To: "Marco Liebsch" ; "Qin Wu" Cc: Sent: Saturday, September 19, 2009 5:57 AM Subject: RE: [netext] [Netext] roaming issue-proposed text for roamingsection So, when could we have a new version available? I also remember from the meeting that we are not going to have private IPv4 address support, NAT traversal etc. Thanks, -Rajeev > -----Original Message----- > From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu] > Sent: Wednesday, September 16, 2009 3:14 AM > To: Qin Wu > Cc: Koodli, Rajeev; netext@ietf.org > Subject: Re: [netext] [Netext] roaming issue-proposed text > for roamingsection > > Hi Qin, > > please see inline for my view. > > Qin Wu schrieb: > > Hi, > > ----- Original Message ----- > > From: "Koodli, Rajeev" > > To: > > Sent: Wednesday, September 16, 2009 10:39 AM > > Subject: Re: [netext] [Netext] roaming issue-proposed text for > > roamingsection > > > > > > > >> Hi, > >> > >> > >>> [Qin]: So I think if policy governing the SLA can > afffect localized > >>> routing directly, the MN's MAG and MN's LMA should belong to > >>> different domain. > >>> In this sense, if MN's MAG and MN's LMA are located in the same > >>> domain, SLA policy can not affect localize routing, am I right? > >>> > >> Well, typically SLAs are between provider domains; at least that's > >> how I was referring to. > >> > > > > [Qin]: I agree. > > > > > >>> Furthermore, besides SLA policy, I think there are other policies > >>> that also affect localized routing e.g., in roaming scenario even > >>> though MAG and LMA are located in the same domain, having > SA between > >>> MAG and LMA does not mean localized routing can be performed, > >>> because use of local routing may be subject to accounting and > >>> routing policies relating to the mobile node, , therefore > localized > >>> routing signaling between MAG and LMA is required to negotiate > >>> localized routing policy information and enable/disable localized > >>> routing. Am I right? > >>> > >>> > >> Yes, localized routing is subject to policy constraints > regardless of > >> roaming. > >> > >> My point was specific to roaming when the policy allows a MAG to > >> provide localized routing. > >> > >> I do not think we need to design signaling for exchanging this > >> policy, with or without roaming. > >> > > > > [Qin]: Okay, that is to say information exchange between > MAG and LMA > > is required, But the information is not necessary to be > taken as any policy. am I right? > > > I don't think the protocol should not be used to echange > policies, which even does not make sense to me to transfer > e.g. provider policies beyond domains, as the remote provider > may have different policies. I think components (LMA, MAG) > must operate according to their provider's policy and the > protocols should just reflect the policy by means of requests > to set up localized routing, which can be accepted or not and > indicated accordingly in a status/reason code. > > > > >> Since LMA is the control entity, we can assume it to exert > such policy > >> control by instructing the MAG to provide localized routing. > >> > > > > [Qin]: I am wondering whether instructing the MAG to or not > to provide localized routing > > (i.e., enable/disable localized routing) can be viewed as *policy*? > > > I think it's more that the LMA acts according to it's > operator's policy. > If the policy does not permit > localized routing, the LMA would not send the request. The > instruction/request itself does not > convey policies, as I understand from your question. This is my view. > > marco > > > > >> Regards, > >> > >> -Rajeev > >> > >> > >> > >> > >>>> What do you think? > >>>> > >>>> Regards, > >>>> > >>>> -Rajeev > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: netext-bounces@ietf.org > >>>>> [mailto:netext-bounces@ietf.org] On Behalf Of Qin Wu > >>>>> Sent: Tuesday, September 15, 2009 1:22 AM > >>>>> To: Mohana Jeyatharan; Marco Liebsch; Basavaraj.Patil@nokia.com > >>>>> Cc: netext@ietf.org > >>>>> Subject: Re: [netext] [Netext] roaming issue-proposed text for > >>>>> roamingsection > >>>>> > >>>>> Hi, Mohana: > >>>>> Thank for your reply. > >>>>> ----- Original Message ----- > >>>>> From: "Mohana Jeyatharan" > >>>>> To: "Qin Wu" ; "Marco Liebsch" > >>>>> ; > >>>>> Cc: > >>>>> Sent: Tuesday, September 15, 2009 3:45 PM > >>>>> Subject: RE: [Netext] roaming issue-proposed text for > >>>>> > >>> roaming section > >>> > >>>>> Hi Qin, > >>>>> > >>>>> Sorry wanted to comment on your text, but here are some > comments. > >>>>> > >>>>> I think we should stick to the definition of PMIPv6 domain > >>>>> > >>> as in RFC > >>> > >>>>> 5213 and not change it. That is, as long as the MAG-LMA > >>>>> > >>> tunnel can be > >>> > >>>>> created, it is considered as one PMIPv6 domain of MN. > >>>>> > >>>>> [Qin]: you are right, wherever MN moves around, MN does > not change > >>>>> the PMIPv6 domain to which MN belongs, i.e., MN's home > >>>>> > >>> PMIPv6 domain. > >>> > >>>>> While being attached to such PMIPv6 domain, the MN may change > >>>>> administrative domain. > >>>>> i.e. move from home domain to another administrative > >>>>> > >>> domain (foreign > >>> > >>>>> domain). > >>>>> > >>>>> [Qin]: Another administrative domain you mentioned above can be > >>>>> viewed as MN's visited PMIPv6 domain. > >>>>> that is to say, although MN changes from one visited > >>>>> > >>> PMIPv6 domain to > >>> > >>>>> another, MN does not change its home > >>>>> PMIPv6 domain, does this sounds reasonable? Anyway, you > >>>>> > >>> can stick to > >>> > >>>>> use administrative to describe roaming if you like. > >>>>> > >>>>> Now, please see some comments on the text proposed. > >>>>> > >>>>> > >>>>> BR, > >>>>> Mohana > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Qin Wu [mailto:sunseawq@huawei.com] > >>>>>> Sent: Thursday, September 10, 2009 8:30 PM > >>>>>> To: Marco Liebsch; Basavaraj.Patil@nokia.com > >>>>>> Cc: netext@ietf.org; Mohana Jeyatharan > >>>>>> Subject: Re: [Netext] roaming issue-proposed text for > >>>>>> > >>>>> roaming section > >>>>> > >>>>>> Hi, all: > >>>>>> Since folks has no objection to add a section to talk > >>>>>> > >>> about roaming > >>> > >>>>> issues. > >>>>> > >>>>>> I would like to propose > >>>>>> some texts based on roaming picture proposed by Marco. > >>>>>> > >>> The proposed > >>> > >>>>> text > >>>>> > >>>>>> is as follows: > >>>>>> " > >>>>>> In the real PMIPv6 deployment, PMIPv6 components(e.g., > >>>>>> > >>> LMAs, MAGs) > >>> > >>>>> [Mohana: tied to a given MN] > >>>>> > >>>>> [Qin]:Okay. > >>>>> > >>>>> can be > >>>>> > >>>>>> distributed into different PMIPv6 domains > >>>>>> > >>>>> [Mohana: adminsitrative > >>>>> domain. Example LMA placed in one administrative domain and MAG > >>>>> placed in another administrative domain]. > >>>>> > >>>>> [Qin]: I think we have two choices to describe roaming: > >>>>> 1) define administrative domain > >>>>> 2) Separate PMIPv6 domains into PMIPv6 home domain and > >>>>> > >>> PMIPv6 visited > >>> > >>>>> domain Both can be used to describe roaming, in my mind. > >>>>> > >>>>> > >>>>>> In order to support localized > >>>>>> routing, it is required that MAGs to which MN and CN > connect are > >>>>>> > >>>>> within > >>>>> > >>>>>> the same PMIPv6 domain [Mohana: within the same administrative > >>>>>> > >>>>> domain.]and each MAG setup security relationship > >>>>> > >>>>>> respectively with corresponding LMAs which maintain specific > >>>>>> context > >>>>>> > >>>>> to > >>>>> > >>>>>> which MN and CN belong. It is not required that LMAs > >>>>>> > >>> anchored by MN > >>> > >>>>> and CN > >>>>> > >>>>>> are part of PMIPv6 domain [Mohana:administrative > domain] as MAGs > >>>>>> > >>>>> attached by MN and CN. MN is allowed to > >>>>> > >>>>>> roam within its PMIPv6 domain (i.e, MN's home domain in > >>>>>> > >>>>> which MN's LMA > >>>>> is > >>>>> > >>>>>> located) or over different PMIPv6 domains(i.e., MN's > >>>>>> > >>>>> visited domains). > >>>>> > >>>>> [Mohana: I would say MN is allowed to roam from home > >>>>> > >>> adminsitartive > >>> > >>>>> domain to visted administrative domain all tied to a > single PMIPv6 > >>>>> domain of Mn] > >>>>> > >>>>> [Qin]: see above. > >>>>> > >>>>> CN > >>>>> > >>>>>> should stay with MN within the same PMIPv6 domain [Mohana: > >>>>>> > >>>>> administrative domain]. > >>>>> > >>>>> > >>>>> Figure x shows PMIPv6 > >>>>> > >>>>>> roaming cases where MAGs attached by MN and CN belong > to the same > >>>>>> > >>>>> PMIPv6 > >>>>> > >>>>>> domain. In this figure, four PMIPv6 roaming cases need > >>>>>> > >>> to be taken > >>> > >>>>> into > >>>>> > >>>>>> account. > >>>>>> Roaming case 1: > >>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1),CN's > LMA(LMA2) are > >>>>>> > >>>>> located > >>>>> > >>>>>> in the same PMIPv6 domain A as described in the figure 2. > >>>>>> Roaming case 2: > >>>>>> MN's MAG(MAG1), CN's MAG(MAG2),MN's LMA(LMA1) are located > >>>>>> > >>>>> in the same > >>>>> > >>>>>> PMIPv6 domain A while CN's LMA(LMA2') is located in the > >>>>>> > >>>>> PMIPv6 domain > >>>>> B. > >>>>> > >>>>>> Roaming case 3: > >>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the > >>>>>> > >>> PMIPv6 domain C > >>> > >>>>> while > >>>>> > >>>>>> MN's LMA(LMA1) and CN's LMA(LMA2) are located in the > >>>>>> > >>> PMIPv6 domain > >>> > >>>>>> A Roaming case 4: > >>>>>> MN's MAG(MAG1'), CN's MAG(MAG2') are located in the > >>>>>> > >>> PMIPv6 domain C > >>> > >>>>> while > >>>>> > >>>>>> MN's LMA(LMA1) is located in the PMIPv6 domain A, and CN's > >>>>>> LMA(LMA2) > >>>>>> > >>>>> is > >>>>> > >>>>>> located in the PMIPv6 domain B > >>>>>> > >>>>>> " > >>>>>> > >>>>> [Mohana] I think, where description is made regarding MN and CN > >>>>> placement in a certain PMIPv6 domain, it is better to say > >>>>> > >>> in the same > >>> > >>>>> administrative domain. > >>>>> > >>>>> [Qin] I think for now some people support this, some not. > >>>>> > >>>>> It is just that MN is roaming in its PMIPv6 domain and CN > >>>>> > >>> is roaming > >>> > >>>>> in its PMIPv6 domain, and local MAG routing canbe > >>>>> > >>> performed when MN's > >>> > >>>>> MAG and CN's MAG are the same or are placed in the same > >>>>> > >>> adminstrative > >>> > >>>>> domain. I think such things need to be captued. > >>>>> > >>>>> [Qin] Right. > >>>>> > >>>>> > >>>>> -------------------------------------------------------------- > >>>>> ---------- > >>>>> -- > >>>>> > >>>>>> ------ > >>>>>> > >>>>>> > >>>>>> > >>>>>>> | > >>>>>>> +-----+ +-----+ | +-----+ > >>>>>>> |LMA1 | |LMA2 | | |LMA2'| > >>>>>>> +-----+ +-----+ | +-----+ > >>>>>>> | > >>>>>>> | > >>>>>>> | > >>>>>>> | > >>>>>>> +-----+ +-----+ | > >>>>>>> |MAG1 | |MAG2 | | > >>>>>>> +-----+ +-----+ | > >>>>>>> | > >>>>>>> | > >>>>>>> A | B > >>>>>>> > >>>>>>> > >>>>> ------------------------------+------------------------------- > >>>>> > >>>>>>> C > >>>>>>> > >>>>>>> > >>>>>>> +-----+ +-----+ > >>>>>>> |MAG1'| |MAG2'| > >>>>>>> +-----+ +-----+ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> -------------------------------------------------------------- > >>>>> ---------- > >>>>> -- > >>>>> > >>>>>> ------ > >>>>>> > >>>>>> If people prefer to use administrative domain, we can > replace all > >>>>>> > >>>>> PMIPv6 > >>>>> > >>>>>> domain in the proposed text with *administrative domain*, > >>>>>> > >>>>> Welcome your > >>>>> > >>>>>> bash,:-) > >>>>>> Regards! > >>>>>> -Qin > >>>>>> ----- Original Message ----- > >>>>>> From: "Marco Liebsch" > >>>>>> To: > >>>>>> Cc: ; > >>>>>> Sent: Wednesday, September 09, 2009 11:07 PM > >>>>>> Subject: Re: [netext] [Netext] localized route optimization > >>>>>> > >>>>> - roaming > >>>>> > >>>>>> issue > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hi Raj, > >>>>>>> > >>>>>>> yes, agreed, that's why it has been proposed to add a > >>>>>>> > >>> section on > >>> > >>>>> this in > >>>>> > >>>>>>> the PS. The picture > >>>>>>> could be based on what I sent some mails ago. We're currently > >>>>>>> > >>>>> preparing > >>>>> > >>>>>>> some text, but > >>>>>>> I think it makes sense to discuss and agree on the > >>>>>>> > >>> text before it > >>> > >>>>> goes > >>>>> > >>>>>>> to the PS draft. > >>>>>>> > >>>>>>> marco > >>>>>>> > >>>>>>> Basavaraj.Patil@nokia.com wrote: > >>>>>>> > >>>>>>>> Hi Marco, > >>>>>>>> > >>>>>>>> One of the issues that we got hung up at IETF75 during the LR > >>>>>>>> > >>>>>> discussion was > >>>>>> > >>>>>>>> on roaming. It would be good to have a clear > >>>>>>>> > >>> description of the > >>> > >>>>>> relationship > >>>>>> > >>>>>>>> between the MAG and LMA in the context of a PMIP6 domain > >>>>>>>> > >>>>> especially > >>>>> > >>>>>> when you > >>>>>> > >>>>>>>> consider home and visited network scenarios wherein > >>>>>>>> > >>> the MAG/LMA > >>> > >>>>>> entities are > >>>>>> > >>>>>>>> in different domains. > >>>>>>>> > >>>>>>>> The PMIP6 domain definition in RFC5213: > >>>>>>>> " > >>>>>>>> Proxy Mobile IPv6 domain refers to the network > where the > >>>>>>>> > >>>>> mobility > >>>>> > >>>>>>>> management of a mobile node is handled using the > >>>>>>>> > >>>>> Proxy Mobile > >>>>> > >>>>>> IPv6 > >>>>>> > >>>>>>>> protocol as defined in this specification. The > >>>>>>>> > >>>>> Proxy Mobile > >>>>> IPv6 > >>>>> > >>>>>>>> domain includes local mobility anchors and > mobile access > >>>>>>>> > >>>>> gateways > >>>>> > >>>>>>>> between which security associations can be set up and > >>>>>>>> authorization for sending Proxy Binding Updates on > >>>>>>>> > >>>>> behalf of > >>>>> the > >>>>> > >>>>>>>> mobile nodes can be ensured. > >>>>>>>> " > >>>>>>>> > >>>>>>>> does not have any references to home/visited network > >>>>>>>> > >>>>> concepts. The > >>>>> only > >>>>> > >>>>>>>> criteria for an entity (MAG/LMA) being considered > >>>>>>>> > >>> being a part > >>> > >>>>>>>> of > >>>>>>>> > >>>>> the > >>>>> > >>>>>> PMIP6 > >>>>>> > >>>>>>>> domain is the existence of a security association. It > >>>>>>>> > >>>>> would be good > >>>>> to > >>>>> > >>>>>>>> elaborate how this maps to the current discussion in LR. > >>>>>>>> > >>>>>>>> -Raj > >>>>>>>> > >>>>> _______________________________________________ > >>>>> netext mailing list > >>>>> netext@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/netext > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> netext mailing list > >>>> netext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netext > >>>> > >> _______________________________________________ > >> netext mailing list > >> netext@ietf.org > >> https://www.ietf.org/mailman/listinfo/netext > >> > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > > > > > This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you. From root@core3.amsl.com Mon Sep 21 09:00:02 2009 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 334213A6870; Mon, 21 Sep 2009 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090921160002.334213A6870@core3.amsl.com> Date: Mon, 21 Sep 2009 09:00:02 -0700 (PDT) X-Mailman-Approved-At: Mon, 21 Sep 2009 09:04:40 -0700 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-00.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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : PMIPv6 Localized Routing Problem Statement Author(s) : M. Liebsch, et al. Filename : draft-ietf-netext-pmip6-lr-ps-00.txt Pages : 16 Date : 2009-09-21 Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip6-lr-ps-00.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-pmip6-lr-ps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-21085833.I-D@ietf.org> --NextPart-- From Basavaraj.Patil@nokia.com Wed Sep 23 13:04:32 2009 Return-Path: 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 935A93A6405 for ; Wed, 23 Sep 2009 13:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 DgNykFzbfa-g for ; Wed, 23 Sep 2009 13:04:31 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B91533A685B for ; Wed, 23 Sep 2009 13:04:31 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8NK4k79027780 for ; Wed, 23 Sep 2009 15:04:49 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 23:05:35 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 23:05:30 +0300 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 23 Sep 2009 22:05:29 +0200 From: To: Date: Wed, 23 Sep 2009 22:05:42 +0200 Thread-Topic: Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 Thread-Index: Aco8iTpQD8qZCyC7Xkm+4SWUnC5pIQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Sep 2009 20:05:30.0151 (UTC) FILETIME=[33402B70:01CA3C89] X-Nokia-AV: Clean Subject: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 20:04:32 -0000 Hello, Regarding the scope of localized routing for PMIP6, I believe the current PS I-D has some issues w.r.t the following: 1. Localized routing for IPv4 HoA (Sec 3.3.1) I do not believe we should work on supporting LR for IPv4 HoA at this time. Given the possibility of multiple MNs with the same IPv4 HoA (RFC1918 addresses) in a PMIP6 domain, we will be bogged down on this capability. Lets just worry about LR for only the IPv6 prefix/address.=20 2. Transport network between the MAGs (Sec 3.3.2) Rather than making assumptions about the capability of MAGs in a PMIP6 domain, and defining negotiation mechanisms, we can make an assumption that MAGs support IPv6 transport. Keeping the scope constrained will ensure we get something done here. So I would recommend (with chair hat on) that we delete secs 3.3, 3.3.1 and 3.3.2.=20 -Chairs From sunseawq@huawei.com Wed Sep 23 19:23:02 2009 Return-Path: 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 48EB83A695E for ; Wed, 23 Sep 2009 19:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.23 X-Spam-Level: X-Spam-Status: No, score=-0.23 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 W21nuFi4Tx4Q for ; Wed, 23 Sep 2009 19:23:01 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 310773A66B4 for ; Wed, 23 Sep 2009 19:23:01 -0700 (PDT) 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 <0KQG00F2XENXBS@szxga01-in.huawei.com> for netext@ietf.org; Thu, 24 Sep 2009 10:23:58 +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 <0KQG00341ENXIP@szxga01-in.huawei.com> for netext@ietf.org; Thu, 24 Sep 2009 10:23:57 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQG00A7EENWSA@szxml04-in.huawei.com> for netext@ietf.org; Thu, 24 Sep 2009 10:23:57 +0800 (CST) Date: Thu, 24 Sep 2009 10:23:56 +0800 From: Qin Wu To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <00c201ca3cbe$11db7bd0$260ca40a@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: Subject: Re: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 02:23:02 -0000 Hi,: What I feel for the current PS I-D is IPv4 aspect is a little bit fatter than IPv6 aspect. I agree we need to focus on LR for IPv6 and some of issues in the IPv4 aspect are not big/urgent issue which may complicate LR signaling design,e.g., Private IPv4 addressing, we can delete it if there is no interests on it. But I am not sure we need to remove all the IPv4 aspect and narrow the scope to the LR for the only IPv6 aspect. Given the current IPv6 deployment,the transition from IPv4 to IPv6 is still a insurmountable phase. Also there are some existing relevant work in IETF,e.g, draft-ietf-netlmm-pmip6-ipv4-support-17, but LR aspect is not covered. And 3GPP provided some standards to support dual stack operation. So I am wondering 1)Is there any pragmatic IPv4 issues that needs to be addressed in the LR PS draft but not necessarily to be covered by PS solution work? 2)Whether we should obviate all the IPv4 part from the LR PS draft? How about shortening and even dropping some of the text. Regards! -Qin ----- Original Message ----- From: To: Sent: Thursday, September 24, 2009 4:05 AM Subject: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00 > > Hello, > > Regarding the scope of localized routing for PMIP6, I believe the > current PS I-D has some issues w.r.t the following: > > 1. Localized routing for IPv4 HoA (Sec 3.3.1) > I do not believe we should work on supporting LR for IPv4 HoA at this > time. Given the possibility of multiple MNs with the same IPv4 HoA > (RFC1918 addresses) in a PMIP6 domain, we will be bogged down on this > capability. Lets just worry about LR for only the IPv6 > prefix/address. > > 2. Transport network between the MAGs (Sec 3.3.2) > Rather than making assumptions about the capability of MAGs in a PMIP6 > domain, and defining negotiation mechanisms, we can make an assumption > that MAGs support IPv6 transport. Keeping the scope constrained will > ensure we get something done here. > > So I would recommend (with chair hat on) that we delete secs 3.3, > 3.3.1 and 3.3.2. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext