From seiljeon@gmail.com Mon Aug 1 01:15:20 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F87221F85A1 for ; Mon, 1 Aug 2011 01:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 ZTNmACog9lcZ for ; Mon, 1 Aug 2011 01:15:19 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0A3221F84E6 for ; Mon, 1 Aug 2011 01:15:19 -0700 (PDT) Received: by qyk9 with SMTP id 9so913937qyk.10 for ; Mon, 01 Aug 2011 01:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=T/llN/lN3yjqudItuTSJBk33sHy59Tiqrvba4UTt6O0=; b=Q9D7BpHWQIMRJw1SxxLUDnBq0x3XHaOnaH5KzlF1EXUbj7O9opN/lFAIzcIPpVEdRs 2TtZXiGc2D0YtfLBNwB+2UsdPDt36ZOS4GP0R5G8jR9YndeshHi5X3iYyzf4OHEBo3NB F0D++XXXn2qd2Gajbd2RXIRGQgh9/eH013FNg= MIME-Version: 1.0 Received: by 10.229.251.76 with SMTP id mr12mr869590qcb.13.1312186524998; Mon, 01 Aug 2011 01:15:24 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.229.225.208 with HTTP; Mon, 1 Aug 2011 01:15:24 -0700 (PDT) In-Reply-To: <4E2EDB8A.6080305@informatik.haw-hamburg.de> References: <4E2D5D61.8060504@informatik.haw-hamburg.de> <20110725.215732.190261334.asaeda@sfc.wide.ad.jp> <4E2DAABE.7010404@informatik.haw-hamburg.de> <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> <4E2EDB8A.6080305@informatik.haw-hamburg.de> Date: Mon, 1 Aug 2011 17:15:24 +0900 X-Google-Sender-Auth: h6-JqNP0rRg1Ne-WdUR8VD1D5BU Message-ID: From: seil jeon To: Hitoshi Asaeda Content-Type: multipart/alternative; boundary=001636284552b39dc304a96d3b41 Cc: multimob@ietf.org Subject: [multimob] Fwd: PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 08:15:20 -0000 --001636284552b39dc304a96d3b41 Content-Type: text/plain; charset=ISO-8859-1 Hi Hitoshi, In your draft, GRE tunnel between a MAG and an LMA is used for multicat data transmission. I guess this tunnel is regardless of the association of the MN and the LMA. So, it can establish only one tunnel between MAG and LMA and avoid tunnel convergence issue. But following conversation gives me confusion to understand your idea. Could you clarify what I'm confused? Your regards ---------- Forwarded message ---------- From: Thomas C. Schmidt Date: 2011/7/27 Subject: Re: [multimob] PMIPv6 extension for multicast To: Hitoshi Asaeda Cc: multimob@ietf.org Now following your answers and the presentation/discussion in the group, >> the following seems to be clarified: >> >> * You span static tunnels between all LMA-MAG pairs that are in the >> deployment scenario you consider. (This is what we called a mesh, but >> mesh is only a word.) In typical cases, you will add some hundreds of >> multicast-initiated tunnel end points to a single LMA ... >> > > As I said, it is not necessary to create static M-Tunnels to all > LMA-MAG pairs. How many M-tunnels is set up is operators decision; it > would be same to or less than the number of association between > LMA-MAG. It can be adjusted by operators. > > Thomas> Well, your solution builds on this M x N tunnel mesh. Of course, an operator can choose not to deploy it :-) ______________________________**_________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/**listinfo/multimob --001636284552b39dc304a96d3b41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hitoshi,
=A0
In your draft, GRE tunnel between a MAG and an L= MA is used for multicat data transmission.
I guess this tunnel is regard= less of the association of the MN and the LMA.
So, it can establish only= one tunnel between MAG and LMA and avoid tunnel convergence issue.
But following conversation gives me confusion to understand your idea.
C= ould you clarify what I'm confused?
=A0
Your regards


=A0
---------- Forwarded message ----------
From:= Thomas C. Schmidt <= schmidt@informatik.haw= -hamburg.de>
Date: 2011/7/27
Subject: Re: [multimob] PMIPv6 extension for multicastTo: Hitoshi Asaeda <asaeda@sf= c.wide.ad.jp>
Cc: multimob@i= etf.org


Now following your answers and t= he presentation/discussion in the group,
the following seems to be clari= fied:

=A0* You span static tunnels between all LMA-MAG pairs that are in the<= br>deployment scenario you consider. (This is what we called a mesh, butmesh is only a word.) In typical cases, you will add some hundreds of
multicast-initiated tunnel end points to a single LMA ...
<= br>As I said, it is not necessary to create static M-Tunnels to all
LMA-= MAG pairs. How many M-tunnels is set up is operators decision; it
would = be same to or less than the number of association between
LMA-MAG. It can be adjusted by operators.


Tho= mas> Well, your solution builds on this M x N tunnel mesh. Of course, an= operator can choose not to deploy it :-)=20

______________________________________________= _

