From gwz@net-zen.net Sat Jan 1 22:07:13 2011 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 884613A68BF for ; Sat, 1 Jan 2011 22:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.736 X-Spam-Level: X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DsHx0kDm8RgC for ; Sat, 1 Jan 2011 22:06:57 -0800 (PST) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id DF7653A684E for ; Sat, 1 Jan 2011 22:06:32 -0800 (PST) Received: (qmail 12266 invoked from network); 2 Jan 2011 06:08:37 -0000 Received: from unknown (115.87.110.4) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 02 Jan 2011 06:08:36 -0000 From: "Glen Zorn" To: Date: Sun, 2 Jan 2011 13:08:09 +0700 Organization: Network Zen Message-ID: <000001cbaa43$705b1820$51114860$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuqQ23R8w+blFxCQV+DunfTXUcRMQ== Content-Language: en-us Subject: [netext] Review of draft-ietf-netext-radius-pmip6-01 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, 02 Jan 2011 06:07:13 -0000 There are many grammatical errors. For example, in the very first sentence of section 1 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is network based mobility management protocol which allows IP mobility session continuity for a Mobile Node (MN) without its involvement in mobility management signaling. This should read something like Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility management protocol which allows IP mobility session continuity for a Mobile Node (MN) without its involvement in mobility management signaling. However, this still reads pretty clumsily; in particular, it's difficult for me to tell which entity "its" refers to and the usage of "network-based" is jargon that only has meaning if one is already familiar with PMIP; since this draft is presumably aimed at RADIUS implanters, I think it would be good to avoid as much PMIP-specific jargon as possible. Similarly, the terms "download" and "interface" are used repeatedly. "Download" has AFAIK no meaning WRT to RADIUS and "interface", while "real 3G" is also not particularly useful in this context. For example, Section 1 says: This document defines the RADIUS [RFC2865] based profile and the corresponding attributes to be used on the AAA interface between the MAG and the RADIUS server. This interface is used to download the per MN Policy Profile from the remote Policy Store to the MAG, at the point when MN attaches to a PMIPv6 Domain. I suspect that what this means that the per-MN profile is returned in a RADIUS Access-Accept message encapsulated in the Attributes defined by this draft (and I shouldn't need to guess). The same section continues: Furthermore, this document also defines a RADIUS-based interface between the LMA and the RADIUS server for authorization of the received Proxy Binding Update (PBU) messages for the mobility service session. Actually, it doesn't: some Attributes are defined, but how they are used is left almost completely unspecified. The statement that "The terminology in this document is based on the definitions found in [RFC5213] and [I-D.ietf-netlmm-pmip6-ipv4-support]" in Section 2 strongly suggests that the reader must have read and understood draft-ietf-netlmm-pmip6-ipv4-support and that, therefore, that draft would be a normative reference but it's not. In Section 2, the definition of "Network Access Server (NAS)" says A device that provides the access service for a user to a network. In the context of this document the NAS may be integrated into or co-located with the MAG. The NAS device contains the RADIUS Client function. What happens in the context of this document if the NAS is _not_ integrated or co-located with the MAG? Since the statement is that the NAS "contains the RADIUS Client (sic) functionality", my guess is nothing ;-). Similarly, even if the MAG and NAS are co-located, unless they communicate nothing will happen. Furthermore, Section 3 says that the MAG 'acts as a NAS', which seems more accurate but isn't the same as 'integrated with' or 'co-located with'. I _think_ that what is really meant is that the MAG acts as a RADIUS client, but it's really hard to tell... I could go on at (much) greater length, but basically this draft either a) says too much (i.e., claims to provide a "solution" while just doing a lot of hand-waving) or b) says way too little for the same reason. My suggestion would be to either a) get rid of the "solution" stuff and _only_ define the needed Attributes or b) actually describe how these Attributes are to be used in detail. From Basavaraj.Patil@nokia.com Tue Jan 4 10:05:22 2011 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 58D4D3A6B73 for ; Tue, 4 Jan 2011 10:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zdsUt0rSQmTl for ; Tue, 4 Jan 2011 10:05:21 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 4D8DE3A699F for ; Tue, 4 Jan 2011 10:05:21 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p04I7Rhs012348 for ; Tue, 4 Jan 2011 20:07:27 +0200 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.4675); Tue, 4 Jan 2011 20:07:22 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 4 Jan 2011 19:07:21 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.118]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi; Tue, 4 Jan 2011 19:07:21 +0100 From: To: Thread-Topic: WG last call: draft-ietf-netext-pmip6-lr-ps-03 Thread-Index: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIA== Date: Tue, 4 Jan 2011 18:07:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: <54541293-9ad8-4bb5-bc73-7010b7416268> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2011 18:07:22.0142 (UTC) FILETIME=[3BCAD3E0:01CBAC3A] X-Nokia-AV: Clean Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 04 Jan 2011 18:05:22 -0000 At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem Statement" I-D following a WG last call. The I-D has gone through a WG last call previously. Please consider this as the WG last call for the following I-D: draft-ietf-netext-pmip6-lr-ps-03.txt Reviews and feedback are appreciated. The WG last call will expire on Jan 20th.=20 Please note that progress of documents is only possible when we have enough people reviewing the WG documents. -Chairs From jouni.nospam@gmail.com Wed Jan 5 03:17:21 2011 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 16A893A6E17 for ; Wed, 5 Jan 2011 03:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 YgFPKTLn+xuv for ; Wed, 5 Jan 2011 03:17:20 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 103BB3A6D3C for ; Wed, 5 Jan 2011 03:17:19 -0800 (PST) Received: by bwz12 with SMTP id 12so15243328bwz.31 for ; Wed, 05 Jan 2011 03:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ODWWaNJPZThYTgpACd0JWzpgow9X1tFOmmekqyfIUN0=; b=UQpQfCOeCre0rX09i20rD2Z2NwLXy4xHxoTzaqGYCewZfkPuGTyqR81xG1DZ5XZStQ aDmCDZV4RoIjmxkiIXxkKX8JHhJJ0ktBoSfJsELpn25kEArUG1R9cnjBXOXblvW3J6OZ GAYGghT+9w4ZW9mpYy/rhOnZvZGF9egjVOwdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=NlJ7/sdDC4SKSYlAsiB1YwhH277k4xFUOY0ZDHBwz2hRNfsbOcQB58iH6Ect4i0jpM x3SSke3WvE0XASXNrcPu2sSkWocWEOUdyjabVlSl/um/rnVCEWQnHxejZr289C1V2bAR zJg21R7GAEakpLzl7AzEj75WUMJvHnNuxnBLk= Received: by 10.204.73.78 with SMTP id p14mr17472816bkj.47.1294226366247; Wed, 05 Jan 2011 03:19:26 -0800 (PST) Received: from a88-112-206-34.elisa-laajakaista.fi (a88-112-206-34.elisa-laajakaista.fi [88.112.206.34]) by mx.google.com with ESMTPS id 12sm12700206bki.7.2011.01.05.03.19.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 03:19:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 5 Jan 2011 13:19:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rajeev Koodli X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] LMA Redirect ID 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, 05 Jan 2011 11:17:21 -0000 Rajeev, Thanks for a thorough review. I'll address these comments in a new = 'draft' revision and then come up with additional comments if/when I = disagree with something. - Jouni On Dec 9, 2010, at 7:40 AM, Rajeev Koodli wrote: >=20 > Hi Jouni, All,=20 >=20 > Attached is the document with my review of the ID. > Please have a look. >=20 > Regards, >=20 > -Rajeev > = ___________________________________________= ____ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Dirk.von-Hugo@telekom.de Wed Jan 5 03:27:55 2011 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 D0C823A6D3C for ; Wed, 5 Jan 2011 03:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 AiSwHSlkQe5x for ; Wed, 5 Jan 2011 03:27:54 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 64F073A6CD5 for ; Wed, 5 Jan 2011 03:27:53 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 05 Jan 2011 12:29:55 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Jan 2011 12:29:55 +0100 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: Wed, 5 Jan 2011 12:29:54 +0100 Message-ID: <643B0A1D1A13AB498304E0BBC802784802E6C5B6@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 Thread-Index: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIJPCHSlQ References: From: To: , X-OriginalArrivalTime: 05 Jan 2011 11:29:55.0668 (UTC) FILETIME=[E0996940:01CBACCB] Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 05 Jan 2011 11:27:56 -0000 Dear all, I have read the draft and think it has improved, is concise, clear, and correct ... Beyond some nits detected as follows:=20 Ch. 3.1:=20 Hence, providing the necessary protocol specification to enable localized routing in PMIPv6 is necessary. =3D> I think it sounds nice when we exchange 'necessary' by 'required' = or 'strongly recommended' Ch. 3.2: s/being build by the CN's/being built by the CN's/ =3D> or may we omit 'being' completely?=20 ... considered as the MN's current pCoA, =3D> add explanation (previous CoA, Proxy-CoA, ... ?) s/Accordingly, these topological difference are denoted/Accordingly, these topological differences are denoted/=20 s/without traversing the MNs' LMA(s)/without traversing the MNs' LMA(s)./ Ch. 3.3.2: s/domain . Optional mechanisms for negotiating the IP version to use as well as the encapsulation mode to use are outside the scope/domain. Design of optional mechanisms for negotiating the IP version to use as well as the encapsulation mode to use is outside the scope/=20 Ch.5: s/registration of the MN or the CN respectively./registration of the MN or the CN, respectively./ s/by CN's MAG (MAG2/MAG2') and its LMA (LMA2)./by CN's MAG (MAG2/MAG2') and its LMA (LMA2/LMA2')./=20 s/are located in provider domain A/are located in provider domain A./ s/and CN's LMA (LMA2) is located in provider domain B/and CN's LMA (LMA2') is located in provider domain B./ Thanks for all the work to editors and chairs ... And a Happy New Year to all! Best regards Dirk =20 Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag von Basavaraj.Patil@nokia.com Gesendet: Dienstag, 4. Januar 2011 19:07 An: netext@ietf.org Betreff: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem Statement" I-D following a WG last call. The I-D has gone through a WG last call previously. Please consider this as the WG last call for the following I-D: draft-ietf-netext-pmip6-lr-ps-03.txt Reviews and feedback are appreciated. The WG last call will expire on Jan 20th.=20 Please note that progress of documents is only possible when we have enough people reviewing the WG documents. -Chairs _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From xiayangsong@huawei.com Wed Jan 5 15:34:05 2011 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 2985B3A6CD9 for ; Wed, 5 Jan 2011 15:34:05 -0800 (PST) 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 CWnUtSzzU-WY for ; Wed, 5 Jan 2011 15:34:04 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 1F3903A6C1E for ; Wed, 5 Jan 2011 15:34:04 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEK00DUKPK04U@szxga05-in.huawei.com> for netext@ietf.org; Thu, 06 Jan 2011 07:36:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEK00IOPPK0TD@szxga05-in.huawei.com> for netext@ietf.org; Thu, 06 Jan 2011 07:36:00 +0800 (CST) Received: from X24512z ([10.193.34.79]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEK005PGPJR73@szxml04-in.huawei.com> for netext@ietf.org; Thu, 06 Jan 2011 07:36:00 +0800 (CST) Date: Wed, 05 Jan 2011 15:35:51 -0800 From: Frank Xia In-reply-to: To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <005c01cbad31$4b34def0$4f22c10a@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: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIJPDBm2A References: Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 05 Jan 2011 23:34:05 -0000 Hi guys I have a quick review of this draft. My main concern is about the concept of CN(Correspondent Node). Firstly, there is another definition in RFC3775 regarding CN. What is the relationship between these two definitions? Secondly, My impression is that the draft mostly assumes CNs are always attached to MAGs. The draft should make it clear that CNs could be mobile or stationary. It would be better to state why stationary CNs are not taken into account. Lastly, this draft uses "set up" as a noun, e.g "The set up and maintenance of localized routing". I am not sure if its appropriate. BR Frank -----Original Message----- From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Tuesday, January 04, 2011 10:07 AM To: netext@ietf.org Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem Statement" I-D following a WG last call. The I-D has gone through a WG last call previously. Please consider this as the WG last call for the following I-D: draft-ietf-netext-pmip6-lr-ps-03.txt Reviews and feedback are appreciated. The WG last call will expire on Jan 20th. Please note that progress of documents is only possible when we have enough people reviewing the WG documents. -Chairs _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From Xiangsong.Cui@huawei.com Thu Jan 6 23:34:19 2011 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 8B84E3A67D8 for ; Thu, 6 Jan 2011 23:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.588, 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 6a6LQy-Jq3E5 for ; Thu, 6 Jan 2011 23:34:18 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3D0333A67D3 for ; Thu, 6 Jan 2011 23:34:18 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEN00ALM6GELN@szxga05-in.huawei.com> for netext@ietf.org; Fri, 07 Jan 2011 15:36:14 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEN0088X6GDP6@szxga05-in.huawei.com> for netext@ietf.org; Fri, 07 Jan 2011 15:36:14 +0800 (CST) Date: Fri, 07 Jan 2011 15:36:12 +0800 From: Xiangsong Cui In-reply-to: To: Basavaraj.Patil@nokia.com, netext@ietf.org Message-id: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIJPE5dNQ References: Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 07 Jan 2011 07:34:19 -0000 Hi, I have read this draft, and I have some comments. The scope of the base protocol covers the set up and maintenance of a forwarding tunnel between an MN's Mobility Access Gateway (MAG) and its selected Local Mobility Anchor (LMA). MAG is defined as Mobile Access Gateway in RFC5213. Localized Routing States: Information for localized routing on relevant forwarding entities on the direct data path between an MN and a CN. "direct data path" seems not clear enough. Mechanisms for route optimization in MIPv6 cannot be directly applied in PMIPv6, as MNs do not take part in mobility management and associated signaling. Following the paradigm of PMIPv6, MNs are not involved in mobility signaling, hence cannot perform signaling to set up localized routes. These two sentences seem a bit duplicated or redundant to me. Instead, the PMIPv6 functional entities of the LMA and MAG, which are involved in the mobility management of the MN and the CN, must be able to find out whether or not a localized route is to be used and then control the setup and maintenance of localized routing states accordingly without any assistance from the MN and the CN. I feel uncomfortable in the "must". Section 2 reads, o Localized Routing: Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN, which are attached to the **same provider domain** without intervention of the MN's LMA and the CN's LMA in data forwarding. However, section 5 says, A solution for localized routing cannot take any assumption about **whether or not MN and CN share the same PMIPv6 domain**, ... It is not required that LMAs, which hold the registration for the MN and the CN respectively, are part of the **same provider domain** as the MAGs where MN and CN attach. it is confusing, localized routing is intra-domain-only or inter-domain-possible? Regards, Xiangsong > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Wednesday, January 05, 2011 2:07 AM > To: netext@ietf.org > Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > > > At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem > Statement" I-D following a WG last call. > The I-D has gone through a WG last call previously. Please consider this > as the WG last call for the following I-D: > draft-ietf-netext-pmip6-lr-ps-03.txt > > > Reviews and feedback are appreciated. The WG last call will expire on Jan > 20th. > > Please note that progress of documents is only possible when we have > enough people reviewing the WG documents. > > -Chairs > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From gwz@net-zen.net Fri Jan 7 01:08:29 2011 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 8F1763A67ED for ; Fri, 7 Jan 2011 01:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 O9jlxyYMJql0 for ; Fri, 7 Jan 2011 01:08:28 -0800 (PST) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id C74C73A67E3 for ; Fri, 7 Jan 2011 01:08:28 -0800 (PST) Received: (qmail 6663 invoked from network); 7 Jan 2011 09:10:34 -0000 Received: from unknown (124.122.87.72) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 07 Jan 2011 09:10:33 -0000 From: "Glen Zorn" To: "'Xiangsong Cui'" References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> In-Reply-To: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> Date: Fri, 7 Jan 2011 16:10:16 +0700 Organization: Network Zen Message-ID: <000301cbae4a$b5877f00$20967d00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIJPE5dNQgABV4wA= Content-Language: en-us Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 07 Jan 2011 09:08:29 -0000 Xiangsong Cui [mailto://Xiangsong.Cui@huawei.com] writes: > Localized Routing States: Information for localized routing on > relevant forwarding entities on the direct data path between an MN > and a CN. > > "direct data path" seems not clear enough. Have a suggestion? ... > Instead, the PMIPv6 functional entities of the LMA and MAG, which are > involved in the mobility management of the MN and the CN, must be > able to find out whether or not a localized route is to be used and > then control the setup and maintenance of localized routing states > accordingly without any assistance from the MN and the CN. > > I feel uncomfortable in the "must". I don't understand why not. ... From Xiangsong.Cui@huawei.com Fri Jan 7 01:31:22 2011 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 7A3443A67FD for ; Fri, 7 Jan 2011 01:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=1.443, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 02eSpk5T--2s for ; Fri, 7 Jan 2011 01:31:21 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7D36C3A67EE for ; Fri, 7 Jan 2011 01:31:21 -0800 (PST) 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 <0LEN007MWBV7W5@szxga04-in.huawei.com> for netext@ietf.org; Fri, 07 Jan 2011 17:33:07 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEN00KDEBV6P6@szxga04-in.huawei.com> for netext@ietf.org; Fri, 07 Jan 2011 17:33:07 +0800 (CST) Date: Fri, 07 Jan 2011 17:33:07 +0800 From: Xiangsong Cui In-reply-to: <000301cbae4a$b5877f00$20967d00$@net> To: 'Glen Zorn' Message-id: <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIJPE5dNQgABV4wCAAAUScA== References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <000301cbae4a$b5877f00$20967d00$@net> Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 07 Jan 2011 09:31:22 -0000 > > Localized Routing States: Information for localized routing on > > relevant forwarding entities on the direct data path between an MN > > and a CN. > > > > "direct data path" seems not clear enough. > > Have a suggestion? This is a difficult job to me, too, but I would like to try. Localized Routing States: Information for localized routing on relevant forwarding entities, which route the packets directly to the care-of address of the destination node, rather than the home address. > > ... > > > Instead, the PMIPv6 functional entities of the LMA and MAG, which are > > involved in the mobility management of the MN and the CN, must be > > able to find out whether or not a localized route is to be used and > > then control the setup and maintenance of localized routing states > > accordingly without any assistance from the MN and the CN. > > > > I feel uncomfortable in the "must". > > I don't understand why not. Is it wrong if the entity is NOT able to find out ... ? Xiangsong > > ... > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From gwz@net-zen.net Fri Jan 7 01:56:25 2011 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 391853A6804 for ; Fri, 7 Jan 2011 01:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 BrAR-PqqjMww for ; Fri, 7 Jan 2011 01:56:24 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 6E4CD3A6800 for ; Fri, 7 Jan 2011 01:56:24 -0800 (PST) Received: (qmail 10073 invoked from network); 7 Jan 2011 09:58:30 -0000 Received: from unknown (124.120.147.24) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 07 Jan 2011 09:58:29 -0000 From: "Glen Zorn" To: "'Xiangsong Cui'" References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <000301cbae4a$b5877f00$20967d00$@net> <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> In-Reply-To: <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> Date: Fri, 7 Jan 2011 16:58:11 +0700 Organization: Network Zen Message-ID: <001a01cbae51$67ac4c00$3704e400$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIJPE5dNQgABV4wCAAAUScIAACOVg Content-Language: en-us Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 07 Jan 2011 09:56:25 -0000 Xiangsong Cui [mailto://Xiangsong.Cui@huawei.com] writes: ... > > > Instead, the PMIPv6 functional entities of the LMA and MAG, which > are > > > involved in the mobility management of the MN and the CN, must be > > > able to find out whether or not a localized route is to be used > and > > > then control the setup and maintenance of localized routing > states > > > accordingly without any assistance from the MN and the CN. > > > > > > I feel uncomfortable in the "must". > > > > I don't understand why not. > > Is it wrong if the entity is NOT able to find out ... ? If both the LMA & MAG support localized routing but can't decide whether or not to use it, that seems like a problem to me. ... From Xiangsong.Cui@huawei.com Fri Jan 7 02:03:16 2011 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 412D63A6810 for ; Fri, 7 Jan 2011 02:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=1.371, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 PR49ZhLUsJI9 for ; Fri, 7 Jan 2011 02:03:15 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6564B3A67EE for ; Fri, 7 Jan 2011 02:03:15 -0800 (PST) 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 <0LEN00AGGDCIPE@szxga04-in.huawei.com> for netext@ietf.org; Fri, 07 Jan 2011 18:05:06 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEN0091FDCIY0@szxga04-in.huawei.com> for netext@ietf.org; Fri, 07 Jan 2011 18:05:06 +0800 (CST) Date: Fri, 07 Jan 2011 18:05:05 +0800 From: Xiangsong Cui In-reply-to: <001a01cbae51$67ac4c00$3704e400$@net> To: 'Glen Zorn' Message-id: <00b601cbae52$5bcd65d0$13683170$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AQHLrDo7IQk/iUAI/U6rn7SmfqrIIJPE5dNQgABV4wCAAAUScIAACOVggAABdXA= References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <000301cbae4a$b5877f00$20967d00$@net> <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> <001a01cbae51$67ac4c00$3704e400$@net> Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 07 Jan 2011 10:03:16 -0000 > If both the LMA & MAG support localized routing but can't decide whether or > not to use it, that seems like a problem to me. This is just a problem statement, why do you have the assumption of "LMA & MAG support localized routing"? Xiangsong > > ... > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Jan 10 13:32:19 2011 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 1AE583A6822 for ; Mon, 10 Jan 2011 13:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.399 X-Spam-Level: X-Spam-Status: No, score=-107.399 tagged_above=-999 required=5 tests=[AWL=3.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 FykR+x2DB2ae for ; Mon, 10 Jan 2011 13:32:18 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id D433B3A6825 for ; Mon, 10 Jan 2011 13:32:17 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0ALY8xh021345; Mon, 10 Jan 2011 23:34:32 +0200 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.4675); Mon, 10 Jan 2011 23:34:19 +0200 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 10 Jan 2011 22:34:18 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.110]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi; Mon, 10 Jan 2011 22:34:18 +0100 From: To: Thread-Topic: Review of I-D: draft-ietf-netext-pmip6-lr-ps Thread-Index: AQHLsQ4iEyr6y5t8/E2sokK370RtCA== Date: Mon, 10 Jan 2011 21:34:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: <0cbc11a1-a71d-483c-9c4c-6acc927ca077> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2011 21:34:19.0360 (UTC) FILETIME=[23826E00:01CBB10E] X-Nokia-AV: Clean Cc: draft-ietf-netext-pmip6-lr-ps@tools.ietf.org Subject: [netext] Review of I-D: draft-ietf-netext-pmip6-lr-ps 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, 10 Jan 2011 21:32:19 -0000 I-D: draft-ietf-netext-pmip6-lr-ps-03.txt Review comments: General: The I-D illustrates multiple scenarios and use cases for optimized routing. However the WG has clearly noted that the scope of such localized routing should be limited to the scope of a single PMIP6 domain. Inter-LMA routing is also out of scope. These points should be noted in the I-D as being relevant to the solution scope. Additional comments below: Issues: - It would be good to note in the introduction that RFC5213 (Sec 6.10.3) does allow packets between an MN and CN attached to a common MAG to be routed without having to traverse thru the LMA. - The scope of Localized routing as far as I understand is between nodes that are attached to a common LMA. There is no inter-LMA routing. The definition of localized routing in sec 2 seems to indicate otherwise. " Localized Routing: Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN, which are attached to the same provider domain without intervention of the MN's LMA and the CN's LMA in data forwarding. " Proposed change: Localized routing: The capability to route packets between an MN and CN which are attached to a common LMA but potentially different MAGs without having to traverse the LMA is refered to as localized routing.=20 - In sec 3.2, it would be useful to show the concept of a PMIP6 domain in the figure (Fig 1). You could make the argument that there could be multiple LMAs within the scope of a single PMI6 domain. However the PS doc needs to clearly state that the scope of LR is only between nodes that are served by a common LMA. - Also in Fig 1, you may want to illustrate multiple MAGs within the scope of a single LMA. - Case A11 is already handled by RFC5213. So maybe you can just mention it as such. - W.r.t A12 you need to also consider whether MAG1 is part of the same PMIP6 domain or is associated with LMAs that are in different PMIP6 domain. Do both LMAs have to authorize (EnableMAGLocalRouting flag) in order for this to work? - It is okay to include A22, but only as a potential use case. You may want to emphasise that the WG is not considering this use case because of the complexities involved. - In Sec 3.3.2: "Optional mechanisms for negotiating the IP version to use as well as the encapsulation mode to use are outside the scope of the NetExt WG's solution for localized routing." =20 Why does the PS I-D have to say anything about solution scope? - The functional requirements in Sec 4 appear to be specifying a solution. This section could be safely dropped IMO. Editorial: - s/for network-based localized mobility management (NetLMM) which takes basic operation for registration, de-registration and handover into account. /for network-based localized mobility managment. - s/Even though an MN may be attached to the same or a different MAG as its Correspondent Node (CN) within the same provider domain, packets being associated with their communication will traverse the MN's and the CN's LMA./Packets associated with a session between an MN and CN which are attached to the same PMIP6 domain via a common LMA are always routed via the LMA.=20 - s/The NetLMM Extensions (NetExt) Working Group has an objective to design a solution for localized routing in PMIPv6./An optimized approach to routing of packets between nodes attached to a common LMA is considered useful. The NetLMM Extensions (NetExt) working group has a charter item to specify a localized routing solution for Proxy Mobile IPv6. Rewrite the following with better clarity: " In case one or both nodes hand over to a different MAG, the localized routing protocol maintains the localized routing path. Relevant protocol interfaces may include the interface between associated MAGs, between a MAG and an LMA as well as between LMAs. " - s/3.1. General observation/Background and justification - s/At least some deployment would benefit from having such communication localized, rather than traverse the core network to the LMA(s)./Deployment benefit in terms of reduced backhaul is realized by having packets between an MN and CN associated with a common LMA localized to the relevant MAGs. - s/Localized routing is crucial at least/Localized routing is relevant at least - s/Hence, providing the necessary protocol specification to enable localized routing in PMIPv6 is necessary./Hence, specifying optimizations to packet routing between nodes attached to a common LMA has performance and cost benefits. - s/3.2. Analysis of different use cases/ Use Case analysis - s/The following list summarizes some key functions, which need to be performed by the PMIPv6 enabled network infrastructure to substitute mobile nodes in setting up a direct route./The following is a list of some of the key functions which need to be implemented by the MAG and LMA nodes in a PMIP6 enabled network. - In Sec 5, it would be worthwhile to also include some analysis text regarding which of the roaming scenarios may be considered out of scope at the present time. =20 -Basavaraj From Marco.Liebsch@neclab.eu Tue Jan 11 07:13:19 2011 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 0495728C2D3 for ; Tue, 11 Jan 2011 07:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 977PkEcFwSiv for ; Tue, 11 Jan 2011 07:13:18 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id C1BF228C2D0 for ; Tue, 11 Jan 2011 07:13:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9C29C280002A9; Tue, 11 Jan 2011 16:16:38 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u-9O+HPOYiC; Tue, 11 Jan 2011 16:16:38 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 7E6422800017A; Tue, 11 Jan 2011 16:16:23 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Jan 2011 16:15:18 +0100 Message-ID: <4D2C7401.6040303@neclab.eu> Date: Tue, 11 Jan 2011 16:15:13 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: References: <643B0A1D1A13AB498304E0BBC802784802E6C5B6@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC802784802E6C5B6@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 11 Jan 2011 15:13:19 -0000 Hi Dirk, thanks a lot for the review and your comments! Please find some feedback inline. Dirk.von-Hugo@telekom.de wrote: > Dear all, > I have read the draft and think it has improved, is concise, clear, and > correct ... Beyond some nits detected as follows: > > Ch. 3.1: > Hence, providing the > necessary protocol specification to enable localized routing in > PMIPv6 is necessary. > => I think it sounds nice when we exchange 'necessary' by 'required' or > 'strongly recommended' > 'recommended' sounds good. > Ch. 3.2: > s/being build by the CN's/being built by the CN's/ > => or may we omit 'being' completely? > yes, too many beings.. I think simply 'PMIP6 domain built by the CN's LMA..' should be ok. > ... considered as the MN's current pCoA, > => add explanation (previous CoA, Proxy-CoA, ... ?) > good point, I'll expand it. > s/Accordingly, these topological difference are denoted/Accordingly, > these topological differences are denoted/ > ok > s/without traversing the MNs' LMA(s)/without traversing the MNs' > LMA(s)./ > ok > Ch. 3.3.2: > > s/domain . Optional mechanisms for negotiating the IP version to use as > well as the encapsulation mode to use are outside the scope/domain. > Design of optional mechanisms for negotiating the IP version to use as > well as the encapsulation mode to use is outside the scope/ > ok > Ch.5: > s/registration of the MN or the CN respectively./registration of the MN > or the CN, respectively./ > ok > s/by CN's MAG (MAG2/MAG2') and its LMA (LMA2)./by CN's MAG (MAG2/MAG2') > and its LMA (LMA2/LMA2')./ > true > s/are located in provider domain A/are located in provider domain A./ > ok > s/and CN's LMA (LMA2) is located in provider domain B/and CN's LMA > (LMA2') is located in provider domain B./ > ok > Thanks for all the work to editors and chairs ... And a Happy New Year > to all! > Many thanks to you for finding and proposing revision to all these editorial items. Best regards, marco > Best regards > Dirk > > Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag > von Basavaraj.Patil@nokia.com > Gesendet: Dienstag, 4. Januar 2011 19:07 > An: netext@ietf.org > Betreff: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > > > At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem > Statement" I-D following a WG last call. > The I-D has gone through a WG last call previously. Please consider this > as the WG last call for the following I-D: > draft-ietf-netext-pmip6-lr-ps-03.txt > > > Reviews and feedback are appreciated. The WG last call will expire on > Jan > 20th. > > Please note that progress of documents is only possible when we have > enough people reviewing the WG documents. > > -Chairs > > _______________________________________________ > 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@neclab.eu Tue Jan 11 08:12:28 2011 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 615E23A698E for ; Tue, 11 Jan 2011 08:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 KaJUXV8jN0sU for ; Tue, 11 Jan 2011 08:12:27 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id BAF6B3A6809 for ; Tue, 11 Jan 2011 08:12:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0819A2C00040C; Tue, 11 Jan 2011 17:17:44 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX2Cm6Tjv6ap; Tue, 11 Jan 2011 17:17:43 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id DA4362C00040B; Tue, 11 Jan 2011 17:17:28 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Jan 2011 17:14:27 +0100 Message-ID: <4D2C81E2.30909@neclab.eu> Date: Tue, 11 Jan 2011 17:14:26 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Frank Xia References: <005c01cbad31$4b34def0$4f22c10a@china.huawei.com> In-Reply-To: <005c01cbad31$4b34def0$4f22c10a@china.huawei.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 11 Jan 2011 16:12:28 -0000 Hi Frank, thanks for your feedback. Please see inline. Frank Xia wrote: > Hi guys > > I have a quick review of this draft. My main concern is about > the concept of CN(Correspondent Node). > > Firstly, there is another definition in RFC3775 regarding CN. > What is the relationship between these two definitions? > I do not see these two definitions conflicting. RFC3775 says: "A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary." For the LR discussion, NetExt considers a specific setup, which has the MN's communication peer attached at a MAG as well. Only such use case is relevant for NetExt. The additional definition for the CN in the PS draft is to clarify where the CN is assumed for the use cases discussed in the PS. We had a discussion long time ago about using MN1-MN2 or MN-CN. We sticked to MN-CN to indicate also the direction of the communication setup. Hence, MN sends first data packets to CN, which can trigger the setup of a localized routing path. I also feel more comfortable in writing and reading such notation rather than always using MN1, MN2. If the WG finds this important to change, I can revise it. > Secondly, My impression is that the draft mostly assumes > CNs are always attached to MAGs. The draft should make > it clear that CNs could be mobile or stationary. It would > be better to state why stationary CNs are not taken into account. > Well, the CN can be stationary as long as it is attached to a MAG and managed by PMIPv6. I agree that managing such node with PMIP may not make too much sense. When it's stationary and *not* managed by PMIP, we enter the discussion again to consider regular IPv6 nodes on an access router. That has been addressed by Carlos long time ago. We mention this in section 3.1, 2nd paragraph, but chairs ruled it out from the solution. I agree that the definition of CN in the PS repeats some parts of RFC3775. We could revise text to say something like 'Take the definition according to RFC3775 and assume further characteristics for the CN, such as MAG-attached, PMIP managed.' Do you think this makes it clearer? > Lastly, this draft uses "set up" as a noun, e.g "The set up > and maintenance of localized routing". I am not sure if its > appropriate. > Ok, I'll check. Thanks, marco > BR > Frank > > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Tuesday, January 04, 2011 10:07 AM > To: netext@ietf.org > Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > > > At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem > Statement" I-D following a WG last call. > The I-D has gone through a WG last call previously. Please consider this > as the WG last call for the following I-D: > draft-ietf-netext-pmip6-lr-ps-03.txt > > > Reviews and feedback are appreciated. The WG last call will expire on Jan > 20th. > > Please note that progress of documents is only possible when we have > enough people reviewing the WG documents. > > -Chairs > > _______________________________________________ > 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@neclab.eu Tue Jan 11 08:47:51 2011 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 59E303A6A1F for ; Tue, 11 Jan 2011 08:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 T0a+b5ppWdoO for ; Tue, 11 Jan 2011 08:47:50 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 1BD803A67FD for ; Tue, 11 Jan 2011 08:47:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 63F8F280002A9; Tue, 11 Jan 2011 17:51:11 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0iyE8qFo6hE; Tue, 11 Jan 2011 17:51:11 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 462112800017B; Tue, 11 Jan 2011 17:50:56 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Jan 2011 17:49:51 +0100 Message-ID: <4D2C8A2E.8060204@neclab.eu> Date: Tue, 11 Jan 2011 17:49:50 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Xiangsong Cui References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> In-Reply-To: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 11 Jan 2011 16:47:51 -0000 Hi Xiangsong, thanks for your comments. Please see inline. Xiangsong Cui wrote: > Hi, > > I have read this draft, and I have some comments. > > > The scope of the base > protocol covers the set up and maintenance of a forwarding tunnel > between an MN's Mobility Access Gateway (MAG) and its selected Local > Mobility Anchor (LMA). > > MAG is defined as Mobile Access Gateway in RFC5213. > Ok, I'll revise the expanded wording accordingly. > Localized Routing States: Information for localized routing on > relevant forwarding entities on the direct data path between an MN > and a CN. > > "direct data path" seems not clear enough. > I remember we had some discussion on this. What about the following: '...entities on the optimized path between...' ? > Mechanisms for > route optimization in MIPv6 cannot be directly applied in PMIPv6, as > MNs do not take part in mobility management and associated signaling. > Following the paradigm of PMIPv6, MNs are not involved in mobility > signaling, hence cannot perform signaling to set up localized routes. > > These two sentences seem a bit duplicated or redundant to me. > Ok, let's omit the second part of the first sentence: 'Mechanisms for route optimization in MIPv6 cannot be directly applied in PMIPv6. Following the paradigm of PMIPv6, MNs are not involved in mobility signaling, hence cannot perform signaling to set up localized routes.' > Instead, the PMIPv6 functional entities of the LMA and MAG, which are > involved in the mobility management of the MN and the CN, must be > able to find out whether or not a localized route is to be used and > then control the setup and maintenance of localized routing states > accordingly without any assistance from the MN and the CN. > > I feel uncomfortable in the "must". > This has been discussed in further mails. I'll reply using the latest one of your discussion with Glen. > Section 2 reads, > o Localized Routing: Result of signaling to set up routing states on > relevant network entities to allow forwarding of data packets > between an MN and a CN, which are attached to the **same provider > domain** without intervention of the MN's LMA and the CN's LMA in > data forwarding. > > However, section 5 says, > A solution for localized routing cannot take any > assumption about **whether or not MN and CN share the same PMIPv6 > domain**, ... > It is not required that LMAs, which hold the registration for the MN > and the CN respectively, are part of the **same provider domain** as the > MAGs where MN and CN attach. > > it is confusing, localized routing is intra-domain-only or > inter-domain-possible? > Ok, I see. The first paragraph (Terminology) refers to the two MAGs, which must share the same provider domain according to a NetExt WG decision. The paragraph in section 5 refers to the anchors of the MN and the CN, hence talks about the LMAs in the roaming model. I agree we need to clarify this. What about the following: ' o Localized Routing: Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN, which are attached to MAGs sharing the same provider domain without intervention of the MN's LMA and the CN's LMA in data forwarding.' Section 5: 'A solution for localized routing cannot take any assumption about whether or not the MN's and CN's LMAs share the same PMIPv6 domain, ...' Does this revision make the text clearer? Thanks and best regards, marco > > Regards, > Xiangsong > > >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf >> > Of > >> Basavaraj.Patil@nokia.com >> Sent: Wednesday, January 05, 2011 2:07 AM >> To: netext@ietf.org >> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 >> >> >> At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem >> Statement" I-D following a WG last call. >> The I-D has gone through a WG last call previously. Please consider this >> as the WG last call for the following I-D: >> draft-ietf-netext-pmip6-lr-ps-03.txt >> >> >> Reviews and feedback are appreciated. The WG last call will expire on Jan >> 20th. >> >> Please note that progress of documents is only possible when we have >> enough people reviewing the WG documents. >> >> -Chairs >> >> _______________________________________________ >> 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@neclab.eu Tue Jan 11 09:00:13 2011 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 D289428C2C6 for ; Tue, 11 Jan 2011 09:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 6t+kKD8RPrij for ; Tue, 11 Jan 2011 09:00:11 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 53B3528C2AC for ; Tue, 11 Jan 2011 09:00:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A361F2800017B; Tue, 11 Jan 2011 18:03:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyDvukBO9O0U; Tue, 11 Jan 2011 18:03:32 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 877802800017A; Tue, 11 Jan 2011 18:03:17 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Jan 2011 18:02:12 +0100 Message-ID: <4D2C8D14.5080608@neclab.eu> Date: Tue, 11 Jan 2011 18:02:12 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Glen Zorn References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <000301cbae4a$b5877f00$20967d00$@net> <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> <001a01cbae51$67ac4c00$3704e400$@net> In-Reply-To: <001a01cbae51$67ac4c00$3704e400$@net> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, 'Xiangsong Cui' Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 11 Jan 2011 17:00:13 -0000 Hi Xiangsong, please see inline. Glen Zorn wrote: > Xiangsong Cui [mailto://Xiangsong.Cui@huawei.com] writes: > > ... > > >>>> Instead, the PMIPv6 functional entities of the LMA and MAG, which >>>> >> are >> >>>> involved in the mobility management of the MN and the CN, must be >>>> able to find out whether or not a localized route is to be used >>>> >> and >> >>>> then control the setup and maintenance of localized routing >>>> >> states >> >>>> accordingly without any assistance from the MN and the CN. >>>> >>>> I feel uncomfortable in the "must". >>>> >>> I don't understand why not. >>> >> Is it wrong if the entity is NOT able to find out ... ? >> > > If both the LMA & MAG support localized routing but can't decide whether or > not to use it, that seems like a problem to me. > > ... > > The sentence comprise two aspects: Finding out whether or not to optimize, and controlling the setup. 'Finding out' can be based on a third component or an indication, even a static policy to optimize for a particular pool of MN/CN prefixes. Still, it's the PMIP components who find out, using whatever mechanism This is needed, hence a must. Also the 'control of LR setup': We can rely only on existing PMIP components to enable LR, at least for the key functions like signaling etc. To solve the problem, I also see here a must. But if you have a proposal which takes these requirements into account and makes you feeling more comfortable, we can discuss this. marco > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Marco.Liebsch@neclab.eu Tue Jan 11 09:03:42 2011 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 0092D3A67AB for ; Tue, 11 Jan 2011 09:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 FQtBOv8dsj1Z for ; Tue, 11 Jan 2011 09:03:41 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id F15453A677E for ; Tue, 11 Jan 2011 09:03:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7EBA82C00040B; Tue, 11 Jan 2011 18:08:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx-dAAx9wNQz; Tue, 11 Jan 2011 18:08:58 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 6262A2C000403; Tue, 11 Jan 2011 18:08:43 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Jan 2011 18:05:42 +0100 Message-ID: <4D2C8DE5.10603@neclab.eu> Date: Tue, 11 Jan 2011 18:05:41 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Xiangsong Cui References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <000301cbae4a$b5877f00$20967d00$@net> <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> <001a01cbae51$67ac4c00$3704e400$@net> <00b601cbae52$5bcd65d0$13683170$%cui@huawei.com> In-Reply-To: <00b601cbae52$5bcd65d0$13683170$%cui@huawei.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 11 Jan 2011 17:03:42 -0000 Xiangsong Cui wrote: >> If both the LMA & MAG support localized routing but can't decide whether >> > or > >> not to use it, that seems like a problem to me. >> > > This is just a problem statement, why do you have the assumption of "LMA & > MAG support localized routing"? > I think because these are the only components we can do something to enable LR, which is the problem we want to analyze and solve. marco > Xiangsong > > >> ... >> >> >> _______________________________________________ >> 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 Xiangsong.Cui@huawei.com Tue Jan 11 17:39:59 2011 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 7367C3A682E for ; Tue, 11 Jan 2011 17:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=1.306, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 qovSzJm+YmE3 for ; Tue, 11 Jan 2011 17:39:58 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id ED22C3A6827 for ; Tue, 11 Jan 2011 17:39:57 -0800 (PST) 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 <0LEV00413ZDV54@szxga04-in.huawei.com> for netext@ietf.org; Wed, 12 Jan 2011 09:41:55 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV00E6GZDV08@szxga04-in.huawei.com> for netext@ietf.org; Wed, 12 Jan 2011 09:41:55 +0800 (CST) Date: Wed, 12 Jan 2011 09:41:55 +0800 From: Xiangsong Cui In-reply-to: <4D2C8A2E.8060204@neclab.eu> To: 'Marco Liebsch' Message-id: <00ba01cbb1f9$e4f29fb0$aed7df10$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acuxr6cJFH1vHEU/TAab5llDgJdSJwASTdew References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <4D2C8A2E.8060204@neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 12 Jan 2011 01:39:59 -0000 > > Localized Routing States: Information for localized routing on > > relevant forwarding entities on the direct data path between an MN > > and a CN. > > > > "direct data path" seems not clear enough. > > > I remember we had some discussion on this. What about the following: > '...entities on the optimized path between...' ? Yeah ;) the new words is ok to me. > > > Mechanisms for > > route optimization in MIPv6 cannot be directly applied in PMIPv6, as > > MNs do not take part in mobility management and associated signaling. > > Following the paradigm of PMIPv6, MNs are not involved in mobility > > signaling, hence cannot perform signaling to set up localized routes. > > > > These two sentences seem a bit duplicated or redundant to me. > > > Ok, let's omit the second part of the first sentence: > 'Mechanisms for route optimization in MIPv6 cannot be directly > applied in PMIPv6. Following the paradigm of PMIPv6, MNs are > not involved in mobility signaling, hence cannot perform signaling > to set up localized routes.' Ok. > > > Instead, the PMIPv6 functional entities of the LMA and MAG, which are > > involved in the mobility management of the MN and the CN, must be > > able to find out whether or not a localized route is to be used and > > then control the setup and maintenance of localized routing states > > accordingly without any assistance from the MN and the CN. > > > > I feel uncomfortable in the "must". > > > This has been discussed in further mails. I'll reply using the latest one > of your discussion with Glen. Ok. > > > Section 2 reads, > > o Localized Routing: Result of signaling to set up routing states on > > relevant network entities to allow forwarding of data packets > > between an MN and a CN, which are attached to the **same > provider > > domain** without intervention of the MN's LMA and the CN's LMA in > > data forwarding. > > > > However, section 5 says, > > A solution for localized routing cannot take any > > assumption about **whether or not MN and CN share the same PMIPv6 > > domain**, ... > > It is not required that LMAs, which hold the registration for the MN > > and the CN respectively, are part of the **same provider domain** as > the > > MAGs where MN and CN attach. > > > > it is confusing, localized routing is intra-domain-only or > > inter-domain-possible? > > > Ok, I see. The first paragraph (Terminology) refers to the two MAGs, which > must share the same provider domain according to a NetExt WG decision. > The paragraph in section 5 refers to the anchors of the MN and the CN, > hence talks about the LMAs in the roaming model. > I agree we need to clarify this. What about the following: > > ' o Localized Routing: Result of signaling to set up routing states on > relevant network entities to allow forwarding of data packets > between an MN and a CN, which are attached to MAGs sharing the > same provider domain without intervention of the MN's LMA and the > CN's LMA in data forwarding.' > > > Section 5: > > 'A solution for localized routing cannot take any assumption about > whether or not the MN's and CN's LMAs share the same PMIPv6 > domain, ...' > > Does this revision make the text clearer? Good, I see the points. Thanks and regards, Xiangsong > > > Thanks and best regards, > marco > > > > > > Regards, > > Xiangsong > > > > > >> -----Original Message----- > >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > >> > > Of > > > >> Basavaraj.Patil@nokia.com > >> Sent: Wednesday, January 05, 2011 2:07 AM > >> To: netext@ietf.org > >> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > >> > >> > >> At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem > >> Statement" I-D following a WG last call. > >> The I-D has gone through a WG last call previously. Please consider this > >> as the WG last call for the following I-D: > >> draft-ietf-netext-pmip6-lr-ps-03.txt > >> > >> > >> Reviews and feedback are appreciated. The WG last call will expire on Jan > >> 20th. > >> > >> Please note that progress of documents is only possible when we have > >> enough people reviewing the WG documents. > >> > >> -Chairs > >> > >> _______________________________________________ > >> 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 Xiangsong.Cui@huawei.com Tue Jan 11 17:48:24 2011 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 92B8F3A685B for ; Tue, 11 Jan 2011 17:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=1.246, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 sYtqt1OnGf3C for ; Tue, 11 Jan 2011 17:48:23 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id ABF303A6853 for ; Tue, 11 Jan 2011 17:48:23 -0800 (PST) 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 <0LEV00LNCZOPU6@szxga04-in.huawei.com> for netext@ietf.org; Wed, 12 Jan 2011 09:48:25 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV001A3ZOO7W@szxga04-in.huawei.com> for netext@ietf.org; Wed, 12 Jan 2011 09:48:25 +0800 (CST) Date: Wed, 12 Jan 2011 09:48:24 +0800 From: Xiangsong Cui In-reply-to: <4D2C8DE5.10603@neclab.eu> To: 'Marco Liebsch' Message-id: <00bc01cbb1fa$cd295710$677c0530$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: Acuxsdt+LmTNKWrzR/W1JXKhSbjKJAASCDvA References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <000301cbae4a$b5877f00$20967d00$@net> <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> <001a01cbae51$67ac4c00$3704e400$@net> <00b601cbae52$5bcd65d0$13683170$%cui@huawei.com> <4D2C8DE5.10603@neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 12 Jan 2011 01:48:24 -0000 > > This is just a problem statement, why do you have the assumption of "LMA & > > MAG support localized routing"? > > > I think because these are the only components we can do something to enable > LR, which is the problem we want to analyze and solve. If you say "To achieve localized routing, the entities must be able to (or say have to be able to) ...", I would be ok. But as Raj mentioned, the PS document should not say anything about the solution space, I'm not sure is it appropriate under this criterion. Regards, Xiangsong > > marco > > > Xiangsong > > > > > >> ... > >> > >> > >> _______________________________________________ > >> 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@neclab.eu Wed Jan 12 06:34:41 2011 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 CC24228C131 for ; Wed, 12 Jan 2011 06:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 wL-itKgbEy9e for ; Wed, 12 Jan 2011 06:34:40 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 4FB5E3A6A01 for ; Wed, 12 Jan 2011 06:34:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 13D062C0003D1; Wed, 12 Jan 2011 15:37:00 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBVSdyA-KSop; Wed, 12 Jan 2011 15:36:59 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id E3DDC2C000349; Wed, 12 Jan 2011 15:36:49 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Jan 2011 15:36:49 +0100 Message-ID: <4D2DBC7C.2030009@neclab.eu> Date: Wed, 12 Jan 2011 15:36:44 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Xiangsong Cui References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <4D2C8A2E.8060204@neclab.eu> <00ba01cbb1f9$e4f29fb0$aed7df10$%cui@huawei.com> In-Reply-To: <00ba01cbb1f9$e4f29fb0$aed7df10$%cui@huawei.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 12 Jan 2011 14:34:41 -0000 Hi Xiangsong, one correction of my proposal inline. Xiangsong Cui wrote: >>> Localized Routing States: Information for localized routing on >>> relevant forwarding entities on the direct data path between an MN >>> and a CN. >>> >>> "direct data path" seems not clear enough. >>> >>> >> I remember we had some discussion on this. What about the following: >> '...entities on the optimized path between...' ? >> > > Yeah ;) > the new words is ok to me. > > >>> Mechanisms for >>> route optimization in MIPv6 cannot be directly applied in PMIPv6, as >>> MNs do not take part in mobility management and associated signaling. >>> Following the paradigm of PMIPv6, MNs are not involved in mobility >>> signaling, hence cannot perform signaling to set up localized routes. >>> >>> These two sentences seem a bit duplicated or redundant to me. >>> >>> >> Ok, let's omit the second part of the first sentence: >> 'Mechanisms for route optimization in MIPv6 cannot be directly >> applied in PMIPv6. Following the paradigm of PMIPv6, MNs are >> not involved in mobility signaling, hence cannot perform signaling >> to set up localized routes.' >> > > Ok. > > >>> Instead, the PMIPv6 functional entities of the LMA and MAG, which are >>> involved in the mobility management of the MN and the CN, must be >>> able to find out whether or not a localized route is to be used and >>> then control the setup and maintenance of localized routing states >>> accordingly without any assistance from the MN and the CN. >>> >>> I feel uncomfortable in the "must". >>> >>> >> This has been discussed in further mails. I'll reply using the latest one >> of your discussion with Glen. >> > > Ok. > > >>> Section 2 reads, >>> o Localized Routing: Result of signaling to set up routing states on >>> relevant network entities to allow forwarding of data packets >>> between an MN and a CN, which are attached to the **same >>> >> provider >> >>> domain** without intervention of the MN's LMA and the CN's LMA in >>> data forwarding. >>> >>> However, section 5 says, >>> A solution for localized routing cannot take any >>> assumption about **whether or not MN and CN share the same PMIPv6 >>> domain**, ... >>> It is not required that LMAs, which hold the registration for the MN >>> and the CN respectively, are part of the **same provider domain** as >>> >> the >> >>> MAGs where MN and CN attach. >>> >>> it is confusing, localized routing is intra-domain-only or >>> inter-domain-possible? >>> >>> >> Ok, I see. The first paragraph (Terminology) refers to the two MAGs, which >> must share the same provider domain according to a NetExt WG decision. >> The paragraph in section 5 refers to the anchors of the MN and the CN, >> hence talks about the LMAs in the roaming model. >> I agree we need to clarify this. What about the following: >> >> ' o Localized Routing: Result of signaling to set up routing states on >> relevant network entities to allow forwarding of data packets >> between an MN and a CN, which are attached to MAGs sharing the >> same provider domain without intervention of the MN's LMA and the >> CN's LMA in data forwarding.' >> >> >> Section 5: >> >> 'A solution for localized routing cannot take any assumption about >> whether or not the MN's and CN's LMAs share the same PMIPv6 >> domain, ...' >> >> Does this revision make the text clearer? >> > > The paragraphs talk about different domains. The first one refers to the provider domain, whereas Section 5 refers to the PMIPv6 domain. I still think that the proposed revision to the Terms section helps to understand the requirement, that both MAGs must share the provider domain. For Section 5, I think we should stick to the original text, as it talks about PMIP domains, which are defined by the relation between an MN's MAG-LMA association. Ok with you? marco > Good, I see the points. > > Thanks and regards, > Xiangsong > > >> Thanks and best regards, >> marco >> >> >> >>> Regards, >>> Xiangsong >>> >>> >>> >>>> -----Original Message----- >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>> > Behalf > >>> Of >>> >>> >>>> Basavaraj.Patil@nokia.com >>>> Sent: Wednesday, January 05, 2011 2:07 AM >>>> To: netext@ietf.org >>>> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 >>>> >>>> >>>> At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem >>>> Statement" I-D following a WG last call. >>>> The I-D has gone through a WG last call previously. Please consider >>>> > this > >>>> as the WG last call for the following I-D: >>>> draft-ietf-netext-pmip6-lr-ps-03.txt >>>> >>>> >>>> Reviews and feedback are appreciated. The WG last call will expire on >>>> > Jan > >>>> 20th. >>>> >>>> Please note that progress of documents is only possible when we have >>>> enough people reviewing the WG documents. >>>> >>>> -Chairs >>>> >>>> _______________________________________________ >>>> 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 Marco.Liebsch@neclab.eu Wed Jan 12 07:28:05 2011 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 657C128C107 for ; Wed, 12 Jan 2011 07:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 laE-fs4kUmxx for ; Wed, 12 Jan 2011 07:28:04 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 920F028C143 for ; Wed, 12 Jan 2011 07:28:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E0193280001C2; Wed, 12 Jan 2011 16:31:27 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k08fkwwkwHx; Wed, 12 Jan 2011 16:31:27 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C6D482800019F; Wed, 12 Jan 2011 16:31:12 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Jan 2011 16:30:06 +0100 Message-ID: <4D2DC8FA.3040207@neclab.eu> Date: Wed, 12 Jan 2011 16:30:02 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Xiangsong Cui References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <000301cbae4a$b5877f00$20967d00$@net> <00b501cbae4d$e489c4e0$ad9d4ea0$%cui@huawei.com> <001a01cbae51$67ac4c00$3704e400$@net> <00b601cbae52$5bcd65d0$13683170$%cui@huawei.com> <4D2C8DE5.10603@neclab.eu> <00bc01cbb1fa$cd295710$677c0530$%cui@huawei.com> In-Reply-To: <00bc01cbb1fa$cd295710$677c0530$%cui@huawei.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 12 Jan 2011 15:28:05 -0000 Xiangsong Cui wrote: >>> This is just a problem statement, why do you have the assumption of "LMA >>> > & > >>> MAG support localized routing"? >>> >>> >> I think because these are the only components we can do something to >> > enable > >> LR, which is the problem we want to analyze and solve. >> > > If you say "To achieve localized routing, the entities must be able to (or > say have to be able to) ...", I would be ok. > Ok. 'Entities' is not really clear, IMHO. What about using 'the solution' and refer in this context to functions in the network as we cannot rely on the MN? Result: '...the solution must consider functions in the network to find out whether or not a localized route is to be used and then control the setup and maintenance of localized routing states accordingly without any assistance from the MN and the CN.' Is that ok? marco > But as Raj mentioned, the PS document should not say anything about the > solution space, I'm not sure is it appropriate under this criterion. > > Regards, > Xiangsong > > >> marco >> >> >>> Xiangsong >>> >>> >>> >>>> ... >>>> >>>> >>>> _______________________________________________ >>>> 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@neclab.eu Wed Jan 12 08:53:34 2011 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 253DC28C11C for ; Wed, 12 Jan 2011 08:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 XQKYqbXLdlKP for ; Wed, 12 Jan 2011 08:53:31 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 75E9E28C0EE for ; Wed, 12 Jan 2011 08:53:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id C02892C0003D1; Wed, 12 Jan 2011 17:55:51 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73oV58FhrPxo; Wed, 12 Jan 2011 17:55:51 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 9BD9F2C0003CC; Wed, 12 Jan 2011 17:55:36 +0100 (CET) Received: from [10.1.6.62] (10.1.6.62) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Jan 2011 17:55:35 +0100 Message-ID: <4D2DDD07.8030308@neclab.eu> Date: Wed, 12 Jan 2011 17:55:35 +0100 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org Subject: Re: [netext] Review of I-D: draft-ietf-netext-pmip6-lr-ps 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, 12 Jan 2011 16:53:34 -0000 Hi Raj, thanks for your review and comments. Please see inline. Basavaraj.Patil@nokia.com wrote: > I-D: draft-ietf-netext-pmip6-lr-ps-03.txt > > Review comments: > > General: > The I-D illustrates multiple scenarios and use cases for optimized > routing. However the WG has clearly noted that the scope of such > localized routing should be limited to the scope of a single PMIP6 > domain. I think section 3.2, where we start the analysis, can mention this. What about starting with the following intro: 'This problem statement focuses on local communication between PMIPv6 managed nodes being attached to MAGs sharing the same provider domain.' > Inter-LMA routing is also out of scope. I think routing between two LMAs is nothing we can influence. That happens when two MNs communicate, even without localized routing. > These points should be > noted in the I-D as being relevant to the solution scope. > Is the sentence above for section 3.2 ok with you? > Additional comments below: > > Issues: > > - It would be good to note in the introduction that RFC5213 (Sec > 6.10.3) does allow packets between an MN and CN attached to a common > MAG to be routed without having to traverse thru the LMA. > Ok, we address this in 3.1, but can also refer to it in the Intro. However, I think that RFC5213 just *considers* it without *supporting* it. This means, the spec mandates the LMA to control such local routing, but means to control are not available. So, what about adding the following to the Intro: Intro: '...[RFC5213] addresses the need to enable local routing of traffic between two nodes being attached to the same MAG, but does not specify the complete procedure to establish such localized routing state on the shared MAG...' > - The scope of Localized routing as far as I understand is between > nodes that are attached to a common LMA. There is no inter-LMA > routing. The definition of localized routing in sec 2 seems to > indicate otherwise. > " Localized Routing: Result of signaling to set up routing states on > relevant network entities to allow forwarding of data packets > between an MN and a CN, which are attached to the same provider > domain without intervention of the MN's LMA and the CN's LMA in > data forwarding. > " > > Proposed change: > Localized routing: The capability to route packets between an MN and > CN which are attached to a common LMA but potentially different MAGs > without having to traverse the LMA is refered to as localized > routing. > Same as above, I do not think this can be influenced. When two PMIP managed MNs communicate, their traffic always traverses their LMAs, hence is routed between their LMAs. This has nothing to do with the localized routing issue. Hence, we cannot exclude this from the PS. Limiting the scope of a solution for LR to single MAG operation, this is something different. However, the NetExt WG's solution draft also specifies LR for multi-LMA scenarios. So, why shouldn't this be considered then in the PS. > - In sec 3.2, it would be useful to show the concept of a PMIP6 domain > in the figure (Fig 1). You could make the argument that there could > be multiple LMAs within the scope of a single PMI6 domain. However > the PS doc needs to clearly state that the scope of LR is only > between nodes that are served by a common LMA. > 3.2 does not make an assumption about PMIP domains, as it's not relevant. We went through the exercise to discuss and define the terms of PMIP domain versus provider domain. We use these terms as agreed. NetExt WG scope limitation to consider only MAGs sharing the same provider domain is explicitly mentioned in 3.2. Do you agree this is sufficient? Btw, distribution of LMAs and MAGs between different provider domains is discussed in the roaming section, which has been requested some time ago. I think this helps to understand the limitations. > - Also in Fig 1, you may want to illustrate multiple MAGs within the > scope of a single LMA. > Not exactly clear to me what you propose. It's just an architecture picture without associating MAGs to LMAs. This is done in section 3.2 and section 5. Maybe you can provide an example what you want to show in Fig 1 and indicate what's the advantage of showing this in Fig. 1. > - Case A11 is already handled by RFC5213. So maybe you can just > mention it as such. > Ok, same proposal as above, we can refer to what RFC5213 covers. Basically it would be the same text as I proposed above. Is this ok with you? One question: How does RFC5213 localized routing distinguish A11 from A12? And how do LMAs control the mandated enforcement of localized routing? > - W.r.t A12 you need to also consider whether MAG1 is part of the same > PMIP6 domain or is associated with LMAs that are in different PMIP6 > domain. Do both LMAs have to authorize (EnableMAGLocalRouting flag) > in order for this to work? > I do not know. I also cannot find this described in RFC5213. That's why I doubt this is specified and supported by RFC5213. How to handle this? > - It is okay to include A22, but only as a potential use case. You may > want to emphasise that the WG is not considering this use case > because of the complexities involved. > Ok, I can add a statement. But is this really the responsibility of the Problem Statement? Why should we enter the solution space and scope here? It's something the charter should indicate, isn't it? > - In Sec 3.3.2: > "Optional mechanisms for negotiating the IP version to use > as well as the encapsulation mode to use are outside the scope of the > NetExt WG's solution for localized routing." > > Why does the PS I-D have to say anything about solution scope? > Raj, now I am confused. Should the PS now refer to NetExt limitations or not? For the A22 scenarios you want to have it, for other things not. Please take a decision and let us know. > - The functional requirements in Sec 4 appear to be specifying a > solution. This section could be safely dropped IMO. > You're the only one proposing this so far. If the WG thinks this should be out, no problem. We don't see this as solution. The bullets just follow the problem analysis and list what's to be done to address the problems. This also differentiates the problems from MIPv6 RO problems. Maybe we can have more opinions on this? Btw, there were some comments from Xiangsong and we revised text to avoid solution specifics. > Editorial: > > - s/for network-based localized mobility management (NetLMM) which > takes basic operation for registration, de-registration and handover > into account. /for network-based localized mobility managment. > ok. > - s/Even though an MN may be attached to the > same or a different MAG as its Correspondent Node (CN) within the > same provider domain, packets being associated with their > communication will traverse the MN's and the CN's LMA./Packets > associated with a session between an MN and CN which are attached > to the same PMIP6 domain via a common LMA are always routed via the > LMA. > Why do you propose mixing again provider with PMIP domain? PMIP domain is not relevant here. 'provider domain' has been added here as requested to highlight the NetExt limitation, where both MAGs must share the same provider domain. I don't think we need to mention NetExt scope limitations in every second sentence.. For remaining editorial comments, I'll take over relevant comments which make text clearer. Most of the other proposals for editorial changes make an effort to limit the description to single LMA scenario, which even conflicts with NetExt scope, as the solution covers scenarios with multiple LMAs. So, would it be ok to keep the general PS, but mention the NetExt scope in the PS once? I think this is sufficient and should be clarified first. marco > - s/The NetLMM Extensions (NetExt) Working Group has an objective to > design a solution for localized routing in PMIPv6./An optimized > approach to routing of packets between nodes attached to a common > LMA is considered useful. The NetLMM Extensions (NetExt) working > group has a charter item to specify a localized routing solution > for Proxy Mobile IPv6. > > Rewrite the following with better clarity: > " In case one or both nodes hand over to a different MAG, the localized > routing protocol maintains the localized routing path. Relevant > protocol interfaces may include the interface between associated > MAGs, between a MAG and an LMA as well as between LMAs. > " > > - s/3.1. General observation/Background and justification > > > - s/At least some deployment would benefit from having such > communication localized, rather than traverse the core network to the > LMA(s)./Deployment benefit in terms of reduced backhaul is realized > by having packets between an MN and CN associated with a common LMA > localized to the relevant MAGs. > > - s/Localized routing is crucial at least/Localized routing is > relevant at least > > - s/Hence, providing the > necessary protocol specification to enable localized routing in > PMIPv6 is necessary./Hence, specifying optimizations to packet > routing between nodes attached to a common LMA has performance and > cost benefits. > > - s/3.2. Analysis of different use cases/ Use Case analysis > > - s/The following list summarizes some key functions, which need to > be performed by the PMIPv6 enabled network infrastructure to > substitute mobile nodes in setting up a direct route./The following > is a list of some of the key functions which need to be implemented > by the MAG and LMA nodes in a PMIP6 enabled network. > > - In Sec 5, it would be worthwhile to also include some analysis text > regarding which of the roaming scenarios may be considered out of > scope at the present time. > > -Basavaraj > > > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > From Internet-Drafts@ietf.org Wed Jan 12 09:45:02 2011 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 3714A3A68E2; Wed, 12 Jan 2011 09:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cNWdfd0vaPIB; Wed, 12 Jan 2011 09:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794D43A6817; Wed, 12 Jan 2011 09:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110112174501.10848.67911.idtracker@localhost> Date: Wed, 12 Jan 2011 09:45:01 -0800 Cc: netext@ietf.org Subject: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 17:45: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-04.txt Pages : 18 Date : 2011-01-12 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 setup 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-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netext-pmip6-lr-ps-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-12093350.I-D@ietf.org> --NextPart-- From xiayangsong@huawei.com Wed Jan 12 13:27:09 2011 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 D20A53A6774 for ; Wed, 12 Jan 2011 13:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 X7bUiMTHXvuI for ; Wed, 12 Jan 2011 13:27:08 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9D68E3A69C5 for ; Wed, 12 Jan 2011 13:27:08 -0800 (PST) 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 <0LEX00M5FICPWL@szxga04-in.huawei.com> for netext@ietf.org; Thu, 13 Jan 2011 05:29:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEX00AQ2ICPL9@szxga04-in.huawei.com> for netext@ietf.org; Thu, 13 Jan 2011 05:29:13 +0800 (CST) Received: from X24512z ([10.193.34.99]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00MG9ICFKL@szxml04-in.huawei.com> for netext@ietf.org; Thu, 13 Jan 2011 05:29:13 +0800 (CST) Date: Wed, 12 Jan 2011 13:29:02 -0800 From: Frank Xia In-reply-to: <4D2C81E2.30909@neclab.eu> To: 'Marco Liebsch' Message-id: <007501cbb29f$bd74e550$6322c10a@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: Acuxqr35u+6EjUi2RaC58k4XxDik/QA88RYg References: <005c01cbad31$4b34def0$4f22c10a@china.huawei.com> <4D2C81E2.30909@neclab.eu> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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, 12 Jan 2011 21:27:10 -0000 Hello Marco Thank your response. Please also check my inline comments... BR Frank -----Original Message----- From: Marco Liebsch [mailto:marco.liebsch@neclab.eu] Sent: Tuesday, January 11, 2011 8:14 AM To: Frank Xia Cc: Basavaraj.Patil@nokia.com; netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 Hi Frank, thanks for your feedback. Please see inline. Frank Xia wrote: > Hi guys > > I have a quick review of this draft. My main concern is about > the concept of CN(Correspondent Node). > > Firstly, there is another definition in RFC3775 regarding CN. > What is the relationship between these two definitions? > I do not see these two definitions conflicting. RFC3775 says: "A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary." For the LR discussion, NetExt considers a specific setup, which has the MN's communication peer attached at a MAG as well. Only such use case is relevant for NetExt. The additional definition for the CN in the PS draft is to clarify where the CN is assumed for the use cases discussed in the PS. We had a discussion long time ago about using MN1-MN2 or MN-CN. We sticked to MN-CN to indicate also the direction of the communication setup. Hence, MN sends first data packets to CN, which can trigger the setup of a localized routing path. I also feel more comfortable in writing and reading such notation rather than always using MN1, MN2. If the WG finds this important to change, I can revise it. > Secondly, My impression is that the draft mostly assumes > CNs are always attached to MAGs. The draft should make > it clear that CNs could be mobile or stationary. It would > be better to state why stationary CNs are not taken into account. > Well, the CN can be stationary as long as it is attached to a MAG and managed by PMIPv6. I agree that managing such node with PMIP may not make too much sense. When it's stationary and *not* managed by PMIP, we enter the discussion again to consider regular IPv6 nodes on an access router. That has been addressed by Carlos long time ago. We mention this in section 3.1, 2nd paragraph, but chairs ruled it out from the solution. Frank=>Stationary CN means here regular IPv6 nodes attaching an access router. This is a ps document even though only some of the problems could be dealt with. Whole picture of the problems is important to understand. I agree that the definition of CN in the PS repeats some parts of RFC3775. We could revise text to say something like 'Take the definition according to RFC3775 and assume further characteristics for the CN, such as MAG-attached, PMIP managed.' Do you think this makes it clearer? Frank=>I don't think so. Anyway, you figure it out, and this is not very important issue. > Lastly, this draft uses "set up" as a noun, e.g "The set up > and maintenance of localized routing". I am not sure if its > appropriate. > Ok, I'll check. Thanks, marco > BR > Frank > > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Tuesday, January 04, 2011 10:07 AM > To: netext@ietf.org > Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > > > At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem > Statement" I-D following a WG last call. > The I-D has gone through a WG last call previously. Please consider this > as the WG last call for the following I-D: > draft-ietf-netext-pmip6-lr-ps-03.txt > > > Reviews and feedback are appreciated. The WG last call will expire on Jan > 20th. > > Please note that progress of documents is only possible when we have > enough people reviewing the WG documents. > > -Chairs > > _______________________________________________ > 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 Xiangsong.Cui@huawei.com Wed Jan 12 19:39:11 2011 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 C00A63A6837 for ; Wed, 12 Jan 2011 19:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 KjHcJkDBdLzN for ; Wed, 12 Jan 2011 19:39:10 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A6D963A682A for ; Wed, 12 Jan 2011 19:39:10 -0800 (PST) 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 <0LEX003UNZKX7L@szxga03-in.huawei.com> for netext@ietf.org; Thu, 13 Jan 2011 11:41:21 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEX00K58ZKW1O@szxga03-in.huawei.com> for netext@ietf.org; Thu, 13 Jan 2011 11:41:21 +0800 (CST) Date: Thu, 13 Jan 2011 11:41:20 +0800 From: Xiangsong Cui In-reply-to: <4D2DBC7C.2030009@neclab.eu> To: 'Marco Liebsch' Message-id: <005101cbb2d3$be6dc6a0$3b4953e0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcuyZjQPiVry4B/mQFqIr+JjTl8crgAX3Mmw References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <4D2C8A2E.8060204@neclab.eu> <00ba01cbb1f9$e4f29fb0$aed7df10$%cui@huawei.com> <4D2DBC7C.2030009@neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Thu, 13 Jan 2011 03:39:11 -0000 > The paragraphs talk about different domains. The first one refers to the > provider > domain, whereas Section 5 refers to the PMIPv6 domain. I still think > that the > proposed revision to the Terms section helps to understand the requirement, > that both MAGs must share the provider domain. For Section 5, I think we > should stick to the original text, as it talks about PMIP domains, which are > defined by the relation between an MN's MAG-LMA association. Ok with you? I think I understand your point, but I still think the words is not clear enough. Firstly, I would like to see the terminology of "provider domain" and "PMIP domain". In addition, "home domain" is mentioned in section 5. In Section 2, localized routing is defined as (I refer to PS-draft-04), o Localized Routing: Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN, which are attached to MAGs sharing the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ same provider domain, without intervention of the MN's LMA and the CN's LMA in data forwarding. My questions to this definition are, If MN is attached to MAG1 while CN is attached to MAG2, however, MAG1 and MAG2 are from different carriers (the hint here is that the corresponding LMAs are also from different carriers), is this scenario falls in the scope of localized routing? MN and CN are NOT attached to MAGs in the same carrier network, is it true that the MAGs are NOT sharing the same "provider domain" in this case? In section 5, also saying about "provider domain", Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs, MAGs) tied by MN and CN may be distributed between different ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ provider domains (i.e., domain A, B, C) and MN and/or CN moves from ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ one provider domain to another one. In order to support localized routing when roaming occurs, it is required that MAGs to which MN and ^^^^^^^^^^^^^^^^^^^ CN connect are within the same provider domain and each MAG has a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ security relationship with the corresponding LMA which maintains the registration of the MN or the CN, respectively. The front says, in Figure 2, MAGs may be in different provider domains, and section 5 mainly refers to figure 2 (where MAGs are actually distributed in different provider domains), taking this as a basis, right? The end of this paragraph says it is required that MAGs are within the same provider domain, so should a "sharing-domain-figure" be provided as reference? Xiangsong > > marco > > > > > > Good, I see the points. > > > > Thanks and regards, > > Xiangsong > > > > > >> Thanks and best regards, > >> marco > >> > >> > >> > >>> Regards, > >>> Xiangsong > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > >>>> > > Behalf > > > >>> Of > >>> > >>> > >>>> Basavaraj.Patil@nokia.com > >>>> Sent: Wednesday, January 05, 2011 2:07 AM > >>>> To: netext@ietf.org > >>>> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > >>>> > >>>> > >>>> At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem > >>>> Statement" I-D following a WG last call. > >>>> The I-D has gone through a WG last call previously. Please consider > >>>> > > this > > > >>>> as the WG last call for the following I-D: > >>>> draft-ietf-netext-pmip6-lr-ps-03.txt > >>>> > >>>> > >>>> Reviews and feedback are appreciated. The WG last call will expire on > >>>> > > Jan > > > >>>> 20th. > >>>> > >>>> Please note that progress of documents is only possible when we have > >>>> enough people reviewing the WG documents. > >>>> > >>>> -Chairs > >>>> > >>>> _______________________________________________ > >>>> 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 Marco.Liebsch@neclab.eu Thu Jan 13 01:34:34 2011 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 38A6428C0E3 for ; Thu, 13 Jan 2011 01:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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 5E7xhEk6ZSAN for ; Thu, 13 Jan 2011 01:34:28 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id DF3DB28C0D9 for ; Thu, 13 Jan 2011 01:34:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 974FB2C0003D1 for ; Thu, 13 Jan 2011 10:36:47 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSLm6aDvz4gE for ; Thu, 13 Jan 2011 10:36:47 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 74E512C0003CC for ; Thu, 13 Jan 2011 10:36:42 +0100 (CET) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Jan 2011 10:36:39 +0100 Message-ID: <4D2EC7A7.1060905@neclab.eu> Date: Thu, 13 Jan 2011 10:36:39 +0100 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Content-Type: multipart/mixed; boundary="------------090805000103020604070105" X-Originating-IP: [10.1.6.32] Subject: [netext] Fwd: I-D Action:draft-ietf-netext-pmip6-lr-ps-04.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 09:34:34 -0000 --------------090805000103020604070105 Content-Type: multipart/alternative; boundary="------------030904020804070002070901" --------------030904020804070002070901 Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit Folks, we published an update of the Localized Routing PS, which considers editorial comments as far as we discussed and agreed, since version 03 was about to expire. A further update will follow, taking the remaining comments into account. marco -------- Original-Nachricht -------- Betreff: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-04.txt Datum: Wed, 12 Jan 2011 09:45:01 -0800 Von: An: CC: 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-04.txt Pages : 18 Date : 2011-01-12 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 setup 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-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------030904020804070002070901 Content-Type: text/html; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Folks,

we published an update of the Localized Routing PS, which considers
editorial comments as far as we discussed and agreed, since version 03
was about to expire. A further update will follow, taking the remaining
comments into account.

marco


-------- Original-Nachricht --------
Betreff: [netext] I-D Action:draft-ietf-netext-pmip6-lr-ps-04.txt
Datum: Wed, 12 Jan 2011 09:45:01 -0800
Von: <Internet-Drafts@ietf.org>
An: <i-d-announce@ietf.org>
CC: <netext@ietf.org> 


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-04.txt
	Pages           : 18
	Date            : 2011-01-12

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 setup 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-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------030904020804070002070901-- --------------090805000103020604070105 Content-Type: message/external-body; name="draft-ietf-netext-pmip6-lr-ps-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-netext-pmip6-lr-ps-04.txt" Content-Type: text/plain Content-ID: <2011-01-12093350.I-D@ietf.org> --------------090805000103020604070105 Content-Type: text/plain; name="Nachrichtenteil als Anhang" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Nachrichtenteil als Anhang" _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --------------090805000103020604070105-- From Marco.Liebsch@neclab.eu Thu Jan 13 05:06:43 2011 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 744C43A6B7A for ; Thu, 13 Jan 2011 05:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 IVAddIZNMffr for ; Thu, 13 Jan 2011 05:06:42 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id 354113A6B79 for ; Thu, 13 Jan 2011 05:06:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 64024280001DA; Thu, 13 Jan 2011 14:10:10 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr1OsT0qvOi8; Thu, 13 Jan 2011 14:10:10 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 41EC028000189; Thu, 13 Jan 2011 14:09:55 +0100 (CET) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Jan 2011 14:08:49 +0100 Message-ID: <4D2EF960.90608@neclab.eu> Date: Thu, 13 Jan 2011 14:08:48 +0100 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Frank Xia References: <005c01cbad31$4b34def0$4f22c10a@china.huawei.com> <4D2C81E2.30909@neclab.eu> <007501cbb29f$bd74e550$6322c10a@china.huawei.com> In-Reply-To: <007501cbb29f$bd74e550$6322c10a@china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Thu, 13 Jan 2011 13:06:43 -0000 Hi Frank, please see inline. Am 12.01.2011 22:29, schrieb Frank Xia: > Hello Marco > > Thank your response. > Please also check my inline comments... > > BR > Frank > > -----Original Message----- > From: Marco Liebsch [mailto:marco.liebsch@neclab.eu] > Sent: Tuesday, January 11, 2011 8:14 AM > To: Frank Xia > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org > Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > > Hi Frank, > > thanks for your feedback. Please see inline. > > Frank Xia wrote: >> Hi guys >> >> I have a quick review of this draft. My main concern is about >> the concept of CN(Correspondent Node). >> >> Firstly, there is another definition in RFC3775 regarding CN. >> What is the relationship between these two definitions? >> > I do not see these two definitions conflicting. RFC3775 says: > "A peer node with which a mobile node is communicating. The > correspondent node > may be either mobile or stationary." > For the LR discussion, NetExt considers a specific setup, which has the > MN's communication peer attached at a MAG as well. Only such use case > is relevant for NetExt. The additional definition for the CN in the PS draft > is to clarify where the CN is assumed for the use cases discussed in the PS. > > We had a discussion long time ago about using MN1-MN2 or MN-CN. We > sticked to MN-CN to indicate also the direction of the communication setup. > Hence, MN sends first data packets to CN, which can trigger the setup of a > localized routing path. I also feel more comfortable in writing and reading > such notation rather than always using MN1, MN2. > If the WG finds this important to change, I can revise it. > >> Secondly, My impression is that the draft mostly assumes >> CNs are always attached to MAGs. The draft should make >> it clear that CNs could be mobile or stationary. It would >> be better to state why stationary CNs are not taken into account. >> > Well, the CN can be stationary as long as it is attached to a MAG and > managed by PMIPv6. I agree that managing such node with PMIP may not > make too much sense. When it's stationary and *not* managed by PMIP, > we enter the discussion again to consider regular IPv6 nodes on an > access router. That has been addressed by Carlos long time ago. > We mention this in section 3.1, 2nd paragraph, but chairs ruled it out > from the solution. > Frank=>Stationary CN means here regular IPv6 nodes attaching an access > router. > This is a ps document even though only some of the problems could be dealt > with. > Whole picture of the problems is important to understand. If I understand correctly, you propose having a section in the PS that analyzes the use case of setting up a localized route between an MN's MAG and a regular IPv6 node being attached to an access router, even though such scenario is out of scope of NetExt. Correct? > I agree that the definition of CN in the PS repeats some parts of RFC3775. > We could revise text to say something like 'Take the definition according to > RFC3775 and assume further characteristics for the CN, such as MAG-attached, > PMIP managed.' Do you think this makes it clearer? > Frank=>I don't think so. Anyway, you figure it out, and this is not > very important issue. ok Marco >> Lastly, this draft uses "set up" as a noun, e.g "The set up >> and maintenance of localized routing". I am not sure if its >> appropriate. >> > Ok, I'll check. > > Thanks, > marco > >> BR >> Frank >> >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of >> Basavaraj.Patil@nokia.com >> Sent: Tuesday, January 04, 2011 10:07 AM >> To: netext@ietf.org >> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 >> >> >> At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem >> Statement" I-D following a WG last call. >> The I-D has gone through a WG last call previously. Please consider this >> as the WG last call for the following I-D: >> draft-ietf-netext-pmip6-lr-ps-03.txt >> >> >> Reviews and feedback are appreciated. The WG last call will expire on Jan >> 20th. >> >> Please note that progress of documents is only possible when we have >> enough people reviewing the WG documents. >> >> -Chairs >> >> _______________________________________________ >> 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@neclab.eu Thu Jan 13 05:39:22 2011 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 27E9F28C0D0 for ; Thu, 13 Jan 2011 05:39:22 -0800 (PST) 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 wh55ygRudi2X for ; Thu, 13 Jan 2011 05:39:21 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B5DE83A6AAB for ; Thu, 13 Jan 2011 05:39:20 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EEA452C000403; Thu, 13 Jan 2011 14:41:45 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4bn83eeVFO5; Thu, 13 Jan 2011 14:41:45 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id BF93D2C0003D1; Thu, 13 Jan 2011 14:41:35 +0100 (CET) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Jan 2011 14:41:32 +0100 Message-ID: <4D2F010C.5050707@neclab.eu> Date: Thu, 13 Jan 2011 14:41:32 +0100 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Xiangsong Cui References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <4D2C8A2E.8060204@neclab.eu> <00ba01cbb1f9$e4f29fb0$aed7df10$%cui@huawei.com> <4D2DBC7C.2030009@neclab.eu> <005101cbb2d3$be6dc6a0$3b4953e0$%cui@huawei.com> In-Reply-To: <005101cbb2d3$be6dc6a0$3b4953e0$%cui@huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Thu, 13 Jan 2011 13:39:22 -0000 Hi Xiangsong, please see inline. Am 13.01.2011 04:41, schrieb Xiangsong Cui: >> The paragraphs talk about different domains. The first one refers to the >> provider >> domain, whereas Section 5 refers to the PMIPv6 domain. I still think >> that the >> proposed revision to the Terms section helps to understand the > requirement, >> that both MAGs must share the provider domain. For Section 5, I think we >> should stick to the original text, as it talks about PMIP domains, which > are >> defined by the relation between an MN's MAG-LMA association. Ok with you? > I think I understand your point, but I still think the words is not clear > enough. > > Firstly, I would like to see the terminology of "provider domain" and "PMIP > domain". In addition, "home domain" is mentioned in section 5. PMIPv6 domain is defined in RFC5213. Nodes in a 'provider domain' are administered by one authority, the mobile network provider. For details of the discussion in this context, please refer to the eMail conversation from Sept 2009. Do you propose to define the term of a 'provider domain' in the PS? > In Section 2, localized routing is defined as (I refer to PS-draft-04), > > o Localized Routing: Result of signaling to set up routing states on > relevant network entities to allow forwarding of data packets > between an MN and a CN, which are attached to MAGs sharing the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > same provider domain, without intervention of the MN's LMA and the > CN's LMA in data forwarding. > > My questions to this definition are, > If MN is attached to MAG1 while CN is attached to MAG2, however, MAG1 and > MAG2 are from different carriers (the hint here is that the corresponding > LMAs are also from different carriers), I don't think you can map the MAG association to the LMAs. In case of roaming, both, MN and CN can be anchored at two LMAs of the same provider, their home provider A. The case you refer to assumes that MAG1 is with provider B and MAG2 is with provider C, hence, MAGs do not share the same provider. Such case is possible, but not considered for localized routing in NetExt. > is this scenario falls in the scope > of localized routing? technically: yes, but the other question is if there is benefit in setting up a route between these two MAGs. Depends on how the two domains are connected. When inter-domain traffic traverses LMAs anyway, there is no benefit. > MN and CN are NOT attached to MAGs in the same > carrier network, is it true that the MAGs are NOT sharing the same "provider > domain" in this case? yes. > In section 5, also saying about "provider domain", > Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., > LMAs, MAGs) tied by MN and CN may be distributed between different > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > provider domains (i.e., domain A, B, C) and MN and/or CN moves from > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > one provider domain to another one. In order to support localized > routing when roaming occurs, it is required that MAGs to which MN and > ^^^^^^^^^^^^^^^^^^^ > CN connect are within the same provider domain and each MAG has a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > security relationship with the corresponding LMA which maintains the > registration of the MN or the CN, respectively. > > The front says, in Figure 2, MAGs may be in different provider domains, where? Please point ot the text. > and > section 5 mainly refers to figure 2 (where MAGs are actually distributed in > different provider domains), taking this as a basis, right? Do not confuse the components which are shared or located in different provider domains. This is about MAGs only. When its says 'MAG1 and MAG2 are in the same provider domain', this is independent of whether LMA1/2 is also in the same provider domain or not. The discussion about the MN's LMA location relative to the associated MN's MAG location is different from the location of two MAGs. > The end of this paragraph says it is required that MAGs are within the same > provider domain, so should a "sharing-domain-figure" be provided as > reference? it does. Fig 2 and associated text consider only MAGs in the same provider domain, MAG1-MAG2, and MAG1'-MAG2', respectively. marco > Xiangsong > >> marco >> >> >> >> >>> Good, I see the points. >>> >>> Thanks and regards, >>> Xiangsong >>> >>> >>>> Thanks and best regards, >>>> marco >>>> >>>> >>>> >>>>> Regards, >>>>> Xiangsong >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On >>>>>> >>> Behalf >>> >>>>> Of >>>>> >>>>> >>>>>> Basavaraj.Patil@nokia.com >>>>>> Sent: Wednesday, January 05, 2011 2:07 AM >>>>>> To: netext@ietf.org >>>>>> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 >>>>>> >>>>>> >>>>>> At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem >>>>>> Statement" I-D following a WG last call. >>>>>> The I-D has gone through a WG last call previously. Please consider >>>>>> >>> this >>> >>>>>> as the WG last call for the following I-D: >>>>>> draft-ietf-netext-pmip6-lr-ps-03.txt >>>>>> >>>>>> >>>>>> Reviews and feedback are appreciated. The WG last call will expire on >>>>>> >>> Jan >>> >>>>>> 20th. >>>>>> >>>>>> Please note that progress of documents is only possible when we have >>>>>> enough people reviewing the WG documents. >>>>>> >>>>>> -Chairs >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Thu Jan 13 05:55:50 2011 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 D1EDD3A6B8B for ; Thu, 13 Jan 2011 05:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 FNyqUFlmKNL3 for ; Thu, 13 Jan 2011 05:55:49 -0800 (PST) Received: from vs12.mail.saunalahti.fi (vs12.mail.saunalahti.fi [195.197.172.107]) by core3.amsl.com (Postfix) with ESMTP id 81D073A6B8A for ; Thu, 13 Jan 2011 05:55:49 -0800 (PST) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs12.mail.saunalahti.fi (Postfix) with SMTP id F35701A9061 for ; Thu, 13 Jan 2011 15:58:09 +0200 (EET) Received: from vs12.mail.saunalahti.fi ([127.0.0.1]) by vs12.mail.saunalahti.fi ([195.197.172.107]) with SMTP (gateway) id A01D23F11C0; Thu, 13 Jan 2011 15:58:09 +0200 Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs12.mail.saunalahti.fi (Postfix) with ESMTP id E5FFB1A9061 for ; Thu, 13 Jan 2011 15:58:09 +0200 (EET) Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id CFEC113994B for ; Thu, 13 Jan 2011 15:58:08 +0200 (EET) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jan 2011 15:58:08 +0200 Message-Id: To: netext@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Subject: [netext] review of draft-ietf-netext-pmip6-lr-ps-04 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, 13 Jan 2011 13:55:50 -0000 Hi, Here's my initial quick review of the "PMIPv6 Localized Routing Problem = Statement" based on the recent -04 version. - Jouni -------------------------------- Nits: o The document seems to lack the IANA considerations section. Even if it is not needed, having a dummy section stating "This document has no IANA considerations" would be good. o Shouldn't the I-D reference to RFC3775bis instead of RFC3775? The bis is already in IESG. Semi-substantial: Section 1: o Propose rephrasing ".. maintenance of a forwarding tunnel between an MN's Mobile = Access.." as ".. maintenance of a tunnel between an MN's Mobile Access.." Section 3.1: o It is stated "Localized routing is understood in [RFC5213] as optimization of traffic between an MN and a CN under the same access router, whereas the MN connects to the MAG function of this access router and is registered with an LMA, but the CN is a regular IPv6 node without getting PMIPv6 service. In such case, the MAG forwards traffic.." I do not agree with the above conclusion of CN's role. In RFC5213 Section 6.10.3 says "..correspondent node that is locally attached to an access link connected to the mobile access gateway, .." To me this does not imply CN is not getting PMIPv6 service. I would propose rephrasing the text as: "Localized routing is understood in [RFC5213] as optimization of traffic between an MN and a CN that are attached to an access link connected to a same MAG. In such case, the MAG forwards traffic.." o The third paragraph listing localized routing benefits I think one additional benefit should be listed. Localized routing allows bypassing the LMA, which may help scaling of the LMA. The LMA is anyway aggregating traffic from a number of MAGs thus becoming a bottleneck more easily than a MAG. Section 3.2: o What actually is a "provider domain"? A composition of PMIPv6 domains? This should be clarified. Maybe even in the terminology section. Section 3.3.1: o This section should at least mention that MN and CN should have IPv4 home addresses of the same scope. I know e.g. NAT is scoped away (which is good) but having more explicit statement here would add clarity imho. o In case of RFC1918 IPv4 home addresses CN's and MN's addresses must not overlap. Section 3.3.2: o I would also add here that addressing used across all MAGs=20 should be of the same scope (for both IPv4 and IPv6). That would make life a bit easier. Section 5: o The last paragraph and the last sentence says "CN should stay with MN within the same domain." I did not get where this requirement is coming from. From Marco.Liebsch@neclab.eu Thu Jan 13 07:41:38 2011 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 267B63A6BA7 for ; Thu, 13 Jan 2011 07:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 e3+oWOVMht2U for ; Thu, 13 Jan 2011 07:41:37 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D5F723A6B60 for ; Thu, 13 Jan 2011 07:41:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A19D72C0003F6; Thu, 13 Jan 2011 16:44:01 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5pcRJ3CgjZo; Thu, 13 Jan 2011 16:44:01 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 767012C0003CC; Thu, 13 Jan 2011 16:43:51 +0100 (CET) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Jan 2011 16:43:48 +0100 Message-ID: <4D2F1DB3.7050006@neclab.eu> Date: Thu, 13 Jan 2011 16:43:47 +0100 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jouni References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: netext@ietf.org Subject: Re: [netext] review of draft-ietf-netext-pmip6-lr-ps-04 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, 13 Jan 2011 15:41:38 -0000 Hi Jouni, thanks for your comments. Please see inline. Am 13.01.2011 14:58, schrieb Jouni: > Hi, > > Here's my initial quick review of the "PMIPv6 Localized Routing Problem Statement" based on the recent -04 version. > > - Jouni > > > -------------------------------- > > Nits: > > o The document seems to lack the IANA considerations section. > Even if it is not needed, having a dummy section stating > "This document has no IANA considerations" would be good. very good point. I'll add it. > o Shouldn't the I-D reference to RFC3775bis instead of RFC3775? > The bis is already in IESG. Hmm, as long as it's not approved and published? I think in case we get the PS to the RFC Editor state, by that time RFC3775bis may be public and will be updated in the PS anyhow before publication. I'll check if it's appropriate to refer to the bis now. Thanks for the hint. > > Semi-substantial: > > Section 1: > > o Propose rephrasing > ".. maintenance of a forwarding tunnel between an MN's Mobile Access.." > as > ".. maintenance of a tunnel between an MN's Mobile Access.." ok > Section 3.1: > > o It is stated > "Localized routing is understood in [RFC5213] as optimization of > traffic between an MN and a CN under the same access router, whereas > the MN connects to the MAG function of this access router and is > registered with an LMA, but the CN is a regular IPv6 node without > getting PMIPv6 service. In such case, the MAG forwards traffic.." > > I do not agree with the above conclusion of CN's role. In RFC5213 > Section 6.10.3 says "..correspondent node that is locally attached > to an access link connected to the mobile access gateway, .." > To me this does not imply CN is not getting PMIPv6 service. I would > propose rephrasing the text as: > > "Localized routing is understood in [RFC5213] as optimization of > traffic between an MN and a CN that are attached to an access > link connected to a same MAG. In such case, the MAG forwards > traffic.." Reading RFC5213, both can be understood. Carlos mentioned the interpretation of having regular IPv6 nodes below a MAG in Feb 2009. But this shows that RFC5213 is really not clear about which use cases are addressed and in particular how to achieve and signal localized routing. At that time we agreed to refer to regular IPv6 nodes. I don't think it's too relevant for the PS if it's a regular IPv6 node or a mobile node, as mechanisms are obviously not completely covered in RFC5213. That means there is still a problem and that's what the PS is about. So, if Carlos and others are fine, I am also ok with taking over your shortened text. > o The third paragraph listing localized routing benefits I think one > additional benefit should be listed. Localized routing allows > bypassing the LMA, which may help scaling of the LMA. The LMA is > anyway aggregating traffic from a number of MAGs thus becoming a > bottleneck more easily than a MAG. Ok, I'll add an item about LMA scalability. thanks. > Section 3.2: > > o What actually is a "provider domain"? A composition of PMIPv6 > domains? This should be clarified. Maybe even in the terminology > section. Let's add some description to the Terms section. 'Provider domain: A network domain in which network components are administered by a single authority, e.g. the mobile operator.' Does this sound ok? Btw, we tried to propose text for such definition some time ago, folks complained if we want to re-invent the wheel and re-define well known terms ;-) > Section 3.3.1: > > o This section should at least mention that MN and CN should have > IPv4 home addresses of the same scope. I know e.g. NAT is scoped > away (which is good) but having more explicit statement here > would add clarity imho. > o In case of RFC1918 IPv4 home addresses CN's and MN's addresses > must not overlap. Do you propose to write this as a requirement? We cannot assume this, as we identify problems in this document. Conflicts when using private address spaces can still happen. We covered this in early versions of the PS, but had to take it out. Please clarify the last two bullets. Thanks. > Section 3.3.2: > > o I would also add here that addressing used across all MAGs > should be of the same scope (for both IPv4 and IPv6). That > would make life a bit easier. as requirement or as problem? > Section 5: > > o The last paragraph and the last sentence says "CN should stay > with MN within the same domain." I did not get where this > requirement is coming from. Good point. This is really not clear. I guess it should be said that in both cases, roaming or non-roaming, MN and CN must attached to MAGs of the same provider domain to receive localized routing service (meeting the NetExt scope). What about the following revision: 'During mobility, CN and MN should remain attached to MAGs of the same provider domain to ensure efficient routing of traffic between their MAGs.' Is this clear enough? Thanks, marco > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Thu Jan 13 14:00:37 2011 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 2466E3A6BE7 for ; Thu, 13 Jan 2011 14:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 q91ZJEVLxVrX for ; Thu, 13 Jan 2011 14:00:36 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 4C9A63A6BE2 for ; Thu, 13 Jan 2011 14:00:36 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0DM2r2B015200; Fri, 14 Jan 2011 00:02:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Jan 2011 00:02:47 +0200 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 13 Jan 2011 23:02:45 +0100 Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.209]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi; Thu, 13 Jan 2011 23:02:45 +0100 From: To: , Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 Thread-Index: AQHLrTFZmVjgdNpVCUWoL+i5eCmGrJPL6hUAgAHqOwCAAQaRAIAAMJeA Date: Thu, 13 Jan 2011 22:02:43 +0000 Message-ID: In-Reply-To: <4D2EF960.90608@neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: <103b6abf-51ae-4b8b-8def-c82593d8effa> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jan 2011 22:02:47.0001 (UTC) FILETIME=[9C950490:01CBB36D] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Thu, 13 Jan 2011 22:00:37 -0000 Marco, On 1/13/11 7:08 AM, "ext Marco Liebsch" wrote: > >> Frank=3D>Stationary CN means here regular IPv6 nodes attaching an access >> router. >> This is a ps document even though only some of the problems could be >>dealt >> with. >> Whole picture of the problems is important to understand. > >If I understand correctly, you propose having a section in the PS that >analyzes >the use case of setting up a localized route between an MN's MAG and a >regular IPv6 node being attached to an access router, even though such >scenario is out of scope of NetExt. Correct? > RFC5213 covers the case where the CN (non-PMIP6 attached host) and the MN (PMIP6 attached host) are associated with the same access router (MAG from MNs perspective). So no reason to mention this. But the case where the MN is attached to a MAG and the CN (non PMIP6 host) is attached to another AR (which is a MAG in the scope of the PMIP6 domain) is best left out of scope. -Raj From xiayangsong@huawei.com Thu Jan 13 14:27:24 2011 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 BAC313A6BFE for ; Thu, 13 Jan 2011 14:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 IB+wSqQLUmj8 for ; Thu, 13 Jan 2011 14:27:21 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CD1E728B56A for ; Thu, 13 Jan 2011 14:27:20 -0800 (PST) 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 <0LEZ00H5TFT94P@szxga03-in.huawei.com> for netext@ietf.org; Fri, 14 Jan 2011 06:29:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEZ0074EFT9U6@szxga03-in.huawei.com> for netext@ietf.org; Fri, 14 Jan 2011 06:29:33 +0800 (CST) Received: from X24512z ([10.193.34.99]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEZ00CBIFT21N@szxml04-in.huawei.com> for netext@ietf.org; Fri, 14 Jan 2011 06:29:33 +0800 (CST) Date: Thu, 13 Jan 2011 14:29:25 -0800 From: Frank Xia In-reply-to: <4D2EF960.90608@neclab.eu> To: 'Marco Liebsch' Message-id: <006301cbb371$56fa4630$6322c10a@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: AcuzIxInCpAda1y+QHa/j2ZEDySqsgALVUsg References: <005c01cbad31$4b34def0$4f22c10a@china.huawei.com> <4D2C81E2.30909@neclab.eu> <007501cbb29f$bd74e550$6322c10a@china.huawei.com> <4D2EF960.90608@neclab.eu> Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Thu, 13 Jan 2011 22:27:24 -0000 Hi Marco Please check again. BR Frank -----Original Message----- From: Marco Liebsch [mailto:marco.liebsch@neclab.eu] Sent: Thursday, January 13, 2011 5:09 AM To: Frank Xia Cc: Basavaraj.Patil@nokia.com; netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 Hi Frank, please see inline. Am 12.01.2011 22:29, schrieb Frank Xia: > Hello Marco > > Thank your response. > Please also check my inline comments... > > BR > Frank > > -----Original Message----- > From: Marco Liebsch [mailto:marco.liebsch@neclab.eu] > Sent: Tuesday, January 11, 2011 8:14 AM > To: Frank Xia > Cc: Basavaraj.Patil@nokia.com; netext@ietf.org > Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > > Hi Frank, > > thanks for your feedback. Please see inline. > > Frank Xia wrote: >> Hi guys >> >> I have a quick review of this draft. My main concern is about >> the concept of CN(Correspondent Node). >> >> Firstly, there is another definition in RFC3775 regarding CN. >> What is the relationship between these two definitions? >> > I do not see these two definitions conflicting. RFC3775 says: > "A peer node with which a mobile node is communicating. The > correspondent node > may be either mobile or stationary." > For the LR discussion, NetExt considers a specific setup, which has the > MN's communication peer attached at a MAG as well. Only such use case > is relevant for NetExt. The additional definition for the CN in the PS draft > is to clarify where the CN is assumed for the use cases discussed in the PS. > > We had a discussion long time ago about using MN1-MN2 or MN-CN. We > sticked to MN-CN to indicate also the direction of the communication setup. > Hence, MN sends first data packets to CN, which can trigger the setup of a > localized routing path. I also feel more comfortable in writing and reading > such notation rather than always using MN1, MN2. > If the WG finds this important to change, I can revise it. > >> Secondly, My impression is that the draft mostly assumes >> CNs are always attached to MAGs. The draft should make >> it clear that CNs could be mobile or stationary. It would >> be better to state why stationary CNs are not taken into account. >> > Well, the CN can be stationary as long as it is attached to a MAG and > managed by PMIPv6. I agree that managing such node with PMIP may not > make too much sense. When it's stationary and *not* managed by PMIP, > we enter the discussion again to consider regular IPv6 nodes on an > access router. That has been addressed by Carlos long time ago. > We mention this in section 3.1, 2nd paragraph, but chairs ruled it out > from the solution. > Frank=>Stationary CN means here regular IPv6 nodes attaching an access > router. > This is a ps document even though only some of the problems could be dealt > with. > Whole picture of the problems is important to understand. If I understand correctly, you propose having a section in the PS that analyzes the use case of setting up a localized route between an MN's MAG and a regular IPv6 node being attached to an access router, even though such scenario is out of scope of NetExt. Correct? Frank=>I don't see any text saying such scenario is out of scope of Netext. I encourage you to describe this use case. This is not a solution document. > I agree that the definition of CN in the PS repeats some parts of RFC3775. > We could revise text to say something like 'Take the definition according to > RFC3775 and assume further characteristics for the CN, such as MAG-attached, > PMIP managed.' Do you think this makes it clearer? > Frank=>I don't think so. Anyway, you figure it out, and this is not > very important issue. ok Marco >> Lastly, this draft uses "set up" as a noun, e.g "The set up >> and maintenance of localized routing". I am not sure if its >> appropriate. >> > Ok, I'll check. > > Thanks, > marco > >> BR >> Frank >> >> -----Original Message----- >> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On Behalf > Of >> Basavaraj.Patil@nokia.com >> Sent: Tuesday, January 04, 2011 10:07 AM >> To: netext@ietf.org >> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 >> >> >> At IETF79 we agreed to progress the "PMIPv6 Localized Routing Problem >> Statement" I-D following a WG last call. >> The I-D has gone through a WG last call previously. Please consider this >> as the WG last call for the following I-D: >> draft-ietf-netext-pmip6-lr-ps-03.txt >> >> >> Reviews and feedback are appreciated. The WG last call will expire on Jan >> 20th. >> >> Please note that progress of documents is only possible when we have >> enough people reviewing the WG documents. >> >> -Chairs >> >> _______________________________________________ >> 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 Xiangsong.Cui@huawei.com Thu Jan 13 17:08:54 2011 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 852AF3A687A for ; Thu, 13 Jan 2011 17:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 R04MkaHoBclM for ; Thu, 13 Jan 2011 17:08:53 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 001443A683B for ; Thu, 13 Jan 2011 17:08:52 -0800 (PST) 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 <0LEZ007BTNADFE@szxga04-in.huawei.com> for netext@ietf.org; Fri, 14 Jan 2011 09:11:01 +0800 (CST) Received: from c00111037 ([10.111.16.128]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEZ00G5GNACSN@szxga04-in.huawei.com> for netext@ietf.org; Fri, 14 Jan 2011 09:11:01 +0800 (CST) Date: Fri, 14 Jan 2011 09:11:00 +0800 From: Xiangsong Cui In-reply-to: <4D2F010C.5050707@neclab.eu> To: 'Marco Liebsch' Message-id: <004201cbb387$e86a0450$b93e0cf0$%cui@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcuzJ6JntKrgDHQtR/ikZ1KOTEKZZQAXCktw References: <00ae01cbae3d$8fe21e70$afa65b50$%cui@huawei.com> <4D2C8A2E.8060204@neclab.eu> <00ba01cbb1f9$e4f29fb0$aed7df10$%cui@huawei.com> <4D2DBC7C.2030009@neclab.eu> <005101cbb2d3$be6dc6a0$3b4953e0$%cui@huawei.com> <4D2F010C.5050707@neclab.eu> Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 14 Jan 2011 01:08:54 -0000 > -----Original Message----- > From: Marco Liebsch [mailto:marco.liebsch@neclab.eu] > Sent: Thursday, January 13, 2011 9:42 PM > To: Xiangsong Cui > Cc: netext@ietf.org > Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > > Hi Xiangsong, > please see inline. > > Am 13.01.2011 04:41, schrieb Xiangsong Cui: > >> The paragraphs talk about different domains. The first one refers to the > >> provider > >> domain, whereas Section 5 refers to the PMIPv6 domain. I still think > >> that the > >> proposed revision to the Terms section helps to understand the > > requirement, > >> that both MAGs must share the provider domain. For Section 5, I think we > >> should stick to the original text, as it talks about PMIP domains, which > > are > >> defined by the relation between an MN's MAG-LMA association. Ok with > you? > > I think I understand your point, but I still think the words is not clear > > enough. > > > > Firstly, I would like to see the terminology of "provider domain" and "PMIP > > domain". In addition, "home domain" is mentioned in section 5. > > PMIPv6 domain is defined in RFC5213. > > Nodes in a 'provider domain' are administered by one authority, the > mobile network provider. > For details of the discussion in this context, please refer to the eMail > conversation from > Sept 2009. Do you propose to define the term of a 'provider domain' in > the PS? Sorry I didn't follow the thread closely, but I think it would be better if there was a definition. > > > In Section 2, localized routing is defined as (I refer to PS-draft-04), > > > > o Localized Routing: Result of signaling to set up routing states on > > relevant network entities to allow forwarding of data packets > > between an MN and a CN, which are attached to MAGs sharing the > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > same provider domain, without intervention of the MN's LMA and > the > > CN's LMA in data forwarding. > > > > My questions to this definition are, > > If MN is attached to MAG1 while CN is attached to MAG2, however, MAG1 > and > > MAG2 are from different carriers (the hint here is that the corresponding > > LMAs are also from different carriers), > I don't think you can map the MAG association to the LMAs. In case of > roaming, both, > MN and CN can be anchored at two LMAs of the same provider, their home > provider A. > The case you refer to assumes that MAG1 is with provider B and MAG2 is with > provider C, hence, MAGs do not share the same provider. Such case is > possible, > but not considered for localized routing in NetExt. > > > is this scenario falls in the scope > > of localized routing? > technically: yes, but the other question is if there is benefit in > setting up > a route between these two MAGs. Depends on how the two domains are > connected. > When inter-domain traffic traverses LMAs anyway, there is no benefit. > Thanks for the clarification. > > > MN and CN are NOT attached to MAGs in the same > > carrier network, is it true that the MAGs are NOT sharing the same "provider > > domain" in this case? > yes. > > > In section 5, also saying about "provider domain", > > Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., > > LMAs, MAGs) tied by MN and CN may be distributed between different > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > provider domains (i.e., domain A, B, C) and MN and/or CN moves from > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > one provider domain to another one. In order to support localized > > routing when roaming occurs, it is required that MAGs to which MN and > > ^^^^^^^^^^^^^^^^^^^ > > CN connect are within the same provider domain and each MAG has a > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > security relationship with the corresponding LMA which maintains the > > registration of the MN or the CN, respectively. > > > > The front says, in Figure 2, MAGs may be in different provider domains, > where? Please point ot the text. The first sentence of section 5, Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs, MAGs) tied by MN and CN may be distributed between different provider domains (i.e., domain A, B, C) and MN and/or CN moves from one provider domain to another one. Let me try to simplify this sentence, it is describing the roaming case which is showed in Figure 2, The front half of the subordinate clause says, "PMIPv6 components (e.g., LMAs, MAGs) tied by MN and CN may be distributed between different provider domains" does this mean MAGs may be in different provider domain? The end half of the subordinate clause says, "MN and/or CN moves from one provider domain to another one". Does the *or* means that the nodes may roam one by one? So even MAGs are in same provider domain, it would be changed when one node is roaming (to a new MAG in another provider domain). > > > and > > section 5 mainly refers to figure 2 (where MAGs are actually distributed in > > different provider domains), taking this as a basis, right? > Do not confuse the components which are shared or located in different > provider domains. > This is about MAGs only. When its says 'MAG1 and MAG2 are in the same > provider > domain', this is independent of whether LMA1/2 is also in the same > provider domain or not. > The discussion about the MN's LMA location relative to the associated > MN's MAG location is > different from the location of two MAGs. Yes, I have known the difference on location of LMA and MAG. > > > > The end of this paragraph says it is required that MAGs are within the same > > provider domain, so should a "sharing-domain-figure" be provided as > > reference? > it does. Fig 2 and associated text consider only MAGs in the same > provider domain, > MAG1-MAG2, and MAG1'-MAG2', respectively. Do you mean MN and CN are roaming exactly simultaneously? From MAG1/MAG2 pair to MAG1'/MAG2' pair? In my impression, when MN (or CN) moves to a new provider domain, it would lie in a different provider domain with CN (or MN), so the localized routing should be released, right? If you say they are exactly simultaneously roaming, supposed they are registered in the same LMA, the LMA would receive PBU from MAG1' and MAG2' respectively, I think here should be a single thread program, so it is impossible for the LMA to receive exactly simultaneous message, do you mean the LMA should hold one PBU for some time (not destroy localized routing immediately although "different provider domain") and wait for the other PBU (to continue the localized routing on new MAG pair)? This is of course purely implementation issue, here my point is just to check the case. Xiangsong > > marco > > > Xiangsong > > > >> marco > >> > >> > >> > >> > >>> Good, I see the points. > >>> > >>> Thanks and regards, > >>> Xiangsong > >>> > >>> > >>>> Thanks and best regards, > >>>> marco > >>>> > >>>> > >>>> > >>>>> Regards, > >>>>> Xiangsong > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > >>>>>> > >>> Behalf > >>> > >>>>> Of > >>>>> > >>>>> > >>>>>> Basavaraj.Patil@nokia.com > >>>>>> Sent: Wednesday, January 05, 2011 2:07 AM > >>>>>> To: netext@ietf.org > >>>>>> Subject: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 > >>>>>> > >>>>>> > >>>>>> At IETF79 we agreed to progress the "PMIPv6 Localized Routing > Problem > >>>>>> Statement" I-D following a WG last call. > >>>>>> The I-D has gone through a WG last call previously. Please consider > >>>>>> > >>> this > >>> > >>>>>> as the WG last call for the following I-D: > >>>>>> draft-ietf-netext-pmip6-lr-ps-03.txt > >>>>>> > >>>>>> > >>>>>> Reviews and feedback are appreciated. The WG last call will expire on > >>>>>> > >>> Jan > >>> > >>>>>> 20th. > >>>>>> > >>>>>> Please note that progress of documents is only possible when we have > >>>>>> enough people reviewing the WG documents. > >>>>>> > >>>>>> -Chairs > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 Marco.Liebsch@neclab.eu Fri Jan 14 02:10:37 2011 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 4B5513A6AF0 for ; Fri, 14 Jan 2011 02:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, 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 2Pcf2AauACCm for ; Fri, 14 Jan 2011 02:10:36 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 674753A6ACE for ; Fri, 14 Jan 2011 02:10:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8FBB62C0003CC; Fri, 14 Jan 2011 11:13:05 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-VDkuIsHX23; Fri, 14 Jan 2011 11:13:05 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 72C852C000349; Fri, 14 Jan 2011 11:12:50 +0100 (CET) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Jan 2011 11:12:44 +0100 Message-ID: <4D30219C.7070508@neclab.eu> Date: Fri, 14 Jan 2011 11:12:44 +0100 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Frank Xia References: <005c01cbad31$4b34def0$4f22c10a@china.huawei.com> <4D2C81E2.30909@neclab.eu> <007501cbb29f$bd74e550$6322c10a@china.huawei.com> <4D2EF960.90608@neclab.eu> <006301cbb371$56fa4630$6322c10a@china.huawei.com> In-Reply-To: <006301cbb371$56fa4630$6322c10a@china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: netext@ietf.org, Basavaraj.Patil@nokia.com Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 14 Jan 2011 10:10:38 -0000 Hi Frank, Am 13.01.2011 23:29, schrieb Frank Xia: > H >>> Secondly, My impression is that the draft mostly assumes >>> CNs are always attached to MAGs. The draft should make >>> it clear that CNs could be mobile or stationary. It would >>> be better to state why stationary CNs are not taken into account. >>> >> Well, the CN can be stationary as long as it is attached to a MAG and >> managed by PMIPv6. I agree that managing such node with PMIP may not >> make too much sense. When it's stationary and *not* managed by PMIP, >> we enter the discussion again to consider regular IPv6 nodes on an >> access router. That has been addressed by Carlos long time ago. >> We mention this in section 3.1, 2nd paragraph, but chairs ruled it out >> from the solution. >> Frank=>Stationary CN means here regular IPv6 nodes attaching an access >> router. >> This is a ps document even though only some of the problems could be dealt >> with. >> Whole picture of the problems is important to understand. > If I understand correctly, you propose having a section in the PS that > analyzes > the use case of setting up a localized route between an MN's MAG and a > regular IPv6 node being attached to an access router, even though such > scenario is out of scope of NetExt. Correct? > Frank=>I don't see any text saying such scenario is out of scope of Netext. Technical scope of NetExt LR has been decided throughout the discussion. Authors of the PS have been asked to reflect this in the PS. For the use case to set up a localized route with a regular IPv6 node, the 3.1 has the following text: "Maintaining local forwarding between the MN and the regular IPv6 CN gets more complex in case the MN performs a handover to a different MAG. Such use case is not considered in the specification and out of scope of this problem statement. This document focuses on use cases, where both nodes, the MN and the CN,are each registered with an LMA and both obtain PMIPv6 mobility service." Pleaase propose new or additional text in case you think this in not sufficient. > I encourage you to describe this use case. This is not a solution document. I am ok with having a short section analyzing this case. Would appreciate if you have some input on this. Bullet lists is fine. I can make text out of that. This assumes nobody (incl. chairs) object having such text in the PS. Chairs? marco > >> I agree tha From Marco.Liebsch@neclab.eu Fri Jan 14 02:13:51 2011 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 98DBB3A6AFB for ; Fri, 14 Jan 2011 02:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 tCHQ4DNhvjBD for ; Fri, 14 Jan 2011 02:13:50 -0800 (PST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by core3.amsl.com (Postfix) with ESMTP id C5BE13A6AC9 for ; Fri, 14 Jan 2011 02:13:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id F27F5280001DA; Fri, 14 Jan 2011 11:17:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xuIuONoBCWt; Fri, 14 Jan 2011 11:17:21 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D64F628000189; Fri, 14 Jan 2011 11:17:06 +0100 (CET) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Jan 2011 11:16:00 +0100 Message-ID: <4D30225F.8070003@neclab.eu> Date: Fri, 14 Jan 2011 11:15:59 +0100 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 14 Jan 2011 10:13:51 -0000 Am 13.01.2011 23:02, schrieb Basavaraj.Patil@nokia.com: > Marco, > > On 1/13/11 7:08 AM, "ext Marco Liebsch" wrote: > >>> Frank=>Stationary CN means here regular IPv6 nodes attaching an access >>> router. >>> This is a ps document even though only some of the problems could be >>> dealt >>> with. >>> Whole picture of the problems is important to understand. >> If I understand correctly, you propose having a section in the PS that >> analyzes >> the use case of setting up a localized route between an MN's MAG and a >> regular IPv6 node being attached to an access router, even though such >> scenario is out of scope of NetExt. Correct? >> > RFC5213 covers the case where the CN (non-PMIP6 attached host) and the MN > (PMIP6 attached host) are associated with the same access router (MAG from > MNs perspective). So no reason to mention this. > But the case where the MN is attached to a MAG and the CN (non PMIP6 host) > is attached to another AR (which is a MAG in the scope of the PMIP6 > domain) is best left out of scope. Clear. That's why we added associated text in 3.1 Please check my last reply to Frank in this context and let me know if this is sufficient. marco > -Raj > From jouni.nospam@gmail.com Fri Jan 14 03:13:35 2011 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 C5BC93A6BB5 for ; Fri, 14 Jan 2011 03:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 uL9ZJoFxaUOP for ; Fri, 14 Jan 2011 03:13:33 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7D01D3A6B6A for ; Fri, 14 Jan 2011 03:13:32 -0800 (PST) Received: by bwz12 with SMTP id 12so2590565bwz.31 for ; Fri, 14 Jan 2011 03:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=WrHKcoKOhixrbvS9vq22zoNwxCNTs0ds7c1i3GjKysU=; b=vFHbDGfTtY5lVSq/6wJYqM59X1vBCJpHfPnyr/fRlcWvXuetQknRSuDSrsMKfc/fKE 3Vi9OdEJ+LK6K3cng1STquGf+8d9+e9Lg34Qj3/dThJWZnW4QMDxVo4TKU0g1cFBX97G 9wuSwUN0CahvzDAvWFGBjk4gnKxxyxUWkzS14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=VQ79rZ4J1piVZoK3gPFbW+FMDLO3cOHj+USE0FZ0yOteYD9oQM4RdO6jC7WkqRUEP3 lE7patZGiD/MgS+CwrmTTPLEcetucT3mZ1YCGrLI3IJqkcmR0UgNWIZUcD3ioW7u44Cb f8pThrHNna3ar5IYzoaKDD4gf6f6EqzLPjPGo= Received: by 10.204.138.142 with SMTP id a14mr490938bku.197.1295003756556; Fri, 14 Jan 2011 03:15:56 -0800 (PST) Received: from wd2421.kokousverkko.local (pc161.ficora.fi [87.239.124.37]) by mx.google.com with ESMTPS id b17sm1225770bku.8.2011.01.14.03.15.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Jan 2011 03:15:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4D2F1DB3.7050006@neclab.eu> Date: Fri, 14 Jan 2011 13:15:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D2F1DB3.7050006@neclab.eu> To: Marco Liebsch X-Mailer: Apple Mail (2.1078) Cc: netext@ietf.org Subject: Re: [netext] review of draft-ietf-netext-pmip6-lr-ps-04 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, 14 Jan 2011 11:13:35 -0000 Hi Marco, See inline. On Jan 13, 2011, at 5:43 PM, Marco Liebsch wrote: > Hi Jouni, >=20 > thanks for your comments. Please see inline. >=20 > Am 13.01.2011 14:58, schrieb Jouni: >> Hi, >>=20 >> Here's my initial quick review of the "PMIPv6 Localized Routing = Problem Statement" based on the recent -04 version. >>=20 >> - Jouni >>=20 >>=20 >> -------------------------------- >>=20 >> Nits: >>=20 >> o The document seems to lack the IANA considerations section. >> Even if it is not needed, having a dummy section stating >> "This document has no IANA considerations" would be good. > very good point. I'll add it. >=20 >> o Shouldn't the I-D reference to RFC3775bis instead of RFC3775? >> The bis is already in IESG. > Hmm, as long as it's not approved and published? I think in case we = get the > PS to the RFC Editor state, by that time RFC3775bis may be public and > will be updated in the PS anyhow before publication. I'll check if = it's > appropriate to refer to the bis now. Thanks for the hint. Ok. >=20 >=20 >>=20 >> Semi-substantial: >>=20 >> Section 1: >>=20 >> o Propose rephrasing >> ".. maintenance of a forwarding tunnel between an MN's Mobile = Access.." >> as >> ".. maintenance of a tunnel between an MN's Mobile Access.." > ok >=20 >> Section 3.1: >>=20 >> o It is stated >> "Localized routing is understood in [RFC5213] as optimization of >> traffic between an MN and a CN under the same access router, = whereas >> the MN connects to the MAG function of this access router and is >> registered with an LMA, but the CN is a regular IPv6 node without >> getting PMIPv6 service. In such case, the MAG forwards traffic.." >>=20 >> I do not agree with the above conclusion of CN's role. In RFC5213 >> Section 6.10.3 says "..correspondent node that is locally attached >> to an access link connected to the mobile access gateway, .." >> To me this does not imply CN is not getting PMIPv6 service. I would >> propose rephrasing the text as: >>=20 >> "Localized routing is understood in [RFC5213] as optimization of >> traffic between an MN and a CN that are attached to an access >> link connected to a same MAG. In such case, the MAG forwards >> traffic.." > Reading RFC5213, both can be understood. Carlos mentioned the = interpretation > of having regular IPv6 nodes below a MAG in Feb 2009. But this shows = that RFC5213 > is really not clear about which use cases are addressed and in = particular how to achieve > and signal localized routing. At that time we agreed to refer to = regular IPv6 nodes. > I don't think it's too relevant for the PS if it's a regular IPv6 node = or a mobile node, > as mechanisms are obviously not completely covered in RFC5213. That = means > there is still a problem and that's what the PS is about. So, if = Carlos and others are > fine, I am also ok with taking over your shortened text. >=20 Just to mention that the "shortened" interpretation was used e.g. when = RFC5779 was done. >=20 >> o The third paragraph listing localized routing benefits I think one >> additional benefit should be listed. Localized routing allows >> bypassing the LMA, which may help scaling of the LMA. The LMA is >> anyway aggregating traffic from a number of MAGs thus becoming a >> bottleneck more easily than a MAG. > Ok, I'll add an item about LMA scalability. thanks. >=20 >=20 >> Section 3.2: >>=20 >> o What actually is a "provider domain"? A composition of PMIPv6 >> domains? This should be clarified. Maybe even in the terminology >> section. > Let's add some description to the Terms section. >=20 > 'Provider domain: A network domain in which network components > are administered by a single authority, e.g. the mobile operator.' >=20 > Does this sound ok? Sounds ok. >=20 > Btw, we tried to propose text for such definition some time ago, folks > complained if we want to re-invent the wheel and re-define well > known terms ;-) Wasn't ambiguous to me.. and I even used to work for a provider. >=20 >=20 >> Section 3.3.1: >>=20 >> o This section should at least mention that MN and CN should have >> IPv4 home addresses of the same scope. I know e.g. NAT is scoped >> away (which is good) but having more explicit statement here >> would add clarity imho. >=20 >> o In case of RFC1918 IPv4 home addresses CN's and MN's addresses >> must not overlap. > Do you propose to write this as a requirement? We cannot assume this, = as > we identify problems in this document. You could state that as a problem or a known constraint. > Conflicts when using private address spaces can still happen. We = covered this > in early versions of the PS, but had to take it out. Please clarify = the last two > bullets. Thanks. I find it odd, of someone would even try to directly integrate domains = that are known to have overlapping address issues. That would be plain = dump. >=20 >=20 >> Section 3.3.2: >>=20 >> o I would also add here that addressing used across all MAGs >> should be of the same scope (for both IPv4 and IPv6). That >> would make life a bit easier. > as requirement or as problem? Would state that as a problem/known constraint. >=20 >> Section 5: >>=20 >> o The last paragraph and the last sentence says "CN should stay >> with MN within the same domain." I did not get where this >> requirement is coming from. > Good point. This is really not clear. > I guess it should be said that in both cases, roaming or non-roaming, = MN and CN > must attached to MAGs of the same provider domain to receive localized = routing > service (meeting the NetExt scope). What about the following revision: >=20 > 'During mobility, CN and MN should remain attached to MAGs of the same > provider domain to ensure efficient routing of traffic between their = MAGs.' >=20 > Is this clear enough? Yes. - JOuni >=20 > Thanks, > marco >=20 >=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext >=20 From Basavaraj.Patil@nokia.com Fri Jan 14 09:19:24 2011 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 6CEC13A6BA3 for ; Fri, 14 Jan 2011 09:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.242 X-Spam-Level: X-Spam-Status: No, score=-104.242 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 sRJJCyLvi1Hy for ; Fri, 14 Jan 2011 09:19:23 -0800 (PST) Received: from mgw-da01.nokia.com (mgw-da01.ext.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 74C103A6BBE for ; Fri, 14 Jan 2011 09:19:23 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p0EHLi1Z024951; Fri, 14 Jan 2011 19:21:45 +0200 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.4675); Fri, 14 Jan 2011 19:21:39 +0200 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 14 Jan 2011 18:21:39 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.46]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi; Fri, 14 Jan 2011 18:21:33 +0100 From: To: Thread-Topic: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-03 Thread-Index: AQHLrTFZmVjgdNpVCUWoL+i5eCmGrJPL6hUAgAHqOwCAAQaRAIAAMJeAgAExdYCAABJPgA== Date: Fri, 14 Jan 2011 17:21:31 +0000 Message-ID: In-Reply-To: <4D30225F.8070003@neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jan 2011 17:21:39.0619 (UTC) FILETIME=[81408730:01CBB40F] X-Nokia-AV: Clean Cc: netext@ietf.org Subject: Re: [netext] WG last call: draft-ietf-netext-pmip6-lr-ps-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: Fri, 14 Jan 2011 17:19:24 -0000 Hi Marco, On 1/14/11 4:15 AM, "ext Marco Liebsch" wrote: >Am 13.01.2011 23:02, schrieb Basavaraj.Patil@nokia.com: >> Marco, >> >> On 1/13/11 7:08 AM, "ext Marco Liebsch" wrote: >> >>>> Frank=3D>Stationary CN means here regular IPv6 nodes attaching an acce= ss >>>> router. >>>> This is a ps document even though only some of the problems could be >>>> dealt >>>> with. >>>> Whole picture of the problems is important to understand. >>> If I understand correctly, you propose having a section in the PS that >>> analyzes >>> the use case of setting up a localized route between an MN's MAG and a >>> regular IPv6 node being attached to an access router, even though such >>> scenario is out of scope of NetExt. Correct? >>> >> RFC5213 covers the case where the CN (non-PMIP6 attached host) and the >>MN >> (PMIP6 attached host) are associated with the same access router (MAG >>from >> MNs perspective). So no reason to mention this. >> But the case where the MN is attached to a MAG and the CN (non PMIP6 >>host) >> is attached to another AR (which is a MAG in the scope of the PMIP6 >> domain) is best left out of scope. > >Clear. That's why we added associated text in 3.1 Please check my last >reply to Frank in this context and let me know if this is sufficient. I am okay with what you proposed. Thanks. -Raj > >marco > > >> -Raj >> > > > > >