From Marco.Liebsch@neclab.eu Mon May 2 02:22:52 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA145E071F; Mon, 2 May 2011 02:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYCpwp8ZSwBW; Mon, 2 May 2011 02:22:52 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2C77CE070D; Mon, 2 May 2011 02:22:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 3CE8E2C000089; Mon, 2 May 2011 11:22:10 +0200 (CEST) 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 FfTDjGi5niQI; Mon, 2 May 2011 11:22:10 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 1FAC22C000088; Mon, 2 May 2011 11:21:45 +0200 (CEST) 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; Mon, 2 May 2011 11:21:45 +0200 Message-ID: <4DBE77A4.90507@neclab.eu> Date: Mon, 2 May 2011 11:21:40 +0200 From: Marco Liebsch User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Yoshifumi Nishida References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.62] Cc: netext@ietf.org, ietf@ietf.org, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org, Transport Directorate Subject: Re: [netext] TSVDIR Review for draft-ietf-netext-pmip6-lr-ps X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2011 09:22:52 -0000 Dear Yoshifumi, thanks a lot for your review. Please find 2 comments inline. Yoshifumi Nishida wrote: > Hello, > I've reviewed this document as part of the transport area > directorate's ongoing effort to review key IETF documents. These > comments were written primarily for the transport area directors, but > are copied to the document's authors for their information and to > allow them to address any issues raised. The authors should consider > this review together with any other last-call comments they > receive. Please always CC tsv-dir@ietf.org if you reply to or forward > this review. > > Summary: > > This draft describes the problem space for localized routing in PMIPv6, > which supports direct communication between MAGs for MN and CN. > This draft is basically ready for publication and I couldn't > find any transport related issues in the draft. > > Minor comments: > > Would it be better to mention error detection and fallback function in > Functional Requirements? It would be useful and helpful to fall back > to normal routing when something happens. > I agree that the solution must provide means to handle such error cases and to step back to non-optimized routing in case there is need. I see these as non-functional requirements, whereas section 4 is about functional requirements only. We could add a functional requirement to 'terminate' localized routing. Example for reasons doing this could be the error case you mention. Does this sound ok? > I believe localize routing is very useful in most cases. However, I think > there will be the cases where we had better avoid localized routing, > such as a case where there are some restrictions (policy, network quality > or configuration, etc) in communications between MAGs. > It might be better to address having some kind of control to enable > localized routing in Functional Requirements in addition to checking > source and destination addresses. > Section 4, which covers the functional requirements, has a new item listed about enforcement of operator policies to control localized routing. I think that covers your comment. Thanks and best regards, marco > Thanks, > -- > Yoshifumi Nishida > nishida@sfc.wide.ad.jp > From yoshifumi.nishida@gmail.com Mon May 2 20:12:31 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A61E0727; Mon, 2 May 2011 20:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI3uteRK2dhI; Mon, 2 May 2011 20:12:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4252AE068C; Mon, 2 May 2011 20:12:24 -0700 (PDT) Received: by iwn39 with SMTP id 39so6605415iwn.31 for ; Mon, 02 May 2011 20:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zQzXZa56fZCMjOX8haa5USc39D5KJNWjorzSWUFLCZg=; b=eVCVEjzrKH86ZA79EfROKONsKslZcJJeXwHLCqwxcvGzCaF/Wo329mwhE7ZdHe9Ilh h94L32/+HtEAIoC/I8IHD2PsdIf7ew9eLwNUyHc9yehkrQBdNe07Au+4b9/TkSCgyBlM SwzAv2FSOt/jG2MoCpy8JCcXaJxd0C103UiPk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=VUXRWFl+aLbA2CAIjtaIWIzo+QsscolBR8ItkLq8jxajQ7MMq/TwEDNizRP05aLngb qqzv74IyFIchMCDv1XI5fpdM8PYyRnm2InucC3PqrOqlsWiBphEZDL5BXCzm+WIurRyH OieMDX6JAw2USDibZfhwrMxoPVPI6WK+cQA1c= MIME-Version: 1.0 Received: by 10.231.74.2 with SMTP id s2mr7112838ibj.8.1304392343766; Mon, 02 May 2011 20:12:23 -0700 (PDT) Sender: yoshifumi.nishida@gmail.com Received: by 10.231.207.66 with HTTP; Mon, 2 May 2011 20:12:23 -0700 (PDT) In-Reply-To: <4DBE77A4.90507@neclab.eu> References: <4DBE77A4.90507@neclab.eu> Date: Mon, 2 May 2011 20:12:23 -0700 X-Google-Sender-Auth: wDxDcLBFhy1TmHPUspp24GpQ-bE Message-ID: From: Yoshifumi Nishida To: Marco Liebsch Content-Type: text/plain; charset=ISO-8859-1 Cc: netext@ietf.org, ietf@ietf.org, draft-ietf-netext-pmip6-lr-ps@tools.ietf.org, Transport Directorate Subject: Re: [netext] TSVDIR Review for draft-ietf-netext-pmip6-lr-ps X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2011 03:12:31 -0000 Dear Marco, Thanks for your response. 2011/5/2 Marco Liebsch : > Dear Yoshifumi, > > thanks a lot for your review. Please find 2 comments inline. > > Yoshifumi Nishida wrote: >> >> Hello, >> I've reviewed this document as part of the transport area >> directorate's ongoing effort to review key IETF documents. These >> comments were written primarily for the transport area directors, but >> are copied to the document's authors for their information and to >> allow them to address any issues raised. The authors should consider >> this review together with any other last-call comments they >> receive. Please always CC tsv-dir@ietf.org if you reply to or forward >> this review. >> >> Summary: >> >> This draft describes the problem space for localized routing in PMIPv6, >> which supports direct communication between MAGs for MN and CN. >> This draft is basically ready for publication and I couldn't >> find any transport related issues in the draft. >> >> Minor comments: >> >> Would it be better to mention error detection and fallback function in >> Functional Requirements? It would be useful and helpful to fall back >> to normal routing when something happens. >> > > I agree that the solution must provide means to handle such error cases > and to step back to non-optimized routing in case there is need. > I see these as non-functional requirements, whereas section 4 is about > functional > requirements only. We could add a functional requirement to 'terminate' > localized routing. Example for reasons doing this could be the error > case you mention. Does this sound ok? Yes. That works for me. >> I believe localize routing is very useful in most cases. However, I think >> there will be the cases where we had better avoid localized routing, >> such as a case where there are some restrictions (policy, network quality >> or configuration, etc) in communications between MAGs. >> It might be better to address having some kind of control to enable >> localized routing in Functional Requirements in addition to checking >> source and destination addresses. >> > Section 4, which covers the functional requirements, has a new item listed > about enforcement of operator policies to control localized routing. I think > that covers your comment. I've checked the new item and I think it covers the comments. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From Internet-Drafts@ietf.org Thu May 5 11:15:03 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDCAE079C; Thu, 5 May 2011 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz6bdkVsQ-GT; Thu, 5 May 2011 11:15:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25477E08FE; Thu, 5 May 2011 11:15:02 -0700 (PDT) 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.53 Message-ID: <20110505181502.4115.6048.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 11:15:02 -0700 Cc: netext@ietf.org Subject: [netext] I-D ACTION:draft-ietf-netext-bulk-re-registration-03.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 05 May 2011 18:15:03 -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 : Bulk Re-registration for Proxy Mobile IPv6 Author(s) : F. Abinader, et al Filename : draft-ietf-netext-bulk-re-registration-03.txt Pages : 19 Date : 2011-04-25 Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines an optimization to the re-registration and revocation processes in Proxy Mobile IPv6 in addition to specifying a new Mobility Option for carrying group affiliation of a Mobile Node in the signaling messages between the mobility enabler entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netext-bulk-re-registration-03.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-bulk-re-registration-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05110328.I-D@ietf.org> --NextPart-- From suresh.krishnan@ericsson.com Thu May 12 14:14:24 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F5CE06F7 for ; Thu, 12 May 2011 14:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSFu4iSfHdJc for ; Thu, 12 May 2011 14:14:19 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF46E0694 for ; Thu, 12 May 2011 14:14:19 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4CLEFCb010130; Thu, 12 May 2011 16:14:17 -0500 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0706.eamcs.ericsson.se (147.117.20.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 12 May 2011 17:14:13 -0400 Message-ID: <4DCC4DAE.4050305@ericsson.com> Date: Thu, 12 May 2011 17:14:22 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Xiangsong Cui References: <007901cbf5d4$0d239a20$276ace60$%cui@huawei.com> In-Reply-To: <007901cbf5d4$0d239a20$276ace60$%cui@huawei.com> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] My comments on draft-ietf-netext-pmip-lr-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 21:14:24 -0000 Hi Xiangsong, Thanks for your comments. Please find responses inline. Xiangsong Cui wrote: > Hi, > > I have reviewed this draft, and I have two comments. > > First, in the case of A11 scenario, > > It reads "It is also possible that > one of the mobility entities (LMA or MAG) could decide to initiate > localized routing based on configured policy." > > But based on the statement of section 2, ONLY LMA can initiate the LR > function in this case, Right. But, the base PMIPv6 spec [RFC5213] allows the MAG to be configured to initiate localized routing using the EnableMAGLocalRouting (static) configuration variable. I have added the following text to clarify this "Please note that a MAG implementing the protocol specified in this specification will not dynamically initiate LR in the same LMA case (i.e. by sending an LRI), but can statically initiate LR based on the EnableMAGLocalRouting configuration variable specified in [RFC5213]." Does that work for you? > So I'm not sure, does this mean MAG may transmit a U-LRA to trigger the LMA > to initiate the LR function? > > > > My Second comment is about the statement of section 4, > > "The MAG may refresh the lifetime of an existing local forwarding > service. For this, it sends an unsolicited LRA (U-LRA) message that > contains the new lifetime value. The MAG MUST wait for the following > LRI message from the LMA before it can conclude that the refresh > request is granted." > > I think this is not very clear, what would happen in the LMA if the MAG > doesn't transmit the U-LRA message? > Does this mean the LMA MUST respond a LRI message to the MAG and the MAG > further transmits an acknowledge LRA? > If the MAG doesn't receive the following LRI, what would happen? Is there > any retransmission? > And, does the MAG transmit refreshment PBU to the LMA after it transmits the > U-LRA? I think the U-LRA is causing too much confusion and it not very useful. It probably makes sense to remove this from the spec. Thanks Suresh From suresh.krishnan@ericsson.com Thu May 12 14:15:00 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5234EE067C for ; Thu, 12 May 2011 14:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6xNqt1CzsWV for ; Thu, 12 May 2011 14:14:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id F25CBE066E for ; Thu, 12 May 2011 14:14:53 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4CLEptV010246; Thu, 12 May 2011 16:14:53 -0500 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Thu, 12 May 2011 17:14:49 -0400 Message-ID: <4DCC4DD2.1010206@ericsson.com> Date: Thu, 12 May 2011 17:14:58 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Dirk.von-Hugo@telekom.de" References: <643B0A1D1A13AB498304E0BBC802784803388E9F@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC802784803388E9F@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Cc: "netext@ietf.org" Subject: Re: [netext] WG LC: draft-ietf-netext-pmip-lr X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 12 May 2011 21:15:00 -0000 Hi Dirk, Thanks for your comments. I have addressed all of them in version -03. Thanks Suresh Dirk.von-Hugo@telekom.de wrote: > Dear all, > I think the draft provides a simple but efficient solution to the problem described in "PMIPv6 Localized Routing Problem Statement" and is written concisely. Some comments beyond the nits detected by the tool following (although done on vers. -01, sorry for that!): > > Abstract: > be suboptimal, localized routing(LR) => be suboptimal, localized routing (LR) > > P.3: > according to [RFC5213]. => according to [RFC5213]. The protocol builds on the scenarios defined > in [I-D.ietf-netext-pmip6-lr-ps]. > > P.4: > The MAG MUST Initiate => The MAG MUST initiate > The LMA MUST Initiate => The LMA MUST initiate > > Some more nits e.g. on p.7: > Localized Routing Entries(LREs) => Localized Routing Entries (LREs) > address of the next- hop). => address of the next hop). > > P.8: > a Local Routing Acknowledgment (LRA) => a Localized Routing Acknowledgment (LRA) > another MAG(say nMAG) => another MAG (say nMAG) > > Not sure about LRE or (new?) LFE on P.8/9: > corresponding LFE entries MUST be removed. => corresponding LRE entries MUST be removed. > > MAG IP Address option is present, each MAG MUST create a local forwarding entry => MAG IP Address option is present, each MAG MUST create an LRE _or_ local forwarding entry (LFE) > > P.12: > it. Hence the local routing => it. Hence the localized routing > > p.17: > 'S' flag: When set to 1, indicates a request to stop local => 'S' flag: When set to 1, indicates a request to stop localized > > P.20: > association between the LMA and the MAG to protect the LRI and LRA => association as defined in [RFC5213] for use between the LMA and the MAG to protect the LRI and LRA > > P.21 > Local Routing Acknowledgment, => Localized Routing Acknowledgment, > > So far my minor suggestions. > Thanks! > > Best regards > Dirk > > -----Ursprüngliche Nachricht----- > Von: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] Im Auftrag von Basavaraj.Patil@nokia.com > Gesendet: Dienstag, 19. April 2011 16:25 > An: netext@ietf.org > Betreff: [netext] WG LC: draft-ietf-netext-pmip-lr > > > Hello, > > Consider this as the working group last call for the I-D: > Localized Routing for Proxy Mobile IPv6 . > > > Please review and submit your comments to the ML or authors by April 30th, > 2011. > > -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 May 12 18:19:14 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876C2E07AB for ; Thu, 12 May 2011 18:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc2+6fgfi3u1 for ; Thu, 12 May 2011 18:19:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DD818E0759 for ; Thu, 12 May 2011 18:19:13 -0700 (PDT) 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 <0LL400GZL0Z9FI@szxga05-in.huawei.com> for netext@ietf.org; Fri, 13 May 2011 09:18:46 +0800 (CST) Received: from c00111037 ([10.111.16.79]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL400MPS0Z8EP@szxga05-in.huawei.com> for netext@ietf.org; Fri, 13 May 2011 09:18:45 +0800 (CST) Date: Fri, 13 May 2011 09:18:53 +0800 From: Xiangsong Cui In-reply-to: <4DCC4DAE.4050305@ericsson.com> To: 'Suresh Krishnan' Message-id: <004b01cc110b$b9eea900$2dcbfb00$%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: AcwQ6Y8Ix2BxQY4KT2+7QeOx3sJNawAIRFoQ References: <007901cbf5d4$0d239a20$276ace60$%cui@huawei.com> <4DCC4DAE.4050305@ericsson.com> Cc: netext@ietf.org Subject: Re: [netext] My comments on draft-ietf-netext-pmip-lr-01 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2011 01:19:14 -0000 Hi Suresh, > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Friday, May 13, 2011 5:14 AM > To: Xiangsong Cui > Cc: netext@ietf.org > Subject: Re: [netext] My comments on draft-ietf-netext-pmip-lr-01 > > Hi Xiangsong, > Thanks for your comments. Please find responses inline. > > Xiangsong Cui wrote: > > Hi, > > > > I have reviewed this draft, and I have two comments. > > > > First, in the case of A11 scenario, > > > > It reads "It is also possible that > > one of the mobility entities (LMA or MAG) could decide to initiate > > localized routing based on configured policy." > > > > But based on the statement of section 2, ONLY LMA can initiate the LR > > function in this case, > > Right. But, the base PMIPv6 spec [RFC5213] allows the MAG to be > configured to initiate localized routing using the EnableMAGLocalRouting > (static) configuration variable. I have added the following text to > clarify this > > "Please note that a MAG implementing the protocol specified in this > specification will not dynamically initiate LR in the same LMA case > (i.e. by sending an LRI), but can statically initiate LR based on the > EnableMAGLocalRouting configuration variable specified in [RFC5213]." > > Does that work for you? Yes, I think this description is very good. > > > So I'm not sure, does this mean MAG may transmit a U-LRA to trigger > the LMA > > to initiate the LR function? > > > > > > > > My Second comment is about the statement of section 4, > > > > "The MAG may refresh the lifetime of an existing local forwarding > > service. For this, it sends an unsolicited LRA (U-LRA) message that > > contains the new lifetime value. The MAG MUST wait for the following > > LRI message from the LMA before it can conclude that the refresh > > request is granted." > > > > I think this is not very clear, what would happen in the LMA if the MAG > > doesn't transmit the U-LRA message? > > Does this mean the LMA MUST respond a LRI message to the MAG and the > MAG > > further transmits an acknowledge LRA? > > If the MAG doesn't receive the following LRI, what would happen? Is there > > any retransmission? > > And, does the MAG transmit refreshment PBU to the LMA after it > transmits the > > U-LRA? > > I think the U-LRA is causing too much confusion and it not very useful. > It probably makes sense to remove this from the spec. Yes, if the MAG would send PBU for the MNs, I think we don't need a separate U-LRA signaling to refresh the LR lifetime. Thanks, Xiangsong > > Thanks > Suresh From ietf-ipr@ietf.org Tue May 24 07:26:33 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F76E0758; Tue, 24 May 2011 07:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZGOo73zN9Bd; Tue, 24 May 2011 07:26:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB41E06AF; Tue, 24 May 2011 07:26:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: jouni.nospam@gmail.com, sri.gundavelli@cisco.com, yokota@kddilabs.jp, Xiangsong.Cui@huawei.com, X-Test-IDTracker: no Message-ID: <20110524142632.28691.64788.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2011 07:26:32 -0700 X-Mailman-Approved-At: Tue, 24 May 2011 07:57:18 -0700 Cc: netext@ietf.org, housley@vigilsec.com, rdroms.ietf@gmail.com, ipr-announce@ietf.org Subject: [netext] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-netext-redirect-07 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2011 14:26:33 -0000 Dear Jouni Korhonen, Sri Gundavelli, Hidetoshi Yokota, Xiangsong Cui: An IPR disclosure that pertains to your Internet-Draft entitled "Runtime L= MA Assignment Support for Proxy Mobile IPv6" (draft-ietf-netext-redirect) was submitted to the IETF Secretariat on 2011-05-24 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1559/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ne= text- redirect-07.""); The IETF Secretariat From multimob2011@gmail.com Wed May 25 01:55:10 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0F2E06EC for ; Wed, 25 May 2011 01:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWiCTkbKMyH3 for ; Wed, 25 May 2011 01:55:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9607CE0664 for ; Wed, 25 May 2011 01:55:09 -0700 (PDT) Received: by yxk30 with SMTP id 30so3747672yxk.31 for ; Wed, 25 May 2011 01:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=8mlAEUtvz/4T3RR58t/3Hu3EnDt3p77msnfAqxXlidQ=; b=EwKvxzL+YAbKe7i1mio5Rg4LJrf/woWnLJIYsvz2Zj6ObBTE4DVYyXs+8FyR4KWPHB tn/Ol6WnKt7NjniFrRM4C91aBrmShuclWoDlrgWlIHfNQXNE97Yx4bVOL4wfrfa8T+v0 hkug8mrzbTchovbq0eVZp8Yfb/crfvS4oNzgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gDHJeVPsmQlaPa1WLUeg0NK3ZB9cljea+Bg5b8OCzMSVOaGgoGTxy0cQ42gShJQaIv MCQHiNtMZgxLZ2eVynV6ggaSD0rwEIHlzp5IqhNO2WuqWCdDnqbgD36OMmq0FdZqjmns oA4RPxzjBFbrUehBhCTUnKNRheQntUFPDXS2o= MIME-Version: 1.0 Received: by 10.150.193.17 with SMTP id q17mr4842443ybf.189.1306313708883; Wed, 25 May 2011 01:55:08 -0700 (PDT) Received: by 10.150.201.21 with HTTP; Wed, 25 May 2011 01:55:08 -0700 (PDT) Date: Wed, 25 May 2011 16:55:08 +0800 Message-ID: From: Aaron Feng To: netext@ietf.org Content-Type: multipart/alternative; boundary=000e0cd63a08954fda04a415dcb4 Subject: [netext] Questions for RFC 5213 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2011 08:55:10 -0000 --000e0cd63a08954fda04a415dcb4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi! I'm now studying PMIPv6, and I'm confused about whether PMIPv6 can support multicast protocol and need some help. I tried to send multicast data orginated by MN to the MAG, but without fowarding multicast data to th= e LMA through LMA-MAG tunnel, MAG just discarded the multicast data packets even though I had run the multicast protocol. Here's my question. In RFC 5213, it says "On receiving a packet from a mobile node connected to its access link, to a destination that is not directly connected, the packet MUST be forwarded to the local mobility anchor through the bidirectional tunnel established between itself and the mobile node=92s loc= al mobility anchor." According to it, maybe LMA will discard the multicast dat= a for not having multicast forwarding stare but the MAG should forward packets. Does it mean PMIPv6 is just for unicast or the source code I used isn't consistent with what you mean? And what is the rules of MAG fowarding packets from MN? I'm very appreciated for your help! With best regards Aaron --000e0cd63a08954fda04a415dcb4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
=A0=A0 =A0Hi! I'm now= studying PMIPv6, and I'm confused about whether PMIPv6 can support mul= ticast protocol and need some help. I tried to send multicast data orginate= d by MN to the MAG, but without fowarding multicast data to the LMA through= LMA-MAG tunnel, MAG just discarded the multicast data packets even though = I had run the multicast protocol. Here's my question. In RFC 5213, it s= ays "On receiving a packet from a mobile node connected to its access= =A0link, to a destination that is not directly connected, the packet=A0MUST= be forwarded to the local mobility anchor through the bidirectional=A0tunn= el established between itself and the mobile=A0node=92s local mobility anch= or." According to it, maybe LMA will discard the multicast data for no= t having multicast forwarding stare but the MAG should forward packets. Doe= s it mean PMIPv6 is just for unicast or the source code I used isn't co= nsistent with what you mean? And what is the rules of MAG fowarding packets= from MN? =A0I'm very appreciated for your help!=A0
=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0With best regards
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Aaron
= --000e0cd63a08954fda04a415dcb4-- From sgundave@cisco.com Wed May 25 04:33:48 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D16E0680 for ; Wed, 25 May 2011 04:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NKn7iLBOvOP for ; Wed, 25 May 2011 04:33:47 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 20C64E0618 for ; Wed, 25 May 2011 04:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5162; q=dns/txt; s=iport; t=1306323227; x=1307532827; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=A/cDl7fRji3nKtD3BP+OwJM3UYXeQRC2ytG3ZurxPng=; b=gvdAckcaCRZ4RsUzZ1dXe/G5RYtgKLgRfLukrMa+4xUlfxCjO5SK629e 4wQoxHpO5dqqCbhqZarCHDvIeCLJp+p63O28BD8hXYFh0BnZy/2r3q4UY xAhX2OOv8XbuR+g41Xe32tOHbCBLBFnZxaq9xy3/qqCt8icQCrmbT10j4 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA7o3E2rRDoG/2dsb2JhbACCZaJlX3iIcJ8OnX2GHASGW4lThECEGIZP X-IronPort-AV: E=Sophos;i="4.65,266,1304294400"; d="scan'208,217";a="453948853" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 25 May 2011 11:33:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4PBXkcg029831; Wed, 25 May 2011 11:33:46 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 May 2011 04:33:46 -0700 Received: from 10.32.243.72 ([10.32.243.72]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 May 2011 11:33:46 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 25 May 2011 04:33:47 -0700 From: Sri Gundavelli To: Aaron Feng , Message-ID: Thread-Topic: [netext] Questions for RFC 5213 Thread-Index: Acwaz5xQBZAu7Y0QB0uvb1iOEcNbbw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3389142827_5900833" X-OriginalArrivalTime: 25 May 2011 11:33:46.0687 (UTC) FILETIME=[9C211CF0:01CC1ACF] Subject: Re: [netext] Questions for RFC 5213 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2011 11:33:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3389142827_5900833 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Aaron, Enabling multicast services in a PMIPv6 domain should naturally work, with no new considerations. It is true, RFC-5213 did not go into those details. However, multimob WG has sufficiently worked on this problem and they are exploring every optimization. I do not know what implementation of MAG/LMA you are using, but the issue is specific to that implementation. I suggest, you look at the specs in multimob WG. Regards Sri On 5/25/11 1:55 AM, "Aaron Feng" wrote: > =A0=A0 =A0Hi! I'm now studying PMIPv6, and I'm confused about whether PMIPv6 ca= n > support multicast protocol and need some help. I tried to send multicast = data > orginated by MN to the MAG, but without fowarding multicast data to the L= MA > through LMA-MAG tunnel, MAG just discarded the multicast data packets eve= n > though I had run the multicast protocol. Here's my question. In RFC 5213,= it > says "On receiving a packet from a mobile node connected to its access=A0li= nk, > to a destination that is not directly connected, the packet=A0MUST be forwa= rded > to the local mobility anchor through the bidirectional=A0tunnel established > between itself and the mobile=A0node=B9s local mobility anchor." According to= it, > maybe LMA will discard the multicast data for not having multicast forwar= ding > stare but the MAG should forward packets. Does it mean PMIPv6 is just for > unicast or the source code I used isn't consistent with what you mean? An= d > what is the rules of MAG fowarding packets from MN? =A0I'm very appreciated= for > your help!=A0 > =A0 > =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0With best regards > =A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Aaron >=20 >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext --B_3389142827_5900833 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [netext] Questions for RFC 5213 Hi Aaron,

Enabling multicast services in a PMIPv6 domain should naturally work, with = no new considerations. It is true, RFC-5213 did not go into those details. H= owever, multimob WG has sufficiently worked on this problem and they are exp= loring every optimization. I do not know what implementation of MAG/LMA you = are using, but the issue is specific to that implementation. I suggest, you = look at the specs in multimob WG.

Regards
Sri




On 5/25/11 1:55 AM, "Aaron Feng" <multimob2011@gmail.com> wrote:

=A0=A0 =A0Hi! I'm now studying PMIPv6, and I'm confused about whethe= r PMIPv6 can support multicast protocol and need some help. I tried to send = multicast data orginated by MN to the MAG, but without fowarding multicast d= ata to the LMA through LMA-MAG tunnel, MAG just discarded the multicast data= packets even though I had run the multicast protocol. Here's my question. I= n RFC 5213, it says "On receiving a packet from a mobile node connected= to its access=A0link, to a destination that is not directly connected, the pa= cket=A0MUST be forwarded to the local mobility anchor through the bidirectiona= l=A0tunnel established between itself and the mobile=A0node’s local mobili= ty anchor." According to it, maybe LMA will discard the multicast data = for not having multicast forwarding stare but the MAG should forward packets= . Does it mean PMIPv6 is just for unicast or the source code I used isn't co= nsistent with what you mean? And what is the rules of MAG fowarding packets = from MN? =A0I'm very appreciated for your help!=A0
=A0
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0With best regards
=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Aaron

___________= ____________________________________
netext mailing list
netext@ietf.org
https://www.ietf.org= /mailman/listinfo/netext
--B_3389142827_5900833-- From behcetsarikaya@yahoo.com Wed May 25 09:27:00 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC1CE0819 for ; Wed, 25 May 2011 09:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pTdG-U7pMCm for ; Wed, 25 May 2011 09:26:59 -0700 (PDT) Received: from nm2.bullet.mail.sp2.yahoo.com (nm2.bullet.mail.sp2.yahoo.com [98.139.91.72]) by ietfa.amsl.com (Postfix) with SMTP id C89DBE0817 for ; Wed, 25 May 2011 09:26:59 -0700 (PDT) Received: from [98.139.91.63] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 25 May 2011 16:26:57 -0000 Received: from [98.139.91.30] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 25 May 2011 16:26:57 -0000 Received: from [127.0.0.1] by omp1030.mail.sp2.yahoo.com with NNFMP; 25 May 2011 16:26:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 157117.90061.bm@omp1030.mail.sp2.yahoo.com Received: (qmail 44187 invoked by uid 60001); 25 May 2011 16:26:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1306340816; bh=uF9oVFoTonKFpDbT6XYSzHJQMFlI0W8fN+Z7pAKTklY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vad2Pdh5xBKBtTuFdIYuuZZpe0uqBGEfkaOMdW9M9ZvrKKF9q7HilV6AxPlKhQX67iPFdaW2Ffi8UMNKDCa6Mn1Pk6yNrRX0JzPmCpMDWCwUGYrtGR9B7gK8j40sO7BUf1BF5k1Ti20zIai8Mrg6Js0CO/5bDpYHlpDu4wX79yI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=efFeGYxYQXE6JmzTRHgFf6o6ArdJW5ZYIwlvPU/AR9LHhmRzZth1F2vmlvrOGPLLQDuJbL7pFocdPGWDR0UvwBK5hMo8FX7dzyPW4cuxAKTmJyP7FjfJoOrF3pTdckV0NTw7zAgOPZH0fMmlah9ntjzNg5WqzD4hvc/INWvcuiU=; Message-ID: <723530.40605.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: XmiSJtAVM1mN6a2GTUG0atRiEOsRai.VLRvwf_8JPNqI7ty NEpVX0Kua2welV6H9OKULdWJ0XSuGJH4R84CsBB0qiChH2QthwvpIlYvXDNc VvUOP4O6.Mt4UMhJ9AI.7eaOAD5dftBVBOerP1NbQvGrdw493Oyzws7jmph6 20pqftrx52AuepYvKSu9TZcqiDd8e5lATXc49Rmbo4449TV4S8VJvML02RBS 3j057AoFrf9lRfpoSH6Y0wIrG1RyXhMVQ9aJfJKlbXt8L.nsQ3OmLOdJs38i NqWq.Y3rBSyDtVISYpocEjluQuljE73OgqXK_437yY2ugVZzPqksTCmoqZJy X0EZGPkDqLxo6U9Hw1SDLLwVPgBLFWe8t2DPWdtUDzQRA7TQGXZ_ItU_aCCv H1zNWbA.dRDxnZA-- Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Wed, 25 May 2011 09:26:56 PDT X-Mailer: YahooMailRC/567 YahooMailWebService/0.8.111.303096 References: Date: Wed, 25 May 2011 09:26:56 -0700 (PDT) From: Behcet Sarikaya To: Sri Gundavelli , Aaron Feng , netext@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] Questions for RFC 5213 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:27:00 -0000 =0A>Re: [netext] Questions for RFC 5213 Hi Aaron,=0A>=0A>Enabling multicast= services in a PMIPv6 domain should naturally work, with no =0A>new conside= rations. It is true, RFC-5213 did not go into those details. However, =0A>= =0A>multimob WG has sufficiently worked on this problem and they are explor= ing every =0A>=0A>optimization. I do not know what implementation of MAG/LM= A you are using, but =0A>the issue is specific to that implementation. I su= ggest, you look at the specs =0A>in multimob WG.=0A=0A=0AYes, please join M= ultimob Working Group mailing list and post your question =0Athere.=0A=0AAn= d then see what happens.=0A=0ARegards,=0A=0ABehcet=0A>=0A>On 5/25/11 1:55 A= M, "Aaron Feng" wrote:=0A>=0A>=0A> Hi! I'm now = studying PMIPv6, and I'm confused about whether PMIPv6 can =0A>support mult= icast protocol and need some help. I tried to send multicast data =0A>orgin= ated by MN to the MAG, but without fowarding multicast data to the LMA =0A>= through LMA-MAG tunnel, MAG just discarded the multicast data packets even = =0A>though I had run the multicast protocol. Here's my question. In RFC 521= 3, it =0A>says "On receiving a packet from a mobile node connected to its a= ccess link, to =0A=0A>a destination that is not directly connected, the pac= ket MUST be forwarded to =0A>the local mobility anchor through the bidirect= ional tunnel established between =0A>itself and the mobile node=E2=80=99s l= ocal mobility anchor." According to it, maybe LMA =0A=0A>will discard the m= ulticast data for not having multicast forwarding stare but =0A>the MAG sho= uld forward packets. Does it mean PMIPv6 is just for unicast or the =0A>sou= rce code I used isn't consistent with what you mean? And what is the rules = of =0A>=0A>MAG fowarding packets from MN? I'm very appreciated for your he= lp! =0A>> =0A>> With best regards=0A>> = Aaron=0A>>=0A>>_________________= _______________=0A_______________________________________________=0A>>netex= t mailing list=0A>>netext@ietf.org=0A>>https://www.ietf.org/mailman/listinf= o/netext=0A>> From Basavaraj.Patil@nokia.com Tue May 31 07:07:05 2011 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76289E072D for ; Tue, 31 May 2011 07:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDNPhiFXftiR for ; Tue, 31 May 2011 07:07:01 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5205BE0797 for ; Tue, 31 May 2011 07:07:00 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4VE6rVt028515 for ; Tue, 31 May 2011 17:06:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 May 2011 17:06:48 +0300 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; Tue, 31 May 2011 16:06:47 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Tue, 31 May 2011 16:06:46 +0200 From: To: Thread-Topic: Seeking consensus on way forward with WG I-D: draft-ietf-netext-redirect Thread-Index: AcwczlEmsZ0vpQIwSZKO4D1sPq8R4Q== Date: Tue, 31 May 2011 14:06:46 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B71904C2DB@008-AM1MPN1-024.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.74.219.186] Content-Type: multipart/alternative; boundary="_000_21E7D9BD69CC7241AAE00F4EA183B71904C2DB008AM1MPN1024mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 May 2011 14:06:48.0627 (UTC) FILETIME=[FB787830:01CC1F9B] X-Nokia-AV: Clean Subject: [netext] Seeking consensus on way forward with WG I-D: draft-ietf-netext-redirect X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2011 14:07:05 -0000 --_000_21E7D9BD69CC7241AAE00F4EA183B71904C2DB008AM1MPN1024mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The WG has been notified about the following IPR claim on the I-D: draft-ietf-netext-redirect-07.txt Please see: http://www.ietf.org/mail-archive/web/netext/current/msg01982.html The I-D which had been forwarded to the IESG for approval has now been sent back to the WG. We would like to solicit feedback from the WG members (and authors) about the way forward. There are several possibilities as listed below (but not limited to): 1. The concern with the IPR is noted but no change to the current I-D is made (e.g., if the license is free and available for everyone 2. Since the IPR basically covers the solution documented in Section 5.4 removing the whole section could be an option 3. Move Section 5.4 to an appendix and make it non-normative 4. Others? Please provide your input to this discussion by June 15th, 2011. We will move forward based on the consensus opinion. -Chairs --_000_21E7D9BD69CC7241AAE00F4EA183B71904C2DB008AM1MPN1024mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

The WG has been notified about the following IPR cla= im on the I-D:

draft-ietf-netext-redirect-07.txt

Please see:

http://www.ietf.org/mail-archive/web/netext/current/= msg01982.html

 

The I-D which had been forwarded to the IESG for app= roval has now been

sent back to the WG. We would like to solicit feedba= ck from the WG

members (and authors) about the way forward.

There are several possibilities as listed below (but= not limited to):

 

1. The concern with the IPR is noted but no change t= o the current I-D

   is made (e.g., if the license is free a= nd available for everyone

  

2. Since the IPR basically covers the solution docum= ented in Section

   5.4 removing the whole section could be= an option

 

3. Move Section 5.4 to an appendix and make it non-n= ormative

 

4. Others?

 

Please provide your input to this discussion by June= 15th, 2011. We

will move forward based on the consensus opinion.

 

-Chairs

--_000_21E7D9BD69CC7241AAE00F4EA183B71904C2DB008AM1MPN1024mgdn_--