--001636284552b39dc304a96d3b41-- From asaeda@sfc.wide.ad.jp Mon Aug 1 02:15:25 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD52A21F8569 for ; Mon, 1 Aug 2011 02:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, 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 k59T3oJXWC9q for ; Mon, 1 Aug 2011 02:15:25 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6021F8568 for ; Mon, 1 Aug 2011 02:15:24 -0700 (PDT) Received: from localhost (dhcp-143-228.sfc.wide.ad.jp [203.178.143.228]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9D4DB27808D; Mon, 1 Aug 2011 18:14:57 +0900 (JST) Date: Mon, 01 Aug 2011 18:14:55 +0900 (JST) Message-Id: <20110801.181455.92576359.asaeda@sfc.wide.ad.jp> To: sijeon79@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> <4E2EDB8A.6080305@informatik.haw-hamburg.de> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 09:15:25 -0000 Hi Seil, > In your draft, GRE tunnel between a MAG and an LMA is used for multicat data > transmission. Establishing M-Tunnel is operator's demand. If operators configure M-Tunnel to set up special mroutes, then the mroutes using M-Tunnel will be inserted into MRIB and PIM-SM on MAG uses the MRIB. If they do not configure M-Tunnel (as they don't need to distinguish multicast path and unicast path or they decide to inherit RIB to MRIB), then PIM-SM on MAG simply selects the regular IPv6-IPv6 tunnel by the RPF. > I guess this tunnel is regardless of the association of the MN and the LMA. Right. It does not depend on the MN-LMA association. > So, it can establish only one tunnel between MAG and LMA and avoid tunnel > convergence issue. No, the tunnel convergence problem is solved by the RPF, not M-tunnel. > But following conversation gives me confusion to understand your idea. > Could you clarify what I'm confused? Well, I recognize M-Tunnel makes people confuse. And it is not the mandatory function for our solution. So I will remove it from the next revision. Sorry for your confusion. Regards, -- Hitoshi Asaeda > > ---------- Forwarded message ---------- > From: Thomas C. Schmidt > Date: 2011/7/27 > Subject: Re: [multimob] PMIPv6 extension for multicast > To: Hitoshi Asaeda > Cc: multimob@ietf.org > > > Now following your answers and the presentation/discussion in the group, >>> the following seems to be clarified: >>> >>> * You span static tunnels between all LMA-MAG pairs that are in the >>> deployment scenario you consider. (This is what we called a mesh, but >>> mesh is only a word.) In typical cases, you will add some hundreds of >>> multicast-initiated tunnel end points to a single LMA ... >>> >> >> As I said, it is not necessary to create static M-Tunnels to all >> LMA-MAG pairs. How many M-tunnels is set up is operators decision; it >> would be same to or less than the number of association between >> LMA-MAG. It can be adjusted by operators. >> >> > Thomas> Well, your solution builds on this M x N tunnel mesh. Of course, an > operator can choose not to deploy it :-) > > ______________________________**_________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/**listinfo/multimob From behcetsarikaya@yahoo.com Mon Aug 8 14:04:28 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB62311E80C1 for ; Mon, 8 Aug 2011 14:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTzBI6OUppuc for ; Mon, 8 Aug 2011 14:04:28 -0700 (PDT) Received: from nm15-vm0.bullet.mail.ne1.yahoo.com (nm15-vm0.bullet.mail.ne1.yahoo.com [98.138.91.70]) by ietfa.amsl.com (Postfix) with SMTP id C190711E80AE for ; Mon, 8 Aug 2011 14:04:27 -0700 (PDT) Received: from [98.138.90.51] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 08 Aug 2011 21:04:54 -0000 Received: from [98.138.89.253] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 08 Aug 2011 21:04:54 -0000 Received: from [127.0.0.1] by omp1045.mail.ne1.yahoo.com with NNFMP; 08 Aug 2011 21:04:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 303487.31130.bm@omp1045.mail.ne1.yahoo.com Received: (qmail 40816 invoked by uid 60001); 8 Aug 2011 21:04:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312837493; bh=pD8XE1LCk18tt0NQqqj51asizDuAqQhRK3qeTvT3h5g=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nkiwhINRkZxpyj1+vrOWlnZZqMA1KUr+Q3nWlVyJFMVB0us4m1/PeY9wdHI0n6KaI3pVMrXoV+Geatu+tCav9dCUHvlownLi5WlXBNVDR+nVTdVAyYjBFmm9UTxVPG7sBtT2pSD8KFyQmqhPjlAt2RjZmfsvxU5z+onZspupJTs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=X4sNomcI91VTDYCUlZOwY0OzuJp/yKcgtoPE+Ilur4yvOjZMKsU4NI2olwCiWZcaEXbDELtnQcFAK+h/fScMqn+B9cgN/otxWpVBMyCffP7G2qlXwQZQtJG9etrJEGhBADwnCmCg28aoJLF6lb40ehi0XiZNSKcKB03t/cLloL0=; X-YMail-OSG: bDY_40AVM1k_e_HyvVub_z.C0oW3l8sXXVZtGCwGLLNYx2v GLoB.2TWcgV3mQrTS4wx8Dwk89MbnEzkyBglwV4GHUnmnPSjxIB2M9V0OSi9 q.8FF59jHMdHujMD9Sr9TdusUHJsjP4hSt8Cs9UzwA1Dz25miMEfwdli9zll 40cBl4EWgjOPaWsb5wBtiX0WRj2N1rw36pJLVWCPG57vSN1yqY_j66uFs_PU O2xPNjyPWrxs9EVm5HyvXWxBDCJrCHGSLVG582hPfVRbghtJdQVMB1TW1PQR 6VQhMHPPhIqfYB0IVg8JYO._GOrIZTTRfraJfV11TjheWnJYn7HudK_Q8.45 t0HwDBdaQp9Nm5Wmz8ar4aLeUQIpRcNQcBo8H4SmPRPmC0sDj3uu60LHU.fZ g3g7e4fZ2mXsKdGTfXSajdQHLOvGFtPdvKsrym4f4AIq4CpD2Cd0fHdgQzGy Iwm8.ekQ- Received: from [50.58.7.243] by web111413.mail.gq1.yahoo.com via HTTP; Mon, 08 Aug 2011 14:04:53 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <20110726.175332.253600511.asaeda@sfc.wide.ad.jp> <4E2EDB8A.6080305@informatik.haw-hamburg.de> <20110801.181455.92576359.asaeda@sfc.wide.ad.jp> Message-ID: <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> Date: Mon, 8 Aug 2011 14:04:53 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , "sijeon79@gmail.com" In-Reply-To: <20110801.181455.92576359.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 21:04:28 -0000 Hi Hitoshi,=0A=A0 Two cases need to be clarified, I think. One is PIM-SM = =0Aat the MAG for multicast traffic to/from MNs and the other one is =0Aso-= called local routing or how to connect the multicast source to the =0AMAG a= s PIM-SM router.=0A=0AAs far as I can see, the first case is more=0A or les= s clarified, i.e. PIM-SM can probably work with MAG routing =0Atables and i= t would also avoid the tunnel convergence problem.=0A=0AI am not sure about= the second one.=0A=0ARegards,=0A=0ABehcet=0A=0A=0APS. sorry for the duplic= ates.=0A=0A> Hi Seil,=0A> =0A>> In your draft, GRE tunnel between a MAG an= d an LMA is used for multicat =0A> data=0A>> transmission.=0A> =0A> Establ= ishing M-Tunnel is operator's demand.=0A> If operators configure M-Tunnel t= o set up special mroutes, then the=0A> mroutes using M-Tunnel will be inser= ted into MRIB and PIM-SM on MAG=0A> uses the MRIB.=0A> If they do not confi= gure M-Tunnel (as they don't need to distinguish=0A> multicast path and uni= cast path or they decide to inherit RIB to=0A> MRIB), then PIM-SM on MAG si= mply selects the regular IPv6-IPv6 tunnel=0A> by the RPF.=0A> =0A>> I gues= s this tunnel is regardless of the association of the MN and the LMA.=0A> = =0A> Right. It does not depend on the MN-LMA association.=0A> =0A>> So, it= can establish only one tunnel between MAG and LMA and avoid tunnel=0A>> c= onvergence issue.=0A> =0A> No, the tunnel convergence problem is solved by = the RPF, not M-tunnel.=0A> =0A>> But following conversation gives me confu= sion to understand your idea.=0A>> Could you clarify what I'm confused?=0A= > =0A> Well, I recognize M-Tunnel makes people confuse. And it is not the= =0A> mandatory function for our solution. So I will remove it from the next= =0A> revision.=0A> =0A> Sorry for your confusion.=0A> =0A> Regards,=0A> --= =0A> Hitoshi Asaeda=0A> =0A> =0A>> =0A>> ---------- Forwarded message ----= ------=0A>> From: Thomas C. Schmidt =0A= >> Date: 2011/7/27=0A>> Subject: Re: [multimob] PMIPv6 extension for mult= icast=0A>> To: Hitoshi Asaeda =0A>> Cc: multimob@i= etf.org=0A>> =0A>> =0A>> =A0 Now following your answers and the presentatio= n/discussion in the group,=0A>>>> the following seems to be clarified:=0A>= >>> =0A>>>> =A0 * You span static tunnels between all LMA-MAG pairs that ar= e in =0A> the=0A>>>> deployment scenario you consider. (This is what we ca= lled a mesh, =0A> but=0A>>>> mesh is only a word.) In typical cases, you w= ill add some hundreds =0A> of=0A>>>> multicast-initiated tunnel end points= to a single LMA ...=0A>>>> =0A>>> =0A>>> As I said, it is not necessary t= o create static M-Tunnels to all=0A>>> LMA-MAG pairs. How many M-tunnels i= s set up is operators decision; it=0A>>> would be same to or less than the= number of association between=0A>>> LMA-MAG. It can be adjusted by operat= ors.=0A>>> =0A>>> =0A>> Thomas> Well, your solution builds on this M x N t= unnel mesh. Of course, =0A> an=0A>> operator can choose not to deploy it := -)=0A>> =0A>> ______________________________**_________________=0A>> =A0 m= ultimob mailing list=0A>> multimob@ietf.org=0A>> =0A> https://www.ietf.org= /mailman/**listinfo/multimob=0A> _______________________________________________=0A> multimob mailing = list=0A> multimob@ietf.org=0A> https://www.ietf.org/mailman/listinfo/multim= ob=0A> From asaeda@sfc.wide.ad.jp Tue Aug 9 02:16:40 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4455C21F8B27 for ; Tue, 9 Aug 2011 02:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQg1-iJhX3gH for ; Tue, 9 Aug 2011 02:16:39 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 16C4C21F851F for ; Tue, 9 Aug 2011 02:16:36 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 224BE278094; Tue, 9 Aug 2011 18:16:33 +0900 (JST) Date: Tue, 09 Aug 2011 18:16:32 +0900 (JST) Message-Id: <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> References: <20110801.181455.92576359.asaeda@sfc.wide.ad.jp> <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 09:16:40 -0000 Hi Behcet, > =A0 Two cases need to be clarified, I think. One is PIM-SM = > at the MAG for multicast traffic to/from MNs and the other one is = > so-called local routing or how to connect the multicast source to the= = > MAG as PIM-SM router. > = > As far as I can see, the first case is more > or less clarified, i.e. PIM-SM can probably work with MAG routing = > tables and it would also avoid the tunnel convergence problem. > = > I am not sure about the second one. This draft does not describe source mobility and local routing. What this draft says is that if MAG can coordinate appropriate MRIB, PIM-SM on MAG can cooperate with local routing to deliver IP multicast packets for mobile nodes. I guess the discussion how to coordinate appropriate MRIB *for local routing* in PMIPv6 should be discussed in a separate draft, whose title would be "Localized multicast routing for PIM-SM capable PMIPv6". This draft work definitively needs to refer to draft-ietf-netext-pmip-lr. I'm happy to work on this topic after our PMIPv6 extension draft becomes the WG draft (because that draft will be also referred). Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Tue Aug 9 09:34:05 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFAF11E8085 for ; Tue, 9 Aug 2011 09:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.953 X-Spam-Level: X-Spam-Status: No, score=-0.953 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq3FvuS4mXHn for ; Tue, 9 Aug 2011 09:34:05 -0700 (PDT) Received: from nm7-vm0.bullet.mail.sp2.yahoo.com (nm7-vm0.bullet.mail.sp2.yahoo.com [98.139.91.192]) by ietfa.amsl.com (Postfix) with SMTP id 2681B11E8073 for ; Tue, 9 Aug 2011 09:34:05 -0700 (PDT) Received: from [98.139.91.62] by nm7.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 16:34:33 -0000 Received: from [98.139.91.10] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 16:34:33 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 16:34:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 590760.15021.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 15809 invoked by uid 60001); 9 Aug 2011 16:34:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312907672; bh=MEFJDklKvJAWq7nnxc0FId8O3ye2BokJA6h4WdYNqY0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f8gNF9vxvDXZzfTbKTCRN9aNLE4+uuOXD2OyjlNAxPgFucMpHgu51f951qkP52mdfujYPSPB93Wdac08FgB9rxoGaCFnouqJehqyPWcVTzd3I53DsM7FsKvfJrNgeMquFrP76lmGqQ9RMLcGc/TnNuWsLewFSCfCaSkGM+DWndA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gmLBacjWftDbdZswNWOsFNiQqKDhbJ3OEEP7vjv2E950yydXIQKkoORIWL//udflCbkmjo1hOmolSq4zPUQY0ZV/czw2qHd4eNtFL59+TtdO1hUycD/9FD8KGXISa6tg0mQdShFoNbytChBNhjYS4QGpqIvUURTVG5NOvFug9Kg=; X-YMail-OSG: q9Y8pYsVM1ld6yqczwW63pJVH.RTQC6bGijID6Qap0qEk6A b1w9ZvKgqvjXUK_vodikQM2KuA0l7iQBLPpBC_YaLod5IFhjMSeq3nua5ZBO HD3fjvPx.9L4e3p9RpJce9IWXB5af34FSGhJf7M.8HSyzCkyZrJJMc.1IhA_ 2VprTI0hGCQ74HXLahx.A5YDroCazVOhfyP_ARZChmVy6BIr5faQfVJ1DjYE huGjKhoKLmUPucXPU7r4KFdsHB0uqipecwu_oSiaSMihsVxCQnvOk8ojPlMO x41B9fdsfDx4WDrBywrNlxWWjHT0WY4hFJ1YdL.CxnhvJSAQs7eD5av.KNxL AGmUv4Hu54IzMdIwPRdSHNPVUpKlQ349WI8LuG43DDIS7.tER.pDthwKSZJ3 u77XdxVb3rJlljCj.5Stm0QpGH9QDTUiU6PN.ALtnEuvmh1gjKhaCVdeMPhr dHQSLviM- Received: from [50.58.7.243] by web111403.mail.gq1.yahoo.com via HTTP; Tue, 09 Aug 2011 09:34:32 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <20110801.181455.92576359.asaeda@sfc.wide.ad.jp> <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> Message-ID: <1312907672.89763.YahooMailNeo@web111403.mail.gq1.yahoo.com> Date: Tue, 9 Aug 2011 09:34:32 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:34:05 -0000 =0A=0A=0A=0A> Hi Behcet,=0A> =0A>> =A0 Two cases need to be clarified, I t= hink. One is PIM-SM =0A>> at the MAG for multicast traffic to/from MNs and= the other one is =0A>> so-called local routing or how to connect the mult= icast source to the =0A>> MAG as PIM-SM router.=0A>> =0A>> As far as I ca= n see, the first case is more=0A>> =A0 or less clarified, i.e. PIM-SM can p= robably work with MAG routing =0A>> tables and it would also avoid the tun= nel convergence problem.=0A>> =0A>> I am not sure about the second one.=0A= > =0A> This draft does not describe source mobility and local routing.=0A> = What this draft says is that if MAG can coordinate appropriate=0A> MRIB, PI= M-SM on MAG can cooperate with local routing to deliver IP=0A> multicast pa= ckets for mobile nodes.=0A> =0A> I guess the discussion how to coordinate a= ppropriate MRIB *for local=0A> routing* in PMIPv6 should be discussed in a = separate draft, whose=0A> title would be "Localized multicast routing for P= IM-SM capable=0A> PMIPv6". This draft work definitively needs to refer to= =0A> draft-ietf-netext-pmip-lr.=0A> I'm happy to work on this topic after o= ur PMIPv6 extension draft=0A> becomes the WG draft (because that draft will= be also referred).=0A=0A=0AIn my latest discussion with Stig, Stig mention= ed that PIM-SM assumes =0Athat the source is directly connected. What do yo= u think about this?=0AIf we assume this then we don't need another draft.= =0A=0ARegards,=0A=0ABehcet From asaeda@sfc.wide.ad.jp Tue Aug 9 10:06:01 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A4B11E8080 for ; Tue, 9 Aug 2011 10:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQaF8pIU9Ill for ; Tue, 9 Aug 2011 10:06:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id CD14011E8085 for ; Tue, 9 Aug 2011 10:06:00 -0700 (PDT) Received: from localhost (p3151-ipngn1501hodogaya.kanagawa.ocn.ne.jp [114.166.86.151]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9B44A278094; Wed, 10 Aug 2011 02:05:57 +0900 (JST) Date: Wed, 10 Aug 2011 02:05:57 +0900 (JST) Message-Id: <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> To: behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> References: <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 17:06:01 -0000 >> This draft does not describe source mobility and local routing. >> What this draft says is that if MAG can coordinate appropriate >> MRIB, PIM-SM on MAG can cooperate with local routing to deliver IP >> multicast packets for mobile nodes. >> >> I guess the discussion how to coordinate appropriate MRIB *for local >> routing* in PMIPv6 should be discussed in a separate draft, whose >> title would be "Localized multicast routing for PIM-SM capable >> PMIPv6". This draft work definitively needs to refer to >> draft-ietf-netext-pmip-lr. >> I'm happy to work on this topic after our PMIPv6 extension draft >> becomes the WG draft (because that draft will be also referred). > > In my latest discussion with Stig, Stig mentioned that PIM-SM > assumes that the source is directly connected. What do you think > about this? Source is directly connected to what? MAG? If source is directly connected to MAG, then the localized routing situation should be considered, right? Let's see, except the case that a mobile node is a multicast source, our PMIPv6 extension solution works well, I think. But for that case, because HNP is routed to LMA, all MN's traffic goes through LMA and then LMA forwards the traffic to the downstream routers (e.g. MAG). This route causes higher delay and congestion in the network and requires the localized routing solution discussed as in draft-ietf-netext-pmip-lr. > If we assume this then we don't need another draft. I'll follow the WG decision. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Tue Aug 9 11:15:33 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263F621F8C26 for ; Tue, 9 Aug 2011 11:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNGBldqhDQrp for ; Tue, 9 Aug 2011 11:15:32 -0700 (PDT) Received: from nm18-vm4.bullet.mail.ne1.yahoo.com (nm18-vm4.bullet.mail.ne1.yahoo.com [98.138.91.178]) by ietfa.amsl.com (Postfix) with SMTP id 6CF3021F8C0F for ; Tue, 9 Aug 2011 11:15:32 -0700 (PDT) Received: from [98.138.90.54] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2011 18:15:59 -0000 Received: from [98.138.87.12] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2011 18:15:58 -0000 Received: from [127.0.0.1] by omp1012.mail.ne1.yahoo.com with NNFMP; 09 Aug 2011 18:15:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 961409.30604.bm@omp1012.mail.ne1.yahoo.com Received: (qmail 65634 invoked by uid 60001); 9 Aug 2011 18:15:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312913758; bh=W6QT1Um2OiL+Q3nHtP7hQ7SAFCedbftfao/ujMgVgFI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BPUIQ2/B1Ks7VYL+WGq5NPN1nQJO5I01oNiw7BsP8JLBRXmOpI6iYDzks/1+roWrklggdX4Uub/7gCp8qR1Hs0SEJkTX22PKURiCbXQmhHDmTy2OP8S5nbhqHNnBsC6UUJrcJFHx7ZxM7ZONl11NQeSa2gK9sMJKrXUXwhHkhUs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DlJEc9UVrQ/fUyEZ2T/q0/sZmJbQONUv8E6ZIhPi+BPsCRX/vlWVs1b6kVrKJDpyGWZFXpMpfaRFuB2ArIpxMtNgFJyh3QtnfLIqm4xdnFsFsC4jNDwVgbB5I0/a6lT+wbH18JueI3kZ/7kC1ZbiB5NVxiTxJXowwqpwun9v0Mk=; X-YMail-OSG: DhekYPIVM1nQyfJNQOzwIMeYWNR0RsZ9PWLUHAojBDGLe79 DiCWfxL3FmoplKXjDN5vSv9AApErZy6fj6qsuTfLJn7NcIpH1AR12zjP1lmp AC.x7LNNbcaoPWAXpnwVmtQhgAORbC8CBPjR9MNjrSNBOwBrAetHAOCMgET1 RotFXnvXLdyh4yGjWgv_4oVYwZtc4dklyNrJBOhipEC_5GkLbH2Tn5d2eit_ aZfNUgFGj0qgikr4AGGUdVSPNOYdmwRGkLqwilGAM66uWUmBtD.aKGakZZvt nImCDPzgKWRTbj.2YynuRltqahoB7l17yMbofMzKWgZiN3sYPAjXRJtoQ1GH c6Kmf0Bt5tn9jijRr.CMhietXUth.5i_X.1k11eF.DPXdb.zRvH09Xta8W8v X_fBA2dCyCU1D_k75d3Mf8SINYKeKnw13e7TzF9HD1IipLKBa0sYNu5oFw5E zw7zc4Vg- Received: from [50.58.7.243] by web111405.mail.gq1.yahoo.com via HTTP; Tue, 09 Aug 2011 11:15:58 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> Message-ID: <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> Date: Tue, 9 Aug 2011 11:15:58 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 18:15:33 -0000 =0A=0A>>> This draft does not describe source mobility and local routing.= =0A>>> What this draft says is that if MAG can coordinate appropriate=0A>>= > MRIB, PIM-SM on MAG can cooperate with local routing to deliver IP=0A>>>= multicast packets for mobile nodes.=0A>>> =0A>>> I guess the discussion = how to coordinate appropriate MRIB *for local=0A>>> routing* in PMIPv6 sho= uld be discussed in a separate draft, whose=0A>>> title would be "Localize= d multicast routing for PIM-SM capable=0A>>> PMIPv6". This draft work defi= nitively needs to refer to=0A>>> draft-ietf-netext-pmip-lr.=0A>>> I'm hap= py to work on this topic after our PMIPv6 extension draft=0A>>> becomes th= e WG draft (because that draft will be also referred).=0A>> =0A>> In my la= test discussion with Stig, Stig mentioned that PIM-SM=0A>> assumes that th= e source is directly connected. What do you think=0A>> about this?=0A> =0A= > Source is directly connected to what? MAG?=0A> If source is directly conn= ected to MAG, then the localized routing=0A> situation should be considered= , right?=0A=0AYes.=0ADirectly connected source to the MAG becomes a problem= for RFC 6224 for which probably there is no solution.=0A=0A> =0A> Let's se= e, except the case that a mobile node is a multicast source,=0A> our PMIPv6= extension solution works well, I think.=0A> But for that case, because HNP= is routed to LMA, all MN's traffic goes=0A> through LMA and then LMA forwa= rds the traffic to the downstream=0A> routers (e.g. MAG). This route causes= higher delay and congestion in=0A> the network and requires the localized = routing solution discussed as=0A> in draft-ietf-netext-pmip-lr.=0A=0ASource= mobility issue is a bit away from the current concerns.=0A=0Adraft-ietf-ne= text-pmip-lr is about LMA authorized=A0 routing by the MAG to other MAGs. = =0AIf the destination is one of the MNs downstream, MAG can send it directl= y as per RFC 5213.=0A=0ARegards,=0A=0ABehcet From seiljeon@gmail.com Tue Aug 9 22:47:50 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0425121F85FE for ; Tue, 9 Aug 2011 22:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u8HCR2ruDhQ for ; Tue, 9 Aug 2011 22:47:49 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2BBB21F85F2 for ; Tue, 9 Aug 2011 22:47:48 -0700 (PDT) Received: by qyk34 with SMTP id 34so2575660qyk.10 for ; Tue, 09 Aug 2011 22:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=7JDtugi/3/zheUR+6iDXSjqxy7R/S/wh/6h6KXu3QdE=; b=KcgzZSVoX10cPt6BXsl45ySDA5lW47rElbvyegyLqzz1GzSg163Fg4hmQDKtR5qR3B dE31Sm3Kt2taXgRRhcG46eqJh0/9aqOq8KGDAM28IAJAPnGsW4N9qcjWiVaYJljCYqGV zuqFwKWoRE6+YSMWoTFYzwyQcj+nwj/XzTIhg= MIME-Version: 1.0 Received: by 10.229.8.138 with SMTP id h10mr5737360qch.105.1312955299179; Tue, 09 Aug 2011 22:48:19 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.229.250.77 with HTTP; Tue, 9 Aug 2011 22:48:18 -0700 (PDT) In-Reply-To: <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> References: <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> Date: Wed, 10 Aug 2011 14:48:18 +0900 X-Google-Sender-Auth: GgW3eubo9zWsI0Af80w3xQBd16c Message-ID: From: seil jeon To: Hitoshi Asaeda , Behcet Sarikaya Content-Type: multipart/alternative; boundary=0015176f0d7036ad4e04aa203a03 Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 05:47:50 -0000 --0015176f0d7036ad4e04aa203a03 Content-Type: text/plain; charset=ISO-8859-1 Hi Behcet and Hitoshi, Please see the below. 2011/8/10 Behcet Sarikaya > > > >>> This draft does not describe source mobility and local routing. > >>> What this draft says is that if MAG can coordinate appropriate > >>> MRIB, PIM-SM on MAG can cooperate with local routing to deliver IP > >>> multicast packets for mobile nodes. > >>> > >>> I guess the discussion how to coordinate appropriate MRIB *for local > >>> routing* in PMIPv6 should be discussed in a separate draft, whose > >>> title would be "Localized multicast routing for PIM-SM capable > >>> PMIPv6". This draft work definitively needs to refer to > >>> draft-ietf-netext-pmip-lr. > >>> I'm happy to work on this topic after our PMIPv6 extension draft > >>> becomes the WG draft (because that draft will be also referred). > >> > >> In my latest discussion with Stig, Stig mentioned that PIM-SM > >> assumes that the source is directly connected. What do you think > >> about this? > > > > Source is directly connected to what? MAG? > > If source is directly connected to MAG, then the localized routing > > situation should be considered, right? > > Yes. > Directly connected source to the MAG becomes a problem for RFC 6224 for > which probably there is no solution. > > Our "Direct/Local Routing" technique is well-suited for this case. In particular, our solution includes the case that MR is integrated together with MAG as we presented the description and slide in Quebec meeting. > > > > Let's see, except the case that a mobile node is a multicast source, > > our PMIPv6 extension solution works well, I think. > > But for that case, because HNP is routed to LMA, all MN's traffic goes > > through LMA and then LMA forwards the traffic to the downstream > > routers (e.g. MAG). This route causes higher delay and congestion in > > the network and requires the localized routing solution discussed as > > in draft-ietf-netext-pmip-lr. > > Source mobility issue is a bit away from the current concerns. > > draft-ietf-netext-pmip-lr is about LMA authorized routing by the MAG to > other MAGs. > If the destination is one of the MNs downstream, MAG can send it directly > as per RFC 5213. > > I aggre with Behcet's opinion. I think we're discussing which is appropriate solution to solve tunnel convergence problem derived from "Base Solution" of PMIPv6 multicasting. I believe that topic may be covered in the slot of source mobility. Your regards, Seil Jeon --0015176f0d7036ad4e04aa203a03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Behcet and Hitoshi,
=A0
Please see the below.

2011/8/10 Behcet Sarikaya <= behcetsarikaya@yahoo.com>= ;


>>> =A0This draft does not describe sour= ce mobility and local routing.
>>> =A0What this draft says is t= hat if MAG can coordinate appropriate
>>> =A0MRIB, PIM-SM on MA= G can cooperate with local routing to deliver IP
>>> =A0multicast packets for mobile nodes.
>>>
>= >> =A0I guess the discussion how to coordinate appropriate MRIB *for = local
>>> =A0routing* in PMIPv6 should be discussed in a separa= te draft, whose
>>> =A0title would be "Localized multicast routing for PIM-SM= capable
>>> =A0PMIPv6". This draft work definitively need= s to refer to
>>> =A0draft-ietf-netext-pmip-lr.
>>>= =A0I'm happy to work on this topic after our PMIPv6 extension draft >>> =A0becomes the WG draft (because that draft will be also refer= red).
>>
>> =A0In my latest discussion with Stig, Stig me= ntioned that PIM-SM
>> =A0assumes that the source is directly conn= ected. What do you think
>> =A0about this?
>
> Source is directly connected to wha= t? MAG?
> If source is directly connected to MAG, then the localized = routing
> situation should be considered, right?

Yes. Directly connected source to the MAG becomes a problem for RFC 6224 for whi= ch probably there is no solution.

=A0
=A0
Our "Direct/Local Routing" technique is well-suited for this= case. In particular, our solution includes the case that MR is integrated = together with MAG as we presented the description and slide in Quebec meeti= ng.
=A0
>
> Let's see, except the case that a mobile= node is a multicast source,
> our PMIPv6 extension solution works we= ll, I think.
> But for that case, because HNP is routed to LMA, all M= N's traffic goes
> through LMA and then LMA forwards the traffic to the downstream
>= ; routers (e.g. MAG). This route causes higher delay and congestion in
&= gt; the network and requires the localized routing solution discussed as > in draft-ietf-netext-pmip-lr.

Source mobility issue is a = bit away from the current concerns.

draft-ietf-netext-pmip-lr is abo= ut LMA authorized=A0 routing by the MAG to other MAGs.
If the destinatio= n is one of the MNs downstream, MAG can send it directly as per RFC 5213.
=A0
I aggre with Behcet's opinion. I think we're discussing which = is appropriate solution to solve tunnel convergence problem derived from &q= uot;Base Solution" of PMIPv6 multicasting. I believe that topic may be= covered in the slot of source mobility.
=A0
=A0
Your regards,
=A0
Seil Jeon
--0015176f0d7036ad4e04aa203a03-- From asaeda@sfc.wide.ad.jp Wed Aug 10 01:50:23 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAE321F876A for ; Wed, 10 Aug 2011 01:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+3tbRA5SSJk for ; Wed, 10 Aug 2011 01:50:23 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id D25B921F8779 for ; Wed, 10 Aug 2011 01:50:22 -0700 (PDT) Received: from localhost (p3151-ipngn1501hodogaya.kanagawa.ocn.ne.jp [114.166.86.151]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 45FBD278067; Wed, 10 Aug 2011 17:50:20 +0900 (JST) Date: Wed, 10 Aug 2011 17:50:19 +0900 (JST) Message-Id: <20110810.175019.203910949.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> References: <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 08:50:23 -0000 >> Let's see, except the case that a mobile node is a multicast source,= >> our PMIPv6 extension solution works well, I think. >> But for that case, because HNP is routed to LMA, all MN's traffic go= es >> through LMA and then LMA forwards the traffic to the downstream >> routers (e.g. MAG). This route causes higher delay and congestion in= >> the network and requires the localized routing solution discussed as= >> in draft-ietf-netext-pmip-lr. > = > Source mobility issue is a bit away from the current concerns. Right. I only reply your question; "so-called local routing", "how to connect the multicast source to the MAG as PIM-SM router?" Once again, I said; 1. our PMIPv6 extension draft does not describe localozed routing and source mobility (while our solution has good affinity with these functions, I believe) 2. if there is the request for localized routing and source mobility with our approach, I will work for providing the corresponding new document for localized routing along with our current solution. (but if not, I won't do for it at the current stage.) > draft-ietf-netext-pmip-lr is about LMA authorized=A0 routing by the > MAG to other MAGs. = > If the destination is one of the MNs downstream, MAG can send it > directly as per RFC 5213. I don't think RFC5213 provides the complete localized routing function; it only mentions "the mobile access gateway MAY optimize on the delivery efforts by locally routing the packets and by not reverse tunneling them to the mobile node's local mobility anchor." According to RFC6279 (problem statement) and draft-ietf-netext-pmip-lr,= = four scenarios for localized routing should be considered; A11: Two MNs attached to the same MAG and LMA, A12: Two MNs attached to different MAGs but same LMA, A21: Two MNs attached to the same MAG with different LMAs, and A22: Two MNs attached to the different MAGs with different LMAs. In fact, RFC5213 describes EnableMAGLocalRouting flag, which could become a localized routing handler. However, this flag only supports A11 case *potentially*. (*Potentially* means, as said above, RFC5213 does not mention the detail procedure even for A11.) This is the reason that if our solution that inherits RFC5213 as the PMIPv6 base spec needs to support localized routing (i.e. A11 to A22), it is necessary to provide a new document ("Localized multicast routing= for PIM-SM capable PMIPv6") or put a major section describing localized= routing in our current draft. (I think the latter is not a good idea, though.) Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Wed Aug 10 08:34:53 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FA221F863C for ; Wed, 10 Aug 2011 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe0uPMDvUIcJ for ; Wed, 10 Aug 2011 08:34:53 -0700 (PDT) Received: from nm26-vm0.bullet.mail.sp2.yahoo.com (nm26-vm0.bullet.mail.sp2.yahoo.com [98.139.91.230]) by ietfa.amsl.com (Postfix) with SMTP id 5AB5521F8634 for ; Wed, 10 Aug 2011 08:34:53 -0700 (PDT) Received: from [98.139.91.70] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 15:35:25 -0000 Received: from [98.139.91.10] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 15:35:25 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 15:35:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 369980.29627.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 15122 invoked by uid 60001); 10 Aug 2011 15:35:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312990524; bh=0iy2uzdoQLAbe0fWORB8ps1iLOZ3w8w8xZbh45hnWr4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jQ3n2OeEP+yUSK8eS5zZjPjUYLGDFM5SqFaWKyboZrQIoayzV9AfQxDE/PZNiJ6rEjoBlvKIjpi0qhXeCStvGRcWGl846KXPDev0V2x0/nSkw8MvA3HDFHffrN77ZF6itouU2dwuimpSywYDxM/p44M+RbVV4iZf7Wsinkw6GiU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6lOyi+oIPOG3mdZVZ/ZJofQ/o9J25r+9mnmoBDYRwvvvJO+nv/ydliNUYnckenpOtrzgU3bzjErbfKS+VjFwh/jihjnUNnShPCyhOpANgwosZNWz8s474+D7LeM9cZv82nV3QaG2bR7akmknXC/S+RJ7V3wDSo2aRe/CFMJ7cFs=; X-YMail-OSG: 85HDdlgVM1k_zSYdyHHhQfOnHeDlJHmAaeCS.cdgNdVdXCH xJf7gGB72jjW97lMlApu5J4vuAZgs2PSQzAnzj0dpK9N7ps1ib1WuJe9Wieq 8puZD3l4RnQpLLdssbzd901E7VPffwDgGEBDZSVCB8iB52yYqv2RXiXf2FXB On3.WQvQFmD6VXl3jlTTYixqHc0OYj9bRMu_mWcFyvmOesCdTwTfH8WfiS8u a7nMxW8bmCiPGC21NrnInTdxnU_sKqnbhtUW0PMMP13fOd_HOcOUDPdVqetq ISQXUks57VptxbLYT.tnV0gpQhAY506dZQwYeNGBo6GPXzVIHozaR8.r70EA gmxYPmk4bN5dgTkMmix0l5bY2NSz4EaKGrYKEbeVLDZDsNsMlgupd.VqN2yc kwgyHJbCx07heKcAIHFzAvVyLbBk.qQtVq9k3Gsas7XwphBsaMSUEWbNRGDb _VDZz53s- Received: from [50.58.7.243] by web111407.mail.gq1.yahoo.com via HTTP; Wed, 10 Aug 2011 08:35:24 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> Message-ID: <1312990524.3468.YahooMailNeo@web111407.mail.gq1.yahoo.com> Date: Wed, 10 Aug 2011 08:35:24 -0700 (PDT) From: Behcet Sarikaya To: seil jeon , Hitoshi Asaeda In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 15:34:53 -0000 Hi Seil,=0A=A0 Yes, if you integrate MR with MAG, "local routing" would wor= k. =0A=0AI think that for PIM-SM at the MAG, MR should be directly connecte= d.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A>=0A>Hi Behcet and Hitoshi,=0A>=A0=0A>= Please see the below.=0A>=0A>=0A>2011/8/10 Behcet Sarikaya =0A>=0A>=0A>>=0A>>>>> =A0This draft does not describe source mobi= lity and local routing.=0A>>>>> =A0What this draft says is that if MAG can = coordinate appropriate=0A>>>>> =A0MRIB, PIM-SM on MAG can cooperate with lo= cal routing to deliver IP=0A>>>>> =A0multicast packets for mobile nodes.=0A= >>>>>=0A>>>>> =A0I guess the discussion how to coordinate appropriate MRIB = *for local=0A>>>>> =A0routing* in PMIPv6 should be discussed in a separate = draft, whose=0A>>>>> =A0title would be "Localized multicast routing for PIM= -SM capable=0A>>>>> =A0PMIPv6". This draft work definitively needs to refer= to=0A>>>>> =A0draft-ietf-netext-pmip-lr.=0A>>>>> =A0I'm happy to work on t= his topic after our PMIPv6 extension draft=0A>>>>> =A0becomes the WG draft = (because that draft will be also referred).=0A>>>>=0A>>>> =A0In my latest d= iscussion with Stig, Stig mentioned that PIM-SM=0A>>>> =A0assumes that the = source is directly connected. What do you think=0A>>>> =A0about this?=0A>>>= =0A>>> Source is directly connected to what? MAG?=0A>>> If source is direct= ly connected to MAG, then the localized routing=0A>>> situation should be c= onsidered, right?=0A>>=0A>>Yes.=0A>>Directly connected source to the MAG be= comes a problem for RFC 6224 for which probably there is no solution.=0A>>= =0A>>=0A>>=0A>=A0=0A>=A0=0A>Our "Direct/Local Routing" technique is well-su= ited for this case. In particular, our solution includes the case that MR i= s integrated together with MAG as we presented the description and slide in= Quebec meeting.=0A>=A0=0A>>=0A>>> Let's see, except the case that a mobile= node is a multicast source,=0A>>> our PMIPv6 extension solution works well= , I think.=0A>>> But for that case, because HNP is routed to LMA, all MN's = traffic goes=0A>>> through LMA and then LMA forwards the traffic to the dow= nstream=0A>>> routers (e.g. MAG). This route causes higher delay and conges= tion in=0A>>> the network and requires the localized routing solution discu= ssed as=0A>>> in draft-ietf-netext-pmip-lr.=0A>>=0A>>Source mobility issue = is a bit away from the current concerns.=0A>>=0A>>draft-ietf-netext-pmip-lr= is about LMA authorized=A0 routing by the MAG to other MAGs.=0A>>If the de= stination is one of the MNs downstream, MAG can send it directly as per RFC= 5213.=0A>>=0A>>=0A>=A0=0A>I aggre with Behcet's opinion. I think we're dis= cussing which is appropriate solution to solve tunnel convergence problem d= erived from "Base Solution" of PMIPv6 multicasting. I believe that topic ma= y be covered in the slot of source mobility.=0A>=A0=0A>=A0=0A>Your regards,= =0A>=A0=0A>Seil Jeon=0A>=0A> From behcetsarikaya@yahoo.com Wed Aug 10 08:52:32 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F6B21F87D6 for ; Wed, 10 Aug 2011 08:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpEXnrKMvdjd for ; Wed, 10 Aug 2011 08:52:32 -0700 (PDT) Received: from nm12-vm0.bullet.mail.sp2.yahoo.com (nm12-vm0.bullet.mail.sp2.yahoo.com [98.139.91.242]) by ietfa.amsl.com (Postfix) with SMTP id 598CD21F87C7 for ; Wed, 10 Aug 2011 08:52:32 -0700 (PDT) Received: from [98.139.91.69] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 15:53:04 -0000 Received: from [98.139.91.47] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 15:53:04 -0000 Received: from [127.0.0.1] by omp1047.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 15:53:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 412010.87206.bm@omp1047.mail.sp2.yahoo.com Received: (qmail 95202 invoked by uid 60001); 10 Aug 2011 15:53:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312991584; bh=l0rSuuxby8LhHMlA0ru8/LSFTumybPvcp+H/G7U+Mf0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u1SxuNzvV9o6KHJrqFx/GRf2Jl/vRU05LbnHbSJ8YJPcIBca8hVWrYZXY41bQhBWztmq6TLR7c85MplOaCjLxROi5FguLY3HrdoDganuqRyZSAlclqykdiQMACprFPulF/Cllw+FNbj63usO/guR0/wi6ZSo9aoyRMuf4edR+OM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nlazHK+8Fxm/R2lxjIoI9Zc2UEKAMCyZSNx1LtDfGH270dQGh2VC3MUkKn6iodtPaVIBtxnX4BLkfgr+CVNwoYng9uZG4g8BZ0fHexG3hF16LswAYWy8VJ8VOKnicR4A8ZZJnysroqPTkyDuRzHroMZtUAF6FAao1TDKKnhomBw=; X-YMail-OSG: q2k.eN8VM1mEKC15xEangpRv7fLzkHjYkTc22ZD4uYaaPfa W57Xgb2IPwaKjDWpTBW92HtbM_yYz1xFLnXg8Pxl3axzj2UJrzLhLZD2KcFC EOVm7JfJ.xG2HqaKM4FwkhmRQxLLlnwR7d1NwMKcfwW0crLi9c7zZq5nRzjN RAlukS7raO3a043JpbzIjxIb.knsW5fh.5m1DEwWRvF1yx0Rl2BS.KXigiT3 DMy9XOT1koz5Lw61_4Gv4ujXiyEYTjFGocIImQV8PdKxY5YaK_NZVVOaKIsI y5WHy7KNgtp3kjhyruUFJNrYdxiMzTp6oKLq0vAauGrQXnXPphugIdzM_8Vq u2dLtijrwuCgubdrwrupoDJUYJOxe7Pcr8bg_cOWxBnNBqQEgSMj5Dlx.mDr cOs6pVvY1O_xQ7oDtpPU0ZNOOm0TMqi9n_CC2B8JaWf1Ex994Uwk1wL7_04_ rjq0BR30- Received: from [50.58.7.243] by web111414.mail.gq1.yahoo.com via HTTP; Wed, 10 Aug 2011 08:53:03 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> <20110810.175019.203910949.asaeda@sfc.wide.ad.jp> Message-ID: <1312991583.83907.YahooMailNeo@web111414.mail.gq1.yahoo.com> Date: Wed, 10 Aug 2011 08:53:03 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110810.175019.203910949.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 15:52:33 -0000 Hi Hitoshi,=0A=A0 It seems like you are confused about the local routing. I= meant in the sense of locally routing the multicast traffic, not unicast. = Basically it is referring to Seil's draft.=0A=0AWhat you are referring to b= elow is probably in the context of source mobility. My suggestion is to tak= e a look at the solution draft. PS draft has more scenarios and solution do= cument addressed only some of the scenarios. Checking Shuai's draft might b= e helpful.=0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A>>> Let's see, except t= he case that a mobile node is a multicast =0A> source,=0A>>> our PMIPv6 ex= tension solution works well, I think.=0A>>> But for that case, because HNP= is routed to LMA, all MN's traffic =0A> goes=0A>>> through LMA and then L= MA forwards the traffic to the downstream=0A>>> routers (e.g. MAG). This r= oute causes higher delay and congestion in=0A>>> the network and requires = the localized routing solution discussed as=0A>>> in draft-ietf-netext-pmi= p-lr.=0A>> =0A>> Source mobility issue is a bit away from the current conc= erns.=0A> =0A> Right.=0A> I only reply your question; "so-called local rout= ing", "how to =0A> connect=0A> the multicast source to the MAG as PIM-SM ro= uter?"=0A> =0A> Once again, I said;=0A> =0A> 1. our PMIPv6 extension draft = does not describe localozed routing and=0A> =A0 source mobility (while our= solution has good affinity with these=0A> =A0 functions, I believe)=0A> 2= . if there is the request for localized routing and source mobility=0A> =A0= with our approach, I will work for providing the corresponding new=0A> = =A0 document for localized routing along with our current solution.=0A> = =A0 (but if not, I won't do for it at the current stage.)=0A> =0A>> draft= -ietf-netext-pmip-lr is about LMA authorized=A0 routing by the=0A>> =A0 MAG= to other MAGs. =0A>> If the destination is one of the MNs downstream, MAG= can send it=0A>> =A0 directly as per RFC 5213.=0A> =0A> I don't think RFC5= 213 provides the complete localized routing=0A> function; it only mentions = "the mobile access gateway MAY optimize on=0A> the delivery efforts by loca= lly routing the packets and by not reverse=0A> tunneling them to the mobile= node's local mobility anchor."=0A> =0A> According to RFC6279 (problem stat= ement) and draft-ietf-netext-pmip-lr, =0A> four scenarios for localized rou= ting should be considered; A11: Two=0A> MNs attached to the same MAG and LM= A, A12: Two MNs attached to=0A> different MAGs but same LMA, A21: Two MNs a= ttached to the same MAG=0A> with different LMAs, and A22: Two MNs attached = to the different MAGs=0A> with different LMAs.=0A> In fact, RFC5213 describ= es EnableMAGLocalRouting flag, which could=0A> become a localized routing h= andler. However, this flag only supports=0A> A11 case *potentially*. (*Pote= ntially* means, as said above, RFC5213=0A> does not mention the detail proc= edure even for A11.)=0A> =0A> This is the reason that if our solution that = inherits RFC5213 as the=0A> PMIPv6 base spec needs to support localized rou= ting (i.e. A11 to A22),=0A> it is necessary to provide a new document ("Loc= alized multicast routing=0A> for PIM-SM capable PMIPv6") or put a major sec= tion describing localized=0A> routing in our current draft.=0A> (I think th= e latter is not a good idea, though.)=0A> =0A> Regards,=0A> --=0A> Hitoshi = Asaeda=0A> From asaeda@sfc.wide.ad.jp Wed Aug 10 09:33:55 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0856421F898E for ; Wed, 10 Aug 2011 09:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GT4JdoLwTAB for ; Wed, 10 Aug 2011 09:33:54 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD4921F893C for ; Wed, 10 Aug 2011 09:33:51 -0700 (PDT) Received: from localhost (p3151-ipngn1501hodogaya.kanagawa.ocn.ne.jp [114.166.86.151]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4B004278097; Thu, 11 Aug 2011 01:33:52 +0900 (JST) Date: Thu, 11 Aug 2011 01:33:52 +0900 (JST) Message-Id: <20110811.013352.111667313.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <1312991583.83907.YahooMailNeo@web111414.mail.gq1.yahoo.com> References: <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> <20110810.175019.203910949.asaeda@sfc.wide.ad.jp> <1312991583.83907.YahooMailNeo@web111414.mail.gq1.yahoo.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 16:33:55 -0000 Behcet, > =A0 It seems like you are confused about the local routing. I meant i= n > the sense of locally routing the multicast traffic, not > unicast. Basically it is referring to Seil's draft. See section 6.10.3 of RFC5213. It mentions "Local Routing". And also, please check RFC6279. The document title is "PMIPv6 Localized= Routing PS". These RFCs clearly define the local (or localized) routing (and draft-ietf-netext-pmip-lr tries to provide the solution). It seems Seil wants to discuss "direct routing", in which MAG communicates with MR located in PMIPv6 domain without LMA's interaction. Don't you and Seil mix local routing and direct routing? BTW, what does "in the sense of locally routing the multicast traffic, not unicast." mean? I cannot understand this statement. > What you are referring to below is probably in the context of source > mobility. My suggestion is to take a look at the solution draft. PS > draft has more scenarios and solution document addressed only some > of the scenarios. Checking Shuai's draft might be helpful. Source mobility in PMIPv6 means the way to support that a source mobile node moves from p-MAG to n-MAG. Source mobility requires PMIPv6 to support localized routing and needs to discuss how sourced contents could be seamlessly served to listener MNs during handover. Localized routing is the core function of source mobility. This is my understanding. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Wed Aug 10 09:57:15 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4907B21F84DC for ; Wed, 10 Aug 2011 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NopcPyQ7RWhI for ; Wed, 10 Aug 2011 09:57:14 -0700 (PDT) Received: from nm21-vm0.bullet.mail.sp2.yahoo.com (nm21-vm0.bullet.mail.sp2.yahoo.com [98.139.91.220]) by ietfa.amsl.com (Postfix) with SMTP id C4D3D21F84D5 for ; Wed, 10 Aug 2011 09:57:14 -0700 (PDT) Received: from [98.139.91.66] by nm21.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 16:57:39 -0000 Received: from [98.139.91.5] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 16:57:39 -0000 Received: from [127.0.0.1] by omp1005.mail.sp2.yahoo.com with NNFMP; 10 Aug 2011 16:57:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 315514.52366.bm@omp1005.mail.sp2.yahoo.com Received: (qmail 56417 invoked by uid 60001); 10 Aug 2011 16:57:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312995458; bh=VEn4NfvskbqhGR24bdlLQguv/UukOGO0j4rUosiE7fQ=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Bt6stmmZk/r9gw0hgSNUvqk0YZhzFdr9x0fKBNKfCCuvmZfaQa0Yjp9SqRweANlaQi2bUhd1BOAlKbjKbit9/25UTiEzA7ctP1NOeSYTtWxP0k+ZM0T+o4tbLVbXcl0FduCcwGbuV2ygHcLvrKVWlKK5PRVDm9FDmfYQJ9G1S4Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4R+EsAbExkbuMXkMiVgkFIQ64wdDuOWUFkk4V1ge/g8qDF9JTwkgK4LeuKVz2ct1TjxTuCUUsiG7WuUZ12iXLk3QshURkRkhak/HAPGAGgFxqIMF1R06JGpP+cJoQ7yN1ypC2tkQNqGLoXqvbjuGF3MxI+tVsCb/EBuJP/c7vvo=; X-YMail-OSG: A.8RVlEVM1liWMffWQ9QlikAhkEPBe5K6VZ8IqdDwSVaYCg EeZn_l2LdvzGIZlNeb7GBj3vxfHmakI4de9IKRZCc.2cSEz6d7NEOPbUsReQ LNgXbDJuYz2IYUJvgXXM6aNckPLcjjEKNIYI1QpwbolHH5GJA.AeHpWIk1CJ XjQz5uPlUUHxqrbAiVl_QaxHqeYtyDceY2SRlcoKIwYMOI8PEG.ggf5izhUG EM_ReJOcJJ.UNdA80bhQuGPXWdSOxI3KwpYeOs..3ymHyXO7Zr4OlXfUCKGZ UEQQorroU1vUt5WZrMFv7UBEF8Xk0iyv1.9_OVf5ZYslJ_WWw0T3P5Dg9T8U 1cbuu6vr5cV7oGAazIDai1clc5wg.uda5nb0Fr75_8QJkXqPBgqjsmZ2BH6b Cx72cRQQuIkVC.ligwJhmuFd8RrI37zXhIp.5mgm4t2o9pmP_6vPorGGdETp oA_uIbq0- Received: from [50.58.7.243] by web111407.mail.gq1.yahoo.com via HTTP; Wed, 10 Aug 2011 09:57:38 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> <20110810.175019.203910949.asaeda@sfc.wide.ad.jp> <1312991583.83907.YahooMailNeo@web111414.mail.gq1.yahoo.com> <20110811.013352.111667313.asaeda@sfc.wide.ad.jp> Message-ID: <1312995458.55690.YahooMailNeo@web111407.mail.gq1.yahoo.com> Date: Wed, 10 Aug 2011 09:57:38 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , "sarikaya@ieee.org" In-Reply-To: <20110811.013352.111667313.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 16:57:15 -0000 =0A=0A=0A=0A> Behcet,=0A> =0A>> =A0 It seems like you are confused about t= he local routing. I meant in=0A>> the sense of locally routing the multica= st traffic, not=0A>> unicast. Basically it is referring to Seil's draft.= =0A> =0A> See section 6.10.3 of RFC5213. It mentions "Local Routing".=0A> A= nd also, please check RFC6279. The document title is "PMIPv6 Localized=0A> = Routing PS".=0A> These RFCs clearly define the local (or localized) routing= (and=0A> draft-ietf-netext-pmip-lr tries to provide the solution).=0A> =0A= > It seems Seil wants to discuss "direct routing", in which MAG=0A> communi= cates with MR located in PMIPv6 domain without LMA's=0A> interaction.=0A> D= on't you and Seil mix local routing and direct routing?=0A=0AMaybe you are = right, it should be called direct routing. I used to call it locally availa= ble multicast.=0ALocal routing is PMIPv6 term referring to the unicast rout= ing.=0A=0A> =0A> BTW, what does "in the sense of locally routing the multic= ast traffic,=0A> not unicast." mean? I cannot understand this statement.=0A= =0APMIPv6 documents you mentioned above are about unicast routing. =0AWhat = I was talking about is locally available multicast.=0A=0A> =0A>> What you = are referring to below is probably in the context of source=0A>> mobility.= My suggestion is to take a look at the solution draft. PS=0A>> draft has = more scenarios and solution document addressed only some=0A>> of the scena= rios. Checking Shuai's draft might be helpful.=0A> =0A> Source mobility in = PMIPv6 means the way to support that a source=0A> mobile node moves from p-= MAG to n-MAG. Source mobility requires PMIPv6=0A> to support localized rout= ing and needs to discuss how sourced contents=0A> could be seamlessly serve= d to listener MNs during handover.=0A> Localized routing is the core functi= on of source mobility.=0A> =0A=0A=0ANo. =0A=0ASource mobility is MN is mult= icast source and of course MN maybe moving.=0A=0AThis is the subject of Shu= ai and Thomas drafts.=0A=0AIs everything clear now?=0A=0A=0ARegards,=0A=0AB= ehcet=0A From asaeda@sfc.wide.ad.jp Wed Aug 10 10:24:12 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C5121F8661 for ; Wed, 10 Aug 2011 10:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9jAlhW7a3DZ for ; Wed, 10 Aug 2011 10:24:12 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 40B0C21F865F for ; Wed, 10 Aug 2011 10:24:11 -0700 (PDT) Received: from localhost (p3151-ipngn1501hodogaya.kanagawa.ocn.ne.jp [114.166.86.151]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BCF7C278091; Thu, 11 Aug 2011 02:24:12 +0900 (JST) Date: Thu, 11 Aug 2011 02:24:11 +0900 (JST) Message-Id: <20110811.022411.171031393.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <1312995458.55690.YahooMailNeo@web111407.mail.gq1.yahoo.com> References: <1312991583.83907.YahooMailNeo@web111414.mail.gq1.yahoo.com> <20110811.013352.111667313.asaeda@sfc.wide.ad.jp> <1312995458.55690.YahooMailNeo@web111407.mail.gq1.yahoo.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 17:24:12 -0000 > Maybe you are right, it should be called direct routing. I used to > call it locally available multicast. > Local routing is PMIPv6 term referring to the unicast routing. Ok, slightly agreed. But local routing is also appricable for multicast in the same concept. >> BTW, what does "in the sense of locally routing the multicast traffic, >> not unicast." mean? I cannot understand this statement. > > PMIPv6 documents you mentioned above are about unicast routing. Of course. Because RFC5213 does not mention multicast. But the same terminology and concept for localized routing are used for multicast. So, my comment is for both unicast and multicast. > What I was talking about is locally available multicast. What is "locally available multicast"? Who is the source? If the source is MN attached to MAG, then localized routing should be considered. If the source is not MN, then our current draft works well. >>> What you are referring to below is probably in the context of source >>> mobility. My suggestion is to take a look at the solution draft. PS >>> draft has more scenarios and solution document addressed only some >>> of the scenarios. Checking Shuai's draft might be helpful. >> >> Source mobility in PMIPv6 means the way to support that a source >> mobile node moves from p-MAG to n-MAG. Source mobility requires PMIPv6 >> to support localized routing and needs to discuss how sourced contents >> could be seamlessly served to listener MNs during handover. >> Localized routing is the core function of source mobility. > > No. Why No? :) > Source mobility is MN is multicast source and of course MN maybe moving. I said the same thing above (with more explanation). > This is the subject of Shuai and Thomas drafts. > > Is everything clear now? Sorry, maybe I'm not clear your thought. I copy my last mail here: > Once again, I said; > > 1. our PMIPv6 extension draft does not describe localozed routing and > source mobility (while our solution has good affinity with these > functions, I believe) > 2. if there is the request for localized routing and source mobility > with our approach, I will work for providing the corresponding new > document for localized routing along with our current solution. > (but if not, I won't do for it at the current stage.) What is the problem for you? What do you ask for our draft? Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Wed Aug 10 11:36:09 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7762D21F8ACA for ; Wed, 10 Aug 2011 11:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXYTZWcmFR3f for ; Wed, 10 Aug 2011 11:36:09 -0700 (PDT) Received: from nm15-vm3.bullet.mail.ne1.yahoo.com (nm15-vm3.bullet.mail.ne1.yahoo.com [98.138.91.145]) by ietfa.amsl.com (Postfix) with SMTP id D4DB421F8AB8 for ; Wed, 10 Aug 2011 11:36:05 -0700 (PDT) Received: from [98.138.90.52] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 18:34:58 -0000 Received: from [98.138.89.234] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 18:34:58 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 18:34:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 577966.5609.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 69151 invoked by uid 60001); 10 Aug 2011 18:34:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313001297; bh=ajwl0pUxeo25nyD0ChMo2AjJ57HoJlOmT9dXtBhiQQI=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=atJsEzUKD44bne5ZMLkskc5rv6yEt12gO0eWmw6OsgB5PUoYEb29nGO2HEdj1HernZe7rNiX1ET7hbohPUrJCGz5I60nt24tLcCSEY5hvbZAT0vHhe8xvfxKJU46IRSiXmN7cSzHxw4tHeXMhT3GHU1W/PPFRGQt3rQjqiV/ekc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=peHoLKUDxMNj3RWZQkVT4wNz4mDqUEBIDquNaC7EZEJn2k3VYIUqnCsDfmNmQ5qoPzZK5fuIy8RmC+KYDUU11ydZxaP/ISKCtFcVKLHVBA6rLHJN3nr4RMthKD5rNBHaxeuNS9ePH5ezAzLbScJk7zu5zEM5jDKg0jY9NB5kmik=; X-YMail-OSG: pnhyohMVM1mgKhWmfT3DxNluGyC86vZSruT2cHMi4LdUUUm MwsX1hMiQHpdRLvG7qb9iZ_4tGLKDrU1B45VmEhWt6bfIBC6y_zrvSeh8M4d zLOZv8g65sSMx0H6nVm.Vc17vcC9ofz4a6JfS0l6T3VYTIbcUQHnUvgMhW7t IfJA1rUbgpr9ErWPYBaAFEdkGOz8lFqAf4dUwA8CsqqcrXwNQ1tTReRluhHR Ch3hmQHhSWoId0gTcH2UfMYqGiWs1MruhtTvArrdYzqA..THfnNoDfcrJakb Gn3hYDrQuVDU2AJIlAJPVAkelzU4P_bENEWJltNnVbiAMirdwpvw.gxgrlfj Gb7kAU0_0xKQ6vNvF83NcNreEbmMBGEtgAZyPhdpoeQptWcakhYGeN1eM0MX NyGS0BrgeuwXw6LHG4A86RcdfayfoDEFSBLFPVer4ypn2HOzLgLOv2x8mDtG iiRZE64o- Received: from [50.58.7.243] by web111409.mail.gq1.yahoo.com via HTTP; Wed, 10 Aug 2011 11:34:57 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <1312991583.83907.YahooMailNeo@web111414.mail.gq1.yahoo.com> <20110811.013352.111667313.asaeda@sfc.wide.ad.jp> <1312995458.55690.YahooMailNeo@web111407.mail.gq1.yahoo.com> <20110811.022411.171031393.asaeda@sfc.wide.ad.jp> Message-ID: <1313001297.63288.YahooMailNeo@web111409.mail.gq1.yahoo.com> Date: Wed, 10 Aug 2011 11:34:57 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110811.022411.171031393.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 18:36:09 -0000 =0A=0A=0A=0A>> Maybe you are right, it should be called direct routing. I = used to=0A>> call it locally available multicast.=0A>> Local routing is P= MIPv6 term referring to the unicast routing.=0A> =0A> Ok, slightly agreed.= =0A> But local routing is also appricable for multicast in the same=0A> con= cept.=0A> =0A>>> BTW, what does "in the sense of locally routing the multi= cast =0A> traffic,=0A>>> not unicast." mean? I cannot understand this stat= ement.=0A>> =0A>> PMIPv6 documents you mentioned above are about unicast r= outing. =0A> =0A> Of course. Because RFC5213 does not mention multicast. Bu= t the same=0A> terminology and concept for localized routing are used for m= ulticast.=0A> So, my comment is for both unicast and multicast.=0A> =0A>> = What I was talking about is locally available multicast.=0A> =0A> What is "= locally available multicast"? Who is the source?=0A> If the source is MN at= tached to MAG, then localized routing should be=0A> considered.=0A=0ALocall= y available multicast means the source is in the access network, =0Amultica= st data is not coming from LMA. Or what you call direct routing. =0A=0AI ag= ree that it should not be called local routing, Seil please take note. Seil= also uses direct routing which is OK.=0A=0A> If the source is not MN, then= our current draft works well.=0A=0AI am not sure, it needs to be clarified= as to how it works. It seems like the source directly connected to MAG wil= l work.=0A=0A=0A=0A> =0A>>>> =A0 What you are referring to below is probabl= y in the context of =0A> source=0A>>>> =A0 mobility. My suggestion is to ta= ke a look at the solution draft. =0A> PS=0A>>>> =A0 draft has more scenario= s and solution document addressed only some=0A>>>> =A0 of the scenarios. Ch= ecking Shuai's draft might be helpful.=0A>>> =0A>>> Source mobility in PMI= Pv6 means the way to support that a source=0A>>> mobile node moves from p-= MAG to n-MAG. Source mobility requires PMIPv6=0A>>> to support localized r= outing and needs to discuss how sourced contents=0A>>> could be seamlessly= served to listener MNs during handover.=0A>>> Localized routing is the co= re function of source mobility.=0A>> =0A>> No. =0A> =0A> Why No? :)=0A> = =0A>> Source mobility is MN is multicast source and of course MN maybe mov= ing.=0A> =0A> I said the same thing above (with more explanation).=0A=0AWe = are in agreement then.=0A=0ARegards,=0A=0ABehcet=0A From behcetsarikaya@yahoo.com Wed Aug 10 16:04:41 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF58621F8BD7 for ; Wed, 10 Aug 2011 16:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxsvIqkr8dK2 for ; Wed, 10 Aug 2011 16:04:41 -0700 (PDT) Received: from nm7-vm4.bullet.mail.ne1.yahoo.com (nm7-vm4.bullet.mail.ne1.yahoo.com [98.138.91.167]) by ietfa.amsl.com (Postfix) with SMTP id 1FAD721F8B43 for ; Wed, 10 Aug 2011 16:04:40 -0700 (PDT) Received: from [98.138.90.56] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 23:05:13 -0000 Received: from [98.138.89.232] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 23:05:13 -0000 Received: from [127.0.0.1] by omp1047.mail.ne1.yahoo.com with NNFMP; 10 Aug 2011 23:05:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 375052.39854.bm@omp1047.mail.ne1.yahoo.com Received: (qmail 92511 invoked by uid 60001); 10 Aug 2011 23:05:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313017512; bh=Tu2Q4IY/nZ6XdhcEJgTA8ciVvOUj6m8a6ff3eDHtX3c=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=So5z/igJlwOdsQzro+Mn7OoItu85UPtO/7DlN7Az/Ix6h3lApn23zJKvXjLOijZyzwQSp0EsLHqnx1UwJrDntNf18gufvTcuoatLNktITYcGgp+X5UfY0qasYyVPkn5iM3kfk2HmQVPfLcH8x3RruXSjDo7o2071lhVHhAytqzs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xfLtYIql3WPR1gSzd9gyXS6At3A1t5/eSbRgE9bJn6Lt1alieJ4eRR/NnBGYmizgTFpXWh83/KvtIduMAXDxHhwYFvW6mD37BjK0RNmBpnUlcP6UbE9SVwnApfNskIuKYMQOw63AjbqYnPXg4lYSTrpKcD7topmJD2tUllteaBw=; X-YMail-OSG: n7XVLisVM1mc23n66RLWTbSsl8sXS1DAUT27HXo_CXXQW3C S70F6vKLwJ2NokxCYWqzp2c8hCJplVKCoOXVgxJezmWHzT44d0P6dokZ34PE WEpSpfcWUF7YynlI66lWTecCzJEwXAqTJpM.x3ehd6eOVoNfDczd1lONf788 Y0saVIP..SmrPZ3z1DVSJzUomaMvNFoeQJYVbQpRFHwxF4KYYziGDFewCbLW quORWsNLsrVKlfCnIXCUVwDbdIuUss2grRzGLyuaAVBINxADMg5uuvYlg2gn MsEPkCRpKv_v6.GUN0u3OvNVfz1JB9ju6Ur_vK9hWHZdcijGo575NpceSY29 HjzclOIzB8uqGu6.qknVEYs8iVX1Hq1R_tPWv1oK212mX5et4b.RajtYElAA DuwgJK2nEOoE9b8qLGBpvYxc78oLMbbSyGESDFJupougjEF4CQ3Zx3HmLmJF .iPB_3g-- Received: from [50.58.7.243] by web111410.mail.gq1.yahoo.com via HTTP; Wed, 10 Aug 2011 16:05:12 PDT X-Mailer: YahooMailWebService/0.8.113.313619 Message-ID: <1313017512.90751.YahooMailNeo@web111410.mail.gq1.yahoo.com> Date: Wed, 10 Aug 2011 16:05:12 -0700 (PDT) From: Behcet Sarikaya To: "multimob@ietf.org" , Bill Atwood MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Minutes of IETF-81 session X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 23:04:41 -0000 Hi all,=0A=A0 As you remember, Bill Atwood had agreed to take the minutes. = But so far he has not provided me his notes, possibly due to the fact that = he is on vacation.=0A=0AIf any of you took the notes, please send them to m= e. We will try to construct some notes.=0A=0ARegards,=0A=0ABehcet=0A From seiljeon@gmail.com Thu Aug 11 00:07:01 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D265E8002 for ; Thu, 11 Aug 2011 00:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2t5SCfL-UAM for ; Thu, 11 Aug 2011 00:07:00 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A33321F84DC for ; Thu, 11 Aug 2011 00:07:00 -0700 (PDT) Received: by qwc23 with SMTP id 23so1182463qwc.31 for ; Thu, 11 Aug 2011 00:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=bOPTvP/Bp8spFkyDWEn1cj1zTaKSS28V0gW//sv7lZQ=; b=JTnAmJNv1cchuhlEyrCAoqEzIcyCLl68BOJv0k0Jef2Vex/a60RzL7siHC9+gwabhq SDQkhwZNrZ+jtAoPpWM6B0V15vc9M0yKV5QTDrGRV7rQ5wUHURA7vrqpNrBNTAlikKee yZYmnIa+4mv+VDjrn8n1BpaWXRsNIMsPmGeso= MIME-Version: 1.0 Received: by 10.229.118.78 with SMTP id u14mr7183742qcq.29.1313046453410; Thu, 11 Aug 2011 00:07:33 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.229.250.77 with HTTP; Thu, 11 Aug 2011 00:07:33 -0700 (PDT) In-Reply-To: <1313001297.63288.YahooMailNeo@web111409.mail.gq1.yahoo.com> References: <1312991583.83907.YahooMailNeo@web111414.mail.gq1.yahoo.com> <20110811.013352.111667313.asaeda@sfc.wide.ad.jp> <1312995458.55690.YahooMailNeo@web111407.mail.gq1.yahoo.com> <20110811.022411.171031393.asaeda@sfc.wide.ad.jp> <1313001297.63288.YahooMailNeo@web111409.mail.gq1.yahoo.com> Date: Thu, 11 Aug 2011 16:07:33 +0900 X-Google-Sender-Auth: 4qkY5Fqdz8gCiF5Win1-6wVuUFA Message-ID: From: seil jeon To: Hitoshi Asaeda , Behcet Sarikaya Content-Type: multipart/alternative; boundary=000e0cd5f4aa6dda6204aa35737f Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 07:07:01 -0000 --000e0cd5f4aa6dda6204aa35737f Content-Type: text/plain; charset=ISO-8859-1 Hi Behcet and Hitoshi, Please see the below. 2011/8/11 Behcet Sarikaya > > > > > >> Maybe you are right, it should be called direct routing. I used to > >> call it locally available multicast. > >> Local routing is PMIPv6 term referring to the unicast routing. > > > > Ok, slightly agreed. > > But local routing is also appricable for multicast in the same > > concept. > > > >>> BTW, what does "in the sense of locally routing the multicast > > traffic, > >>> not unicast." mean? I cannot understand this statement. > >> > >> PMIPv6 documents you mentioned above are about unicast routing. > > > > Of course. Because RFC5213 does not mention multicast. But the same > > terminology and concept for localized routing are used for multicast. > > So, my comment is for both unicast and multicast. > > > >> What I was talking about is locally available multicast. > > > > What is "locally available multicast"? Who is the source? > > If the source is MN attached to MAG, then localized routing should be > > considered. > > Locally available multicast means the source is in the access network, > multicast data is not coming from LMA. Or what you call direct routing. > > I agree that it should not be called local routing, Seil please take note. > Seil also uses direct routing which is OK. > > > If the source is not MN, then our current draft works well. > > I am not sure, it needs to be clarified as to how it works. It seems like > the source directly connected to MAG will work. > > According to the shared meaning through multimob discussion, I think Behcet is correct here. To avoid confusion of the meanings of direct routing and local routing, the definitions of two terms were given through my slide in Quebec meeting. (Of course, those were defined by me.) - Direct routing : multicast data is transmitted from a source to a MN using "Native Multicasting Infrastructure" within operator's network - Local routing : content source is directly connected a MAG. There's no need of multicast routing protocol to retrieve multicast data but MLD proxy function is needed on a MAG to exchange MLD signaling and multicast data between an MN and a source. When we follow the definition of local routing, there's actually no issue of "routing" because "routing" is not used in here. Somewhat "Local Content Delivery" may be much closer. Now, we call it "local routing" simply. For local contents delivery, it seems that there's no reason for the operators to provide the contents through the LMA but direct connection with a MAG is natural. Now, we go back the Behcet's original question. Behcet is asking your solution is feasible for local routing case or not.Isn't it, Behcet? > > > > >>>> What you are referring to below is probably in the context of > > source > >>>> mobility. My suggestion is to take a look at the solution draft. > > PS > >>>> draft has more scenarios and solution document addressed only some > >>>> of the scenarios. Checking Shuai's draft might be helpful. > >>> > >>> Source mobility in PMIPv6 means the way to support that a source > >>> mobile node moves from p-MAG to n-MAG. Source mobility requires PMIPv6 > >>> to support localized routing and needs to discuss how sourced contents > >>> could be seamlessly served to listener MNs during handover. > >>> Localized routing is the core function of source mobility. > >> > >> No. > > > > Why No? :) > > > >> Source mobility is MN is multicast source and of course MN maybe > moving. > > > > I said the same thing above (with more explanation). > > We are in agreement then. > > Regards, > > Behcet > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --000e0cd5f4aa6dda6204aa35737f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Behcet and Hitoshi,
=A0
Please see the below.

2011/8/11 Behcet Sarikaya <= behcetsarikaya@yahoo.com>= ;




>> =A0Maybe you are right, it shoul= d be called direct routing. I used to
>> =A0call it locally availa= ble multicast.
>> =A0Local routing is PMIPv6 term referring to the= unicast routing.
>
> Ok, slightly agreed.
> But local routing is also apprica= ble for multicast in the same
> concept.
>
>>> =A0B= TW, what does "in the sense of locally routing the multicast
> t= raffic,
>>> =A0not unicast." mean? I cannot understand this statement= .
>>
>> =A0PMIPv6 documents you mentioned above are about= unicast routing.
>
> Of course. Because RFC5213 does not menti= on multicast. But the same
> terminology and concept for localized routing are used for multicast.<= br>> So, my comment is for both unicast and multicast.
>
>&g= t; =A0What I was talking about is locally available multicast.
>
> What is "locally available multicast"? Who is the source?> If the source is MN attached to MAG, then localized routing should be=
> considered.

Locally available multicast means the sou= rce is in the access network,
multicast data is not coming from LMA. Or what you call direct routing.
=
I agree that it should not be called local routing, Seil please take no= te. Seil also uses direct routing which is OK.

> If the source is not MN, then our current draft = works well.

I am not sure, it needs to be clarified as to how = it works. It seems like the source directly connected to MAG will work.
=A0
=A0
According to the shared meaning through multimob discussion, I think B= ehcet is correct here. To avoid confusion of the meanings of direct routing= and local routing, the definitions of two terms were given through my slid= e in Quebec meeting. (Of course, those were defined by me.)
=A0
- Direct routing
: multicast data is transmitted from a source to a= MN using "Native Multicasting Infrastructure" within operator= 9;s network
=A0
- Local routing
: content source is directly conne= cted a MAG. There's no need of multicast routing protocol to retrieve m= ulticast data but MLD proxy function is needed on a MAG to exchange MLD sig= naling and multicast data between an MN and a source.
=A0
When we follow the definition of local routing, there's actually n= o issue of "routing" because "routing" is not used in h= ere. Somewhat=A0 "Local Content Delivery" may be much closer. Now= , we call it "local routing" simply.
=A0
For local contents delivery, it seems that there's no reason for t= he operators to provide the contents through the LMA but direct connection = with a MAG is natural.
=A0
Now, we go back the Behcet's=A0original question. Behcet is asking= =A0your solution is feasible for local routing case or not.Isn't it,=A0= Behcet?
=A0

>
>>>> =A0 What you are referring t= o below is probably in the context of
> source
>>>> = =A0 mobility. My suggestion is to take a look at the solution draft.
>= ; PS
>>>> =A0 draft has more scenarios and solution document address= ed only some
>>>> =A0 of the scenarios. Checking Shuai's= draft might be helpful.
>>>
>>> =A0Source mobility= in PMIPv6 means the way to support that a source
>>> =A0mobile node moves from p-MAG to n-MAG. Source mobility requ= ires PMIPv6
>>> =A0to support localized routing and needs to di= scuss how sourced contents
>>> =A0could be seamlessly served to= listener MNs during handover.
>>> =A0Localized routing is the core function of source mobility.<= br>>>
>> =A0No.
>
> Why No? :)
>
>&g= t; =A0Source mobility is MN is multicast source and of course MN maybe movi= ng.
>
> I said the same thing above (with more explanation).

We are in agreement then.

Regards,
Behcet

_______________________________________________
mu= ltimob mailing list
multimob@ietf.o= rg
https://www.ietf.org/mailman/listinfo/multimob

--000e0cd5f4aa6dda6204aa35737f-- From seiljeon@gmail.com Thu Aug 11 02:50:09 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F6B21F87C9 for ; Thu, 11 Aug 2011 02:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky1rvz1HFMSJ for ; Thu, 11 Aug 2011 02:50:08 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 558F321F8634 for ; Thu, 11 Aug 2011 02:50:08 -0700 (PDT) Received: by qwc23 with SMTP id 23so1259134qwc.31 for ; Thu, 11 Aug 2011 02:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=oXpT7W3nuvgGWtj/IsSnY0RC2BI2Hf20MR0WWot86E4=; b=ouqHSYsZVT+dRsRF5i5kiepx4F0qnjT86Gu1wZgFvyLg26uAp/t36dCbvByqJ7nMSg woUGcR7yXqyvzlTq1z8/9EhvipZ5UNIh9Fo8Ue2QXjAU0CfqKuar0uGtt8AHEp/iipPQ XmGHfQ/eY3sk8CiawW1IJIhAWo/eO1s7NVb3M= MIME-Version: 1.0 Received: by 10.229.118.78 with SMTP id u14mr7280145qcq.29.1313056242020; Thu, 11 Aug 2011 02:50:42 -0700 (PDT) Sender: seiljeon@gmail.com Received: by 10.229.250.77 with HTTP; Thu, 11 Aug 2011 02:50:41 -0700 (PDT) In-Reply-To: <1312990524.3468.YahooMailNeo@web111407.mail.gq1.yahoo.com> References: <1312837493.28387.YahooMailNeo@web111413.mail.gq1.yahoo.com> <20110809.181632.89135149.asaeda@sfc.wide.ad.jp> <1312906283.84814.YahooMailNeo@web111404.mail.gq1.yahoo.com> <20110810.020557.93136137.asaeda@sfc.wide.ad.jp> <1312913758.50353.YahooMailNeo@web111405.mail.gq1.yahoo.com> <1312990524.3468.YahooMailNeo@web111407.mail.gq1.yahoo.com> Date: Thu, 11 Aug 2011 18:50:41 +0900 X-Google-Sender-Auth: aHNhL6YbU4hOqgatVRUT2J2Iscs Message-ID: From: seil jeon To: Behcet Sarikaya Content-Type: multipart/alternative; boundary=000e0cd5f4aae0327604aa37bac2 Cc: "multimob@ietf.org" Subject: Re: [multimob] PMIPv6 extension for multicast X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 09:50:09 -0000 --000e0cd5f4aae0327604aa37bac2 Content-Type: text/plain; charset=ISO-8859-1 Hi Behcet, 2011/8/11 Behcet Sarikaya > Hi Seil, > Yes, if you integrate MR with MAG, "local routing" would work. > > I think that for PIM-SM at the MAG, MR should be directly connected. > > Regards, > > Behcet > > That's right. But in the case, any MR protocol is possible as well as PIM-SM because there's no need of "routing" action. Regards, Seil Jeon --000e0cd5f4aae0327604aa37bac2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Behcet,

2011/8/11 Behcet Sarikaya <= behcetsarikaya@yahoo.com>= ;
Hi Seil,
=A0 Yes, if you inte= grate MR with MAG, "local routing" would work.

I think tha= t for PIM-SM at the MAG, MR should be directly connected.

Regards,

Behcet
=A0
=A0
=A0
That's right.
=A0
But in the case, any MR protocol is possible as well as PIM-SM because= there's no need of "routing" action.
=A0
=A0
Regards,
=A0
Seil Jeon
=A0
--000e0cd5f4aae0327604aa37bac2-- From behcetsarikaya@yahoo.com Thu Aug 11 09:46:29 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0FD21F8C7D for ; Thu, 11 Aug 2011 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viBRtTo9lIK5 for ; Thu, 11 Aug 2011 09:46:29 -0700 (PDT) Received: from nm17-vm0.bullet.mail.ne1.yahoo.com (nm17-vm0.bullet.mail.ne1.yahoo.com [98.138.91.58]) by ietfa.amsl.com (Postfix) with SMTP id 1CA9E21F8C4E for ; Thu, 11 Aug 2011 09:46:28 -0700 (PDT) Received: from [98.138.90.57] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 16:47:03 -0000 Received: from [98.138.89.244] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 16:47:03 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 11 Aug 2011 16:47:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 424023.40376.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 23417 invoked by uid 60001); 11 Aug 2011 16:47:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313081222; bh=+uvmBMNeOsKkUjzKu7xull/Dgc4aCE15iqzqpPFhS7Q=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=rePyeUuuXLW3v84qXAAfTE+t7qYiYU6Gx2i5Bi7Mg7TzloXAhAS/a+1uMYPag889Snmaxa4vkZpYP+jsJSfZstgjzYmbpSPYaF+gSsAbOGCNgB1M/69SvfhJ+jqAHvgcN1Wz4hdmysKmJoIO83s1KJKncM5ls55MSWtvbnzpjZw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=PBsZTKwc9xuieRXPyOwluMB5rfqfwiV1S8OOu+H/J4iGVYrbS+yw8bh66imGDIg63CgJNH0KDgG8n2tu+ceIbypF1p5FowueqjKht110iPQr5GGUdoSzKkZfn289s7uJMr7hhwFcr29qCTtvBj5CzNO7T+ZZ8z3NSXB7Oks8Gvs=; X-YMail-OSG: 9T42HHEVM1nCS6fQR3_2tJcyCNJkN7rACuvLqex5aKYQiL6 qignEW8DNIJQUq_ubc8OkJ32rx9At3mO5DmNl9tDwe5wswbWlk1MMMFu_dWR PK7JU44B5xeIsgRAsawlyyE8Zhll77q.l1l6kd7q9F71rCyLQpCsZ8AYIm3a YweIVIvYxxgEoSEeadNlXefpbzj6yH7RwHldMLqwc.f77AX_gJUz3UR0TD6F 10JBO8b_1C4C09UyMS57IfYwIXvLL5ZBR6qN8l60ZHo6fPdPyoUZ0cv3EibK g9wFM6XBG9WvK_0JOSCxL3SY.mETmPvh8mN13hpDUJ9_cUPwid6xq8d0Wg3t xzFUpW17qJ2x5BBDfT3tybDaoeEzZdmGCR9a08p88ZdH5w6bdJakDeLYqE26 Fz9PtbxqIz.mRtHjkC5P7cyAg3EfBmUo9Jq.sA9VS7tDxuVKy.._9tem6Rl7 TuPszVIHCXZct_Y0NGlrzB1yCNmqpKkLf7ox_lWVBlpR5RCGc6N2GBQsNLUv GO1iT1pDBrF9eSPc3tuBQxkGNTkJ5BYQriY4jKNvLNGWfJQ-- Received: from [50.58.7.243] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 11 Aug 2011 09:47:02 PDT X-Mailer: YahooMailWebService/0.8.113.313619 Message-ID: <1313081222.17848.YahooMailNeo@web111402.mail.gq1.yahoo.com> Date: Thu, 11 Aug 2011 09:47:02 -0700 (PDT) From: Behcet Sarikaya To: "multimob@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] IETF 81 Minutes X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:46:29 -0000 Version 0 of the minutes are at: http://www.ietf.org/proceedings/81/minutes/multimob.txt Thanks to Dirk for note taking. Please send your corrections to the list. Regards, Behcet From cjbc@it.uc3m.es Mon Aug 15 06:01:16 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6179121F8B8E for ; Mon, 15 Aug 2011 06:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOJnoABrZfoB for ; Mon, 15 Aug 2011 06:01:15 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3CACD21F8B8D for ; Mon, 15 Aug 2011 06:01:14 -0700 (PDT) X-uc3m-safe: yes Received: from [172.21.46.176] (unknown [192.197.121.176]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id DF5216CBA97; Mon, 15 Aug 2011 15:01:56 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: multimob@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8kE1OrdCl5oxKEtcfPid" Organization: Universidad Carlos III de Madrid Date: Mon, 15 Aug 2011 15:01:54 +0200 Message-ID: <1313413314.4335.35.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18324.007 Subject: [multimob] PMIPv6 routing optimizations to avoid tunnel convergence problem X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:01:16 -0000 --=-8kE1OrdCl5oxKEtcfPid Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, In the last IETF meeting we had a good discussion on the different approaches that can be adopted to tackle the tunnel convergence problem. The consensus of the room was that no single approach solves all problems: - Direct routing approaches are well suited for getting content that is locally available/generated at the visited domain where the MN is camping, or to get to multicast groups without the traffic traversing the LMA back at the home domain (kind-of offloading approach). - Dedicated multicast anchor alike solutions are well suited for getting content that is only available, or preferred to be accessed via the LMA at the home network. - Additionally, there is also the case where the multicast content provider is a third party, nor the home or the visitor provider (e.g., NBA serving a basketball match to telco operators -- well, maybe this is not the best example due to the NBA lockout :P ). In this case, other factors -- such as commercial agreements, costs, etc. -- are to be mainly considered. Based on that, it was suggested that we might want to go for a flexible solution that allows integrating these two main approaches, in such a way that different traffic may get routed differently, depending on several aspects (traffic characteristics/availability at the local domain, user profile, operator deployment decisions -- as operators may decide not to deploy direct & dedicated multicast anchor solutions everywhere, etc.). The right network entity to implement that decision about what approach to follow seems to be the MAG (the decision itself can come from another network entity, this needs more study). =46rom our understanding of what was discussed during the meeting, our proposed next step is to analyze most likely deployment use cases/scenarios, and evaluate the pros&cons of each of the potential solution families described above. Comments on the proposed approach? Thanks, Juan Carlos, Akbar, Luis and Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcom.it.uc3m.es/ GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-8kE1OrdCl5oxKEtcfPid Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk5JGMIACgkQNdy6TdFwT2eQVQCgtQpsRI6mrBv3xOno+SRL0Fp4 6U8AoJIo3p52ewLFB8IdVMlrcK9/H3PE =lcF6 -----END PGP SIGNATURE----- --=-8kE1OrdCl5oxKEtcfPid-- From stig@venaas.com Mon Aug 15 10:27:43 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AB521F8C6C for ; Mon, 15 Aug 2011 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq2jlr+eLOVQ for ; Mon, 15 Aug 2011 10:27:42 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 831A921F8C6B for ; Mon, 15 Aug 2011 10:27:42 -0700 (PDT) Received: from [10.33.12.82] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 7DDC18062 for ; Mon, 15 Aug 2011 19:28:27 +0200 (CEST) Message-ID: <4E495739.8000307@venaas.com> Date: Mon, 15 Aug 2011 10:28:25 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multimob] PIM and non-directly connected multicast sources X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 17:27:43 -0000 In Quebec we had some discussions regarding how PIM behaves when sources are not directly connected. E.g. for the base solution, if a MN is a source, the MAG an IGMP/MLD proxy and a router (a layer-3 device) and the LMA a PIM router (or possibly LMA also a proxy with PIM further upstream). Anyway, the issue is that for ASM to work with PIM-SM, the PIM router closest to the source should send PIM registers to the RP. The PIM spec (RFC 4601) says that the PIM router does that if the source is directly connected. See mainly section 4.2 of 4601 if interested. In our case, the MN would not be regarded as directly connected, because there is a router between the source and the LMA. But there are solutions to this problem. This is described in appendix A of RFC 4601. They are used when connecting a multicast domain not running PIM-SM, to a PIM-SM domain. I think most PIM implementations have some kind of solution for this, either as in A.1 or something similar. Stig From multimob2011@gmail.com Wed Aug 24 20:36:20 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E130721F8BD3 for ; Wed, 24 Aug 2011 20:36:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQsvKudme8Vf for ; Wed, 24 Aug 2011 20:36:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46D7721F8BCD for ; Wed, 24 Aug 2011 20:36:20 -0700 (PDT) Received: by gxk19 with SMTP id 19so1653011gxk.31 for ; Wed, 24 Aug 2011 20:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=t8cW+J6B+Abd5ls7/3HM/Ce1heqitH/7w10ZYqTQavE=; b=xdtwJMsTGOMnxk+JRuBRdGGpJqY8pbPD6GM0iUB+NKrXjCFz8FlpfBOn9vZgKHlI6a 8rr5WHmrugVXVEbXLoDRvApfyFLqBTvkrfiJNS47eySV50KbFkFHvQKngXBNkDHblRpj Q1fcqern/6xBn2lduhis6gVcu3zhpbtvw7nPk= MIME-Version: 1.0 Received: by 10.150.12.8 with SMTP id 8mr321367ybl.107.1314243452397; Wed, 24 Aug 2011 20:37:32 -0700 (PDT) Received: by 10.151.114.21 with HTTP; Wed, 24 Aug 2011 20:37:32 -0700 (PDT) Date: Thu, 25 Aug 2011 11:37:32 +0800 Message-ID: From: Aaron Feng To: multimob@ietf.org Content-Type: multipart/alternative; boundary=000e0cd6ab9020ea6104ab4c26d1 Subject: [multimob] Questions for MLD Proxy X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:36:21 -0000 --000e0cd6ab9020ea6104ab4c26d1 Content-Type: text/plain; charset=ISO-8859-1 Hi! I have a quention for MLD Proxy. In RFC 6224, it says MLD Proxy instances should be deployed on MAGs. After receiving the MLD report message from MNs, the attached MAG should be on behalf of the MNs sending MLD report message using the link address of MAG itself as the source address. Moreover, according to RFC 3810, MLDv2 protocol is used by an IPv6 router to discover the presence of multicast listeners *on directly attached links*. My question is that, in most cases, the LMA and MAG are not directly connected and they don't have the same link address prefix, so maybe LMA will discard the MLD report messages for not directly connection even the MLD report messages can be transmitted through the LMA-MAG tunnel to LMA. (I think at first, when receiving packets from the corresponding MAG, the LMA should first decapsulate the packet and then extract the MLD report messages to execute check of directly connection before establishing MFIB.) Is that right? Aaron Feng --000e0cd6ab9020ea6104ab4c26d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!
I have a quention for MLD Proxy. In RFC 6224, it says=A0 MLD Proxy ins= tances should be deployed on MAGs. After receiving=A0the MLD=A0report=A0mes= sage from MNs, the attached MAG should=A0be on behalf of the MNs sending ML= D report message=A0using the link address of =A0MAG itself as=A0the source = address. Moreover, according to RFC 3810, MLDv2 protocol is used by an IPv6= router to discover the presence of multicast listeners on direc= tly attached links.=A0My question is that,=A0= in most cases, the LMA and MAG are not directly connected and they don'= t have the same link address prefix, so maybe LMA will discard the MLD repo= rt messages for not directly connection even the MLD report messages can be= transmitted through the LMA-MAG tunnel to LMA.=A0(I think at first, when r= eceiving packets from the corresponding MAG, the=A0LMA should first decapsu= late the packet and then extract the MLD report messages to=A0execute check= of=A0directly connection before establishing MFIB.) Is that right?=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=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=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=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Aaron Feng=A0=A0<= /div> --000e0cd6ab9020ea6104ab4c26d1-- From multimob2011@gmail.com Wed Aug 24 20:40:53 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA95E21F8B06 for ; Wed, 24 Aug 2011 20:40:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRqghDvs75Jv for ; Wed, 24 Aug 2011 20:40:53 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6837321F8B02 for ; Wed, 24 Aug 2011 20:40:53 -0700 (PDT) Received: by gxk19 with SMTP id 19so1655800gxk.31 for ; Wed, 24 Aug 2011 20:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=raUwJdiP2tfTZhVIBOk3TPgYl0IaJrjco6auvfqPJDA=; b=hD4yj+n0PaEDrkDs3lvmiXkklVplMd5EBYe1qgRcw43np1lMIXEO2MVjIcrPwXyOJ7 TQM8U+1D6Vht9o2s9cQ/+F9fxyBqqDP/il1++I4tPRaFfm5jrsRO7ZmcurT0V/NT41Du h5o0vCULQfmzqVtDuwwZdaxuvWISpQh7+JPcY= MIME-Version: 1.0 Received: by 10.150.65.19 with SMTP id n19mr334762yba.50.1314243725416; Wed, 24 Aug 2011 20:42:05 -0700 (PDT) Received: by 10.151.114.21 with HTTP; Wed, 24 Aug 2011 20:42:05 -0700 (PDT) Date: Thu, 25 Aug 2011 11:42:05 +0800 Message-ID: From: Aaron Feng To: multimob@ietf.org Content-Type: multipart/alternative; boundary=000e0cd48b5266d7ad04ab4c36fa Subject: [multimob] Questions for MLD Proxy X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:40:54 -0000 --000e0cd48b5266d7ad04ab4c36fa Content-Type: text/plain; charset=ISO-8859-1 Hi! I have a quention for MLD Proxy. In RFC 6224, it says MLD Proxy instances should be deployed on MAGs. After receiving the MLD report message from MNs, the attached MAG should be on behalf of the MNs sending MLD report message using the link address of MAG itself as the source address. Moreover, according to RFC 3810, MLDv2 protocol is used by an IPv6 router to discover the presence of multicast listeners *on directly attached links*. My question is that, in most cases, the LMA and MAG are not directly connected and they don't have the same link address prefix, so maybe LMA will discard the MLD report messages for not directly connected even the MLD report can be transmitted through the LMA-MAG tunnel. (I think at first LMA shuold decapsu) Aaron Feng --000e0cd48b5266d7ad04ab4c36fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!
I have a quention for MLD Proxy. In RFC 6224, it says=A0 MLD Proxy ins= tances should be deployed on MAGs. After receiving=A0the MLD=A0report=A0mes= sage from MNs, the attached MAG should=A0be on behalf of the MNs sending ML= D report message=A0using the link address of =A0MAG itself as=A0the source = address. Moreover, according to RFC 3810, MLDv2 protocol is used by an IPv6= router to discover the presence of multicast listeners on direc= tly attached links.=A0My question is that,=A0= in most cases, the LMA and MAG are not directly connected and they don'= t have the same link address prefix, so maybe LMA will discard the MLD repo= rt messages for not directly connected even the MLD report can be transmitt= ed through the LMA-MAG tunnel.=A0(I think at first LMA shuold decapsu)=A0
=A0
=A0
=A0
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Aaron Feng=A0=A0 --000e0cd48b5266d7ad04ab4c36fa-- From multimob2011@gmail.com Sun Aug 28 19:42:04 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E4921F86AC for ; Sun, 28 Aug 2011 19:42:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21oH0LsaIR9g for ; Sun, 28 Aug 2011 19:42:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B63B621F86AA for ; Sun, 28 Aug 2011 19:42:03 -0700 (PDT) Received: by fxe6 with SMTP id 6so4390117fxe.31 for ; Sun, 28 Aug 2011 19:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+1bk7Zfbluu1eSoe+QouTKhKUQGzyciNVWULMy9QKG0=; b=BgtVPwrtUAa7L44JjxLbS0av6vu/DXdzDdMc411lriO/nkFJ0Wxgu4UYMXtExnhN9Q j4VeZuiEgZt+QwowIEwT4RFoMdyt3ihRgs4P35oLSjd4w6XjYIbCgFVODOGNDtKTPu3n 6sNlmVHDU1mLbRWNr47xOKI1dI1nYQnP7I570= MIME-Version: 1.0 Received: by 10.223.71.145 with SMTP id h17mr6339083faj.49.1314585806538; Sun, 28 Aug 2011 19:43:26 -0700 (PDT) Received: by 10.152.22.39 with HTTP; Sun, 28 Aug 2011 19:43:26 -0700 (PDT) Date: Mon, 29 Aug 2011 10:43:26 +0800 Message-ID: From: Aaron Feng To: schmidt@informatik.haw-hamburg.de, behcetsarikaya@yahoo.com, stig@venaas.com Content-Type: multipart/alternative; boundary=0015174c127a06874a04ab9bdce4 Cc: multimob@ietf.org Subject: [multimob] Question for RFC 6224 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 02:42:04 -0000 --0015174c127a06874a04ab9bdce4 Content-Type: text/plain; charset=ISO-8859-1 Hi! I have a quention for RFC 6224. In RFC 6224, under the scenario where MLD Proxy instances are only deployed on MAGs, there may be a problem. After receiving the MLD report message from MNs, the attached MAG should be on behalf of the MNs sending MLD report message using the link address of the MAG itself as the L3 source address of data packets. According to RFC 3810, MLDv2 protocol is used by an IPv6 router to discover the presence of multicast listeners *on directly attached links*. However, in most cases, the LMA and MAG are not directly connected and they don't have the same link address prefix, so maybe LMA will discard the MLD report messages for not direct connection even the MLD report messages could be transmitted through the LMA-MAG tunnel to LMA. In my opinion, at first, when receiving packets from the corresponding MAG, the LMA should first decapsulate the packets and then extract the MLD report messages to execute check of direct connectionly, using source address prefix of the packets which is the link address prefix of the MAG before adding or maintaining the corresponding MFIB info. Is what I think resaonable? Give some opinions please~ Aaron Feng --0015174c127a06874a04ab9bdce4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi!
=A0=A0=A0 I have=A0a quention for RFC 6224.=A0In RFC 6224,=A0under the= scenario where=A0MLD Proxy instances=A0are only deployed on MAGs, there ma= y be=A0a problem.=A0After receiving=A0the MLD=A0report=A0message from MNs, = the attached MAG should=A0be on behalf of the MNs sending MLD report messag= e=A0using the link address of =A0the MAG itself as=A0the L3 source address = of data packets.=A0According to RFC 3810, MLDv2 protocol is used by an IPv6= router to discover the presence of multicast listeners on direc= tly attached links.=A0However,=A0in most case= s, the LMA and MAG are not directly connected and they don't have the s= ame link address prefix, so maybe LMA will discard the MLD report messages = for not direct connection even the MLD report messages could be transmitted= through the LMA-MAG tunnel to LMA.=A0In my opinion,=A0at first, when recei= ving packets from the corresponding MAG, the=A0LMA should first decapsulate= the packets and then extract the MLD report messages to=A0execute check of= =A0direct connectionly,=A0using source address prefix=A0of the packets whic= h is the link address prefix of the MAG=A0before=A0adding or maintaining=A0= the corresponding MFIB info.=A0Is what I think resaonable? Give some opinio= ns please~=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=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=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=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 Feng=A0=A0 --0015174c127a06874a04ab9bdce4-- From schmidt@informatik.haw-hamburg.de Mon Aug 29 01:58:15 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701C121F876A for ; Mon, 29 Aug 2011 01:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5apR4Wsuteru for ; Mon, 29 Aug 2011 01:58:14 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 79D6D21F874E for ; Mon, 29 Aug 2011 01:58:12 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231107154.adsl.alicedsl.de ([92.231.107.154] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Qxxgt-0008mc-5D; Mon, 29 Aug 2011 10:59:35 +0200 Message-ID: <4E5B54F4.8030604@informatik.haw-hamburg.de> Date: Mon, 29 Aug 2011 10:59:32 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Aaron Feng References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: behcetsarikaya@yahoo.com, multimob@ietf.org Subject: Re: [multimob] Question for RFC 6224 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 08:58:15 -0000 Hi Aaron, thanks for your comments. There are two MLD reports involved here: one from MN to the MAG which are physically link-local, one from the MAG-Proxy to LMA which are virtually link-local by using a tunnel (normally generic as of RFC 2473). You address the second one. The answer should be as follows: The LMA operates in MLD router part on the tunnel interface and listens to appropriate groups (depending on the MLD version). MAG transmits MLD reports with link-locally scoped messages (link-local address, hop limit 1, router alert option) that are encapsulated in the tunnel and thus arrive at the LMA. The LMA tunnel interface endpoint will decapsulate the report and - according to RFC 3810 - checks: "Upon reception of an MLD message that contains a Report, the router checks if the source address of the message is a valid link-local address, if the Hop Limit is set to 1, and if the Router Alert option is present in the Hop-By-Hop Options header of the IPv6 packet. " This will all be true, so LMA will continue to process the report and build per interface states accordingly. Could I explain that well enough? Thomas On 29.08.2011 04:43, Aaron Feng wrote: > Hi! > I have a quention for RFC 6224. In RFC 6224, under the scenario > where MLD Proxy instances are only deployed on MAGs, there may be a > problem. After receiving the MLD report message from MNs, the attached > MAG should be on behalf of the MNs sending MLD report message using the > link address of the MAG itself as the L3 source address of data > packets. According to RFC 3810, MLDv2 protocol is used by an IPv6 router > to discover the presence of multicast listeners _*on directly* *attached > links*_. However, in most cases, the LMA and MAG are not directly > connected and they don't have the same link address prefix, so maybe LMA > will discard the MLD report messages for not direct connection even the > MLD report messages could be transmitted through the LMA-MAG tunnel to > LMA. In my opinion, at first, when receiving packets from the > corresponding MAG, the LMA should first decapsulate the packets and then > extract the MLD report messages to execute check of direct > connectionly, using source address prefix of the packets which is the > link address prefix of the MAG before adding or maintaining the > corresponding MFIB info. Is what I think resaonable? Give some opinions > please~ > Aaron Feng -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From multimob2011@gmail.com Mon Aug 29 02:58:57 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0505621F8ABD for ; Mon, 29 Aug 2011 02:58:57 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTUeHUOXh2+r for ; Mon, 29 Aug 2011 02:58:56 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E843B21F893C for ; Mon, 29 Aug 2011 02:58:55 -0700 (PDT) Received: by fxe6 with SMTP id 6so4655507fxe.31 for ; Mon, 29 Aug 2011 03:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GsSBiTYe5kIUUbxiKm/KoH7djkH0AkXeqX4ygNObFQ4=; b=XN/qlfevhkgSGg9iiQymnTOz2tyA1is7UJTm7p9j/rtu+cnr+9+ncQ2/OpCITro7Tk pgPZI7d+ptrw1CV5py8ViDe5yj7BxaxbjBBp3LpToxJT8EexKt7UB6akKsP+M2piM3rU 7L9/LsbLj+Xmg5A/EexwDdAQRu0XBsvpoNmF0= MIME-Version: 1.0 Received: by 10.223.58.66 with SMTP id f2mr483071fah.106.1314612019294; Mon, 29 Aug 2011 03:00:19 -0700 (PDT) Received: by 10.152.22.39 with HTTP; Mon, 29 Aug 2011 03:00:19 -0700 (PDT) In-Reply-To: <4E5B54F4.8030604@informatik.haw-hamburg.de> References: <4E5B54F4.8030604@informatik.haw-hamburg.de> Date: Mon, 29 Aug 2011 18:00:19 +0800 Message-ID: From: Aaron Feng To: "Thomas C. Schmidt" , behcetsarikaya@yahoo.com, stig@venaas.com Content-Type: multipart/alternative; boundary=0015174764866d73ef04aba1f669 Cc: multimob@ietf.org Subject: Re: [multimob] Question for RFC 6224 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 09:58:57 -0000 --0015174764866d73ef04aba1f669 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thomas Thank you for your reply! > > There are two MLD reports involved here: one from MN to the MAG which are > physically link-local, one from the MAG-Proxy to LMA which are virtually > link-local by using a tunnel (normally generic as of RFC 2473). > > You address the second one. > Yes. > > The answer should be as follows: The LMA operates in MLD router part on the > tunnel interface and listens to appropriate groups (depending on the MLD > version). MAG transmits MLD reports with link-locally scoped messages > (link-local address, hop limit 1, router alert option) that are encapsulated > in the tunnel and thus arrive at the LMA. The LMA tunnel interface endpoint > will decapsulate the report and - according to RFC 3810 - checks: > > "Upon reception of an MLD message that contains a Report, the router > checks if the source address of the message is a valid link-local > address, if the Hop Limit is set to 1, and if the Router Alert option > is present in the Hop-By-Hop Options header of the IPv6 packet. " > I agree above. I think the divergence between us is how to comprehend the "valid link-local address". In my opinion, a valid link-local address means more than a legal link address, but also a *local* link-address, with the same link-address prefix of the router which receives the MLD Report messages (It's the LMA in such scenario, I think, the "local" is not for the MAG, but for the LMA ). However, in most cases, MAGs and LMAs don't have the same link-address prefix though they are virtually directly connected, but after decapsulation at first, they aren't directly connected, which may cause the failure of direct connection. That's what I worry about. Aaron Feng --0015174764866d73ef04aba1f669 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi, Thomas
=A0
=A0Thank you for your reply!
=A0
=A0

There are two MLD reports in= volved here: one from MN to the MAG which are physically link-local, one fr= om the MAG-Proxy to LMA which are virtually link-local by using a tunnel (n= ormally generic as of RFC 2473).

You address the second one.
=A0
Yes.
=A0

The answer should be as foll= ows: The LMA operates in MLD router part on the tunnel interface and listen= s to appropriate groups (depending on the MLD version). MAG transmits MLD r= eports with link-locally scoped messages (link-local address, hop limit 1, = router alert option) that are encapsulated in the tunnel and thus arrive at= the LMA. The LMA tunnel interface endpoint will decapsulate the report and= - according to RFC 3810 - checks:

=A0"Upon reception of an MLD message that contains a Report, the r= outer
=A0 checks if the source address of the message is a valid link-lo= cal
=A0 address, if the Hop Limit is set to 1, and if the Router Alert o= ption
=A0 is present in the Hop-By-Hop Options header of the IPv6 packet. "<= br>
=A0=A0=A0I agree above.
=A0=A0
=A0=A0 I think the=A0divergence between us is how to comprehend the &q= uot;valid link-local=A0address". In my opinion, a valid link-local add= ress means more than a legal link address, but also a local link-add= ress, with the same link-address prefix=A0of the router which receives the = MLD=A0Report messages (It's the=A0LMA in=A0such scenario, I think, the = "local" is not for the MAG, but for=A0the LMA ). However, in most= cases,=A0MAGs and LMAs don't have the same=A0link-address prefix thoug= h they are virtually directly connected, but after decapsulation at first, = they=A0aren't directly=A0connected,=A0which may cause the failure of di= rect connection. That's what I worry about.=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= =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= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Aaron Feng
=A0
=A0
=A0=A0
--0015174764866d73ef04aba1f669-- From schmidt@informatik.haw-hamburg.de Mon Aug 29 04:16:00 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E207F21F850E for ; Mon, 29 Aug 2011 04:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPVqkxWxrYHg for ; Mon, 29 Aug 2011 04:16:00 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4BF21F84F3 for ; Mon, 29 Aug 2011 04:16:00 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231107154.adsl.alicedsl.de ([92.231.107.154] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QxzqF-0000uZ-6r; Mon, 29 Aug 2011 13:17:23 +0200 Message-ID: <4E5B7539.1070808@informatik.haw-hamburg.de> Date: Mon, 29 Aug 2011 13:17:13 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Aaron Feng References: <4E5B54F4.8030604@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: behcetsarikaya@yahoo.com, multimob@ietf.org Subject: Re: [multimob] Question for RFC 6224 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 11:16:01 -0000 Hi Aaron, On 29.08.2011 12:00, Aaron Feng wrote: > > The answer should be as follows: The LMA operates in MLD router part > on the tunnel interface and listens to appropriate groups (depending > on the MLD version). MAG transmits MLD reports with link-locally > scoped messages (link-local address, hop limit 1, router alert > option) that are encapsulated in the tunnel and thus arrive at the > LMA. The LMA tunnel interface endpoint will decapsulate the report > and - according to RFC 3810 - checks: > > "Upon reception of an MLD message that contains a Report, the router > checks if the source address of the message is a valid link-local > address, if the Hop Limit is set to 1, and if the Router Alert option > is present in the Hop-By-Hop Options header of the IPv6 packet. " > > I agree above. > I think the divergence between us is how to comprehend the "valid > link-local address". In my opinion, a valid link-local address means > more than a legal link address, but also a _local_ link-address, with > the same link-address prefix of the router which receives the MLD Report > messages (It's the LMA in such scenario, I think, the "local" is not for > the MAG, but for the LMA ). However, in most cases, MAGs and LMAs don't > have the same link-address prefix though they are virtually directly > connected, but after decapsulation at first, they aren't > directly connected, which may cause the failure of direct connection. > That's what I worry about. An IPv6 link-local address always has the prefix FE80::/10. There is no additional "link-address prefix", as link-local addresses are not routable -> see RFC 4291. Hope that resolves the issue. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From multimob2011@gmail.com Mon Aug 29 05:10:17 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D255821F8B2A for ; Mon, 29 Aug 2011 05:10:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2ukBI+wVnbd for ; Mon, 29 Aug 2011 05:10:17 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6F21F8B0B for ; Mon, 29 Aug 2011 05:10:16 -0700 (PDT) Received: by fxe6 with SMTP id 6so4757748fxe.31 for ; Mon, 29 Aug 2011 05:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XIOSS9gzi4Rjr5A/kdP/wDatpR8qT9B6NR3gZndSymw=; b=lF1XZUDPbsBiGthwuMv7lNlNSLJzIchodpSMn1h2cAF5iSNDNRz+gWmu2lxGW6w4cU rE4euyULE2dKeGFlXoB74LFZ0QOSxhNcmaIYZwY/4w2Vwcbk0thWOHKb52D2COzDYMnV 8NDSCYoQpNk/bDDHzt8bhs6fTGj3/A2+4qUEo= MIME-Version: 1.0 Received: by 10.223.88.83 with SMTP id z19mr7097062fal.11.1314619889171; Mon, 29 Aug 2011 05:11:29 -0700 (PDT) Received: by 10.152.22.39 with HTTP; Mon, 29 Aug 2011 05:11:29 -0700 (PDT) In-Reply-To: <4E5B7539.1070808@informatik.haw-hamburg.de> References: <4E5B54F4.8030604@informatik.haw-hamburg.de> <4E5B7539.1070808@informatik.haw-hamburg.de> Date: Mon, 29 Aug 2011 20:11:29 +0800 Message-ID: From: Aaron Feng To: "Thomas C. Schmidt" , behcetsarikaya@yahoo.com, stig@venaas.com Content-Type: multipart/alternative; boundary=000e0cd4d168823eb104aba3cb3a Cc: multimob@ietf.org Subject: Re: [multimob] Question for RFC 6224 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:10:17 -0000 --000e0cd4d168823eb104aba3cb3a Content-Type: text/plain; charset=ISO-8859-1 Hi, Thomas, You are right, thank you! :) Aaron Feng --000e0cd4d168823eb104aba3cb3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Thomas,

You are right, thank you! =A0:) =A0

=A0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Aaron Feng
--000e0cd4d168823eb104aba3cb3a--