From sarikaya2012@gmail.com Mon Dec 5 14:02: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 321E21F0C7A for ; Mon, 5 Dec 2011 14:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, 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 NxVyWrUwIvLT for ; Mon, 5 Dec 2011 14:02:19 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4A1F0C47 for ; Mon, 5 Dec 2011 14:02:19 -0800 (PST) Received: by ywm13 with SMTP id 13so5647049ywm.31 for ; Mon, 05 Dec 2011 14:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=btLxTtdXmMFFyBZGr40ebq2SxJVIz8VuqwcL3d1XwWw=; b=G4bRBw3QSKKfL+IKbrxMBUXt1UoCmBJuOTThYYBk6/QET+oO24uiw12ratQdPHam0d XgwxTrL6eeHaPW5ZsTx5ItZzi6kvqhnVPaiSPsOuDA2SBB/hvVmM2P/PE6tcm4iHwhkb ZzTMAH+j/P0Vd597/lEKEMPIIUcTGbeSmXaSw= MIME-Version: 1.0 Received: by 10.236.193.68 with SMTP id j44mr14869798yhn.97.1323122539199; Mon, 05 Dec 2011 14:02:19 -0800 (PST) Received: by 10.236.15.102 with HTTP; Mon, 5 Dec 2011 14:02:19 -0800 (PST) Date: Mon, 5 Dec 2011 16:02:19 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:02:20 -0000 Hello all, =A0 There was consensus=A0on the source mobility solution draft in Taipei. This mail is to confirm the consensus. This document can be found at: http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt This mail starts a WG adoption call on this draft. The intended status for this document is proposed standard. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-source-mobility. Please your comments by December 12, 2011. Chairs From Dirk.von-Hugo@telekom.de Tue Dec 6 04:55:03 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 4EDBF21F8B0F for ; Tue, 6 Dec 2011 04:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiCUfWMOvz3X for ; Tue, 6 Dec 2011 04:55:02 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 63D2521F8AD6 for ; Tue, 6 Dec 2011 04:55:01 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 06 Dec 2011 13:52:15 +0100 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.112]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 6 Dec 2011 13:52:14 +0100 From: To: , Date: Tue, 6 Dec 2011 13:51:16 +0100 Thread-Topic: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 Thread-Index: AcyzmZIq5kN96hZsSWuMXsDHDQiuIAAYoC3g Message-ID: <05C81A773E48DD49B181B04BA21A342A26809A834C@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 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, 06 Dec 2011 12:55:03 -0000 Dear all, I agree to adopt the merged draft as WG document and assume that some consi= derations on PIM-SM and BIDIR PIM will be added. Beside I have some minor remarks to improve readability: On P. 4 it says: > A multicast unaware MAG would simply discard these packets in the absence of a multicast forwarding information base (MFIB). However in sect. 4.2. the MFIB is not mentioned for MAG, only in 4.3. for L= MA. Perhaps we should add a sentence on it before saying also whether a syn= chronisation between MAGs and LMAs MFIB is envisaged. On the other hand MFIB was already introduced in RFC6224 ... So this is obv= ious to the experienced reader. On P.5 it says: Thus multicast streams originating from an MN will arrive at the corresponding LMA and directly at all mobile receivers co-located at the same MAG. However on P. 6 the restriction is made: MN - while being attached to the same MAG as the mobile source, but associated with a different LMA, cannot receive multicast traffic on a shortest path. Again this may be obvious being a standard RFC6224 procedure but the fact m= ight be mentioned already in the sentence on P. 5 not to cause misunderstan= ding. On p.8 I stumbled on the MAG proxy (or MAG-proxy) mentioned and found that = the term was inherited from RFC6224. I think it denotes the IGMP/MLD proxy = instance located at the MAG, right? I also found following very minor nits P.4: a multicast destination addresses =3D> a multicast destination address P.5: IPv6 unicast address configuration with PMIPv6 bindings have been performed= . =3D> IPv6 unicast address configuration with PMIPv6 bindings has been per= formed. P.6: It is worth noting that a MN =3D> It is worth noting that an MN P.7: On the arrival of a MN, =3D> On the arrival of an MN, transition from a MN. =3D> transition from an MN. P.8: Multicast streams from and to MNs arrive at a MAG on point-to-point links (identical to unicast). between the routers and independent of any individual MN. =3D> not sure what to add, perhaps similar as in RFC 6224: Multicast streams from and to MNs arrive at a MAG on point-to-point links (identical to unicast). >>Aggregated multicast streams between the MAG proxy instance and the LMA remain link-local<< between the routers a= nd independent of any individual MN. ?? Please check! P.9: will seemlessly embed PMIP mobility gateways =3D> will seamlessly embed PMI= P mobility gateways My 2 cents ;-) Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Behcet Sarikaya Gesendet: Montag, 5. Dezember 2011 23:02 An: multimob@ietf.org Betreff: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-sourc= e-00 Hello all, There was consensus on the source mobility solution draft in Taipei. This mail is to confirm the consensus. This document can be found at: http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt This mail starts a WG adoption call on this draft. The intended status for this document is proposed standard. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-source-mobility. Please your comments by December 12, 2011. Chairs _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From prvs=314cb619e=schmidt@informatik.haw-hamburg.de Tue Dec 6 08:23:39 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 067A721F8438 for ; Tue, 6 Dec 2011 08:23:39 -0800 (PST) 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 qZvrzOS0gt+S for ; Tue, 6 Dec 2011 08:23:35 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id C518D21F8437 for ; Tue, 6 Dec 2011 08:23:33 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 06 Dec 2011 17:23:32 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 1FDAB102C0F6; Tue, 6 Dec 2011 17:23:32 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31403-05; Tue, 6 Dec 2011 17:23:31 +0100 (CET) Received: from [172.17.192.67] (75-148-178-225-Houston.hfc.comcastbusiness.net [75.148.178.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 6D92B102C0CA; Tue, 6 Dec 2011 17:23:30 +0100 (CET) Message-ID: <4EDE4188.50103@informatik.haw-hamburg.de> Date: Tue, 06 Dec 2011 10:23:36 -0600 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dirk von Hugo , "multimob@ietf.org" References: <05C81A773E48DD49B181B04BA21A342A26809A834C@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A26809A834C@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Subject: Re: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 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, 06 Dec 2011 16:23:39 -0000 Hi Dirk, many thanks for the detailed feedback: we will carefully go over the document and improve/fix all these issues. We fully agree that a number of efforts need to go into the document. We also are in the late stage of providing a corresponding proxy implementation which will be released soon. Plan is: Document update and software release before Christmas :-) Best wishes, Thomas On 06.12.2011 06:51, Dirk.von-Hugo@telekom.de wrote: > > Dear all, > > I agree to adopt the merged draft as WG document and assume that some considerations on PIM-SM and BIDIR PIM will be added. > Beside I have some minor remarks to improve readability: > > On P. 4 it says: > >> A multicast unaware MAG would simply discard these packets in > the absence of a multicast forwarding information base (MFIB). > > However in sect. 4.2. the MFIB is not mentioned for MAG, only in 4.3. for LMA. Perhaps we should add a sentence on it before saying also whether a synchronisation between MAGs and LMAs MFIB is envisaged. > On the other hand MFIB was already introduced in RFC6224 ... So this is obvious to the experienced reader. > > On P.5 it says: > Thus multicast streams originating from an MN will arrive at > the corresponding LMA and directly at all mobile receivers co-located > at the same MAG. > > However on P. 6 the restriction is made: > > MN - while being attached to the same MAG as the mobile source, but > associated with a different LMA, cannot receive multicast traffic on > a shortest path. > > Again this may be obvious being a standard RFC6224 procedure but the fact might be mentioned already in the sentence on P. 5 not to cause misunderstanding. > > On p.8 I stumbled on the MAG proxy (or MAG-proxy) mentioned and found that the term was inherited from RFC6224. I think it denotes the IGMP/MLD proxy instance located at the MAG, right? > > > I also found following very minor nits > > P.4: > a multicast destination addresses => a multicast destination address > P.5: > IPv6 unicast address configuration with PMIPv6 bindings have been performed. => IPv6 unicast address configuration with PMIPv6 bindings has been performed. > P.6: > It is worth noting that a MN => It is worth noting that an MN > P.7: > On the arrival of a MN, => On the arrival of an MN, > transition from a MN. => transition from an MN. > P.8: > Multicast streams from and to MNs arrive at a MAG on point-to-point > links (identical to unicast). between the routers and independent of > any individual MN. > => not sure what to add, perhaps similar as in RFC 6224: > Multicast streams from and to MNs arrive at a MAG on point-to-point > links (identical to unicast).>>Aggregated multicast streams between the > MAG proxy instance and the LMA remain link-local<< between the routers and independent of > any individual MN. ?? > > Please check! > > P.9: > will seemlessly embed PMIP mobility gateways => will seamlessly embed PMIP mobility gateways > > My 2 cents ;-) > Best regards > Dirk > > > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von Behcet Sarikaya > Gesendet: Montag, 5. Dezember 2011 23:02 > An: multimob@ietf.org > Betreff: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 > > Hello all, > There was consensus on the source mobility solution draft in Taipei. > This mail is to confirm the consensus. > > > This document can be found at: > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt > > This mail starts a WG adoption call on this draft. > > The intended status for this document is proposed standard. > If adopted, the draft will be named: > > draft-ietf-multimob-pmipv6-source-mobility. > > Please your comments by December 12, 2011. > > > Chairs > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- 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 lmcm@tid.es Wed Dec 7 08:45: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 4A29F21F8C34 for ; Wed, 7 Dec 2011 08:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-3.300, 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 wC0Dlmecx4Gm for ; Wed, 7 Dec 2011 08:45:32 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id E501A21F8C18 for ; Wed, 7 Dec 2011 08:45:30 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVU003RBEJTWT@tid.hi.inet> for multimob@ietf.org; Wed, 07 Dec 2011 17:45:29 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 22.5F.04893.1A3AFDE4; Wed, 07 Dec 2011 18:34:25 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LVU003R4EJSWT@tid.hi.inet> for multimob@ietf.org; Wed, 07 Dec 2011 17:45:29 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Wed, 07 Dec 2011 17:45:28 +0100 Date: Wed, 07 Dec 2011 17:45:27 +0100 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <20111111.192321.79370633.asaeda@sfc.wide.ad.jp> To: Hitoshi Asaeda , "contreras.uc3m@gmail.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [multimob] comments for draft-contreras-multimob-rams-03 Thread-index: AcygW/95NOub3xQfTIqpeUxynG6N8QUoR5HQ acceptlanguage: es-ES, en-US X-AuditID: 0a5f4068-b7f4c6d00000131d-be-4edfa3a11b4a X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsXCFe/Apbtw8X0/gzUbdCxmfOxjcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRv/POewFs4Iqbh84xdzA2BPQxcjJISFgIvH8djMbhC0mceHe eiCbi0NIYAOjxNmpH5ghnN+MEt9PdjNCOI2MEr1z/7KAtLAIqEp0/vjBCGKzCRhKzNo5ibWL kYNDWMBV4sn3WJAwp4CtxKGfl8FKRASSJd6eWcYEYjMLaEtM+7eIGcTmFfCUON7+gg3CFpT4 MfkeC8gYZgF1iSlTciHKxSXm/JrICmErSkxb1AA2klFAVmLl+dNQ490kns1awgphG0l8bvwK VSMj8X/5XhaIJwUkluw5zwxhi0q8fPyPFeKt7YwSm6b8Y53AKD4LyRmzEM6YheSMWUjOWMDI sopRrDipKDM9oyQ3MTMn3cBQLyNTLzMvtWQTIySKMnYwLt+pcohRgINRiYfXIO2enxBrYllx Ze4hRkkOJiVRXr5p9/2E+JLyUyozEosz4otKc1KLDzFKcDArifA2gOR4UxIrq1KL8mFSMhwc ShK83iApwaLU9NSKtMwcYKqASTNxcIK08wC114G1Fxck5hZnpkPkTzGqcux6NekMoxBLXn5e qpQ4rzZIkQBIUUZpHtycV4ziQAcLQ1zAA0x2cBNeAQ1nAhrOF3UXZHhJIkJKqoFxis1k06V5 72O6s+49yj38ONvgUmnppI4qhzNfZzELST5KTotTMYoIvKJ19MzinMXtsmLdr/a5xa0p2b6Y Q6b4ZOfN3SWp//gZHj37qqQ6NVB9yQ/bUyty/nBN9u9UEWL+w2ZqvPHRRpV3GvdO+NU/Oyt1 ty3jPcvJH+cCM2KvVnNsS1344qmjEktxRqKhFnNRcSIAOnRNPTMDAAA= References: <20111108.162947.166997496.asaeda@sfc.wide.ad.jp> <20111111.192321.79370633.asaeda@sfc.wide.ad.jp> Cc: "multimob@ietf.org" Subject: Re: [multimob] comments for draft-contreras-multimob-rams-03 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, 07 Dec 2011 16:45:33 -0000 SGkgSGl0b3NoaSwNCg0KSSdtIHZlcnkgc29ycnkgZm9yIG15IGxvbmcgc2lsZW5jZS4NCg0KUGxl YXNlLCBmaW5kIGFuc3dlcnMgYmVsb3cuDQoNCi0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQpE ZTogbXVsdGltb2ItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm11bHRpbW9iLWJvdW5jZXNAaWV0 Zi5vcmddIEVuIG5vbWJyZSBkZSBIaXRvc2hpIEFzYWVkYQ0KRW52aWFkbyBlbDogdmllcm5lcywg MTEgZGUgbm92aWVtYnJlIGRlIDIwMTEgMTE6MjMNClBhcmE6IGNvbnRyZXJhcy51YzNtQGdtYWls LmNvbQ0KQ0M6IG11bHRpbW9iQGlldGYub3JnDQpBc3VudG86IFJlOiBbbXVsdGltb2JdIGNvbW1l bnRzIGZvciBkcmFmdC1jb250cmVyYXMtbXVsdGltb2ItcmFtcy0wMw0KDQpIaSBMdWlzLA0KDQpU aGFuayB5b3UgZm9yIHlvdXIgcmVwbHkuDQpDYW4gSSBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBh IGxpdHRsZSBtb3JlPw0KDQo+PiBJbiB0aGlzIGRyYWZ0IHRoZSBhdXRob3JzIHByb3Bvc2UgInBy b2FjdGl2ZSIgaGFuZG92ZXIgYW5kICJyZWFjdGl2ZSINCj4+IGhhbmRvdmVyLCBidXQgaXQgd2Fz IGRpZmZpY3VsdCB0byB1bmRlcnN0YW5kIHRoZSBiZW5lZml0IG9mIHRoZQ0KPj4gZXh0ZW5zaW9u IGZvciByZWFjdGl2ZSBoYW5kb3Zlciwgb3IgaG93IHRoZSBwcm9wb3NlZCByZWFjdGl2ZQ0KPj4g aGFuZG92ZXIgYWNjZWxlcmF0ZXMgaGFuZG92ZXIuDQo+DQo+IFRoZSBjb21wYXJpc3NvbiBoYXMg dG8gYmUgZG9uZSB3aXRoIHRoZSByZWFjdGl2ZSBjYXNlIGluIFJGQzYyMjQuVGhlcmUNCj4gdGhl IG5NQUcgaXMgYXdhcmUgb2YgdGhlIGVudGVyaW5nIE1OIHN1YnNjcmlwdGlvbiBvbmNlIGl0IHJl Y2VpdmVzIHRoZQ0KPiBNTEQgUmVwb3J0IGZyb20gdGhlIE1OLCBhcyBhIHJlcGx5IG9mIHRoZSBN TEQgUXVlcnkgc2VudCBieSB0aGUgbk1BRw0KPiBvbmNlIHRoZSBsaW5rIHdhcyBzZXQgdXAuDQoN Ck1MRCBRdWVyeSBpcyAqbm90IGFsd2F5cyogdHJpZ2dlcmVkIGJ5IE1MRCBSZXBvcnQuIEl0IGRl cGVuZHMgb24gdGhlIFJlcG9ydCB0eXBlIGFuZCB0aGUgc3RhdGUgbWFpbnRhaW5lZCBieSB0aGUg cm91dGVyLg0KQnV0IGl0IGlzIG5vdCB0aGUgcG9pbnQgb2Ygb3VyIGN1cnJlbnQgZGlzY3Vzc2lv biwgc28gc2tpcCB0aGlzLg0KDQpbTHVpcz4+XSAoSSdtIG5vdCBzdXJlIGlmIEkgdW5kZXJzdGFu ZCB5b3VyIHBvaW50KSBXZWxsLCBpbiB0aGUgY2FzZSBJJ20gcmVmZXJyaW5nIHRvLCB0aGUgbk1B RyBzZW5kcyBhbiBNTEQgUXVlcnkgYmVjYXVzZSBpdCBkZXRlY3RzIGEgbmV3IGxpbmsgaXMgdXAg KG5vcm1hbCBwcm9jZWR1cmUgZm9yIE1MRCBlbmFibGVkIGRldmljZXMpOyB0aGlzIGlzIGNvbnNl cXVlbmNlIG9mIHRoZSBNTiBhdHRhY2hpbmcgdG8gdGhlIG5NQUcuIE9uY2UgdGhlIE1OIHJlY2Vp dmVzIHRoZSBRdWVyeS4gSXQgd2lsbCBwcm9jZXNzIGFuIGFuc3dlciBpbiB0aGUgZm9ybSBvZiBh biBNTEQgUmVwb3J0LiBUaGlzIGlzIHRoZSB3YXkgdGhlIG5NQUcgZGlzY292ZXJzIHRoZSBzdWJz Y3JpcHRpb24gaWYgZm9sbG93aW5nIHRoZSByZmM2MjI0IHByb2NlZHVyZS4NCg0KPiBUaGUgdGlt ZSBjb25zaWRlcmVkIGluIHRoZSBNTEQgUXVlcnkgdHJhbnNmZXIgaW4gdGhlIHJhZGlvIGxpbmsN Cj4gKGluY2x1ZGluZyBmcmFtaW5nLCByYWRpbyBhY2Nlc3MgZGVsYXksIC4uLiksIHBsdXMgdGhl IHRpbWUgdGFrZW4gYnkNCj4gdGhlIE1OIHRvIHByb2Nlc3MgYW5kIGFuc3dlciB0aGUgTUxEIFF1 ZXJ5IChjb25kaXRpb25lZCBieSB0aGUgUXVlcnkNCj4gUmVzcG9uc2UgaW50ZXJ2YWwpLCBwbHVz IHRoZSBNTEQgUmVwb3J0IGdvaW5nIGJhY2sgdGhyb3VnaCB0aGUgcmFkaW8NCj4gY2hhbm5lbCB0 byB0aGUgbk1BRywgaXMgaGlnaGVyIHRoYW4gdGhlIHRpbWUgdGFrZW4gb24gYXNraW5nIHRoZSBw TUFHLA0KPiB3aGljaCBtYWludGFpbnMgdGhlIG11bHRpY2FzdCBzdWJzY3JpcHRpb24gb2YgdGhl IE1OIGJlY2F1c2Ugd2UgYXJlIGluIHRoZSByZWFjdGl2ZSBjYXNlLg0KPg0KPiBXZSBoYXZlIHRy eSB0byBtb2RlbCB0aGlzIGluIHRoZSBmb2xsb3dpbmcgcGFwZXI6DQo+IGh0dHA6Ly9pc3lvdS5p bmZvL2pvd3VhL3BhcGVycy9qb3d1YS12Mm4yLTUucGRmDQoNCkkgdG9vayBhIGxvb2sgYXQgdGhp cyBwYXBlci4NCkNvbXBhcmluZyB3aXRoIEZpZy43IChwcm9hY3RpdmUpIGFuZCA4IChyZWFjdGl2 ZSksIHRoZSB0aW1lIGRpZmZlcmVuY2UgaXMgd2l0aCAiVGFjcSIuIFRoZSB0aW1lIGZvciByZWFj dGl2ZSBoYW5kb3ZlciBhbHdheXMgYWRkcyBUYWNxIHRpbWUgdG8gdGhlIG9uZSBmb3IgcHJvYWN0 aXZlIGhhbmRvdmVyLCBoZW5jZSBpdCdzIGFsd2F5cyBsb25nZXIsIGlzbid0IGl0Pw0KDQpbTHVp cz4+XSBPZiBjb3Vyc2UsIHRoZSByZWFjdGl2ZSBjYXNlIGlzIGFsd2F5cyBsb25nZXIgdGhhbiB0 aGUgcHJvYWN0aXZlIGNhc2UuIEluIHRoZSBwcm9hY3RpdmUgY2FzZSB0aGUgc3Vic2NyaXB0aW9u IGluZm9ybWF0aW9uIChvciBjb250ZXh0KSBpcyBwaWdneWJhY2tlZCBpbiB0aGUgbm9ybWFsIHJl Z2lzdHJhdGlvbiBhbmQgZGUtcmVnaXN0cmF0aW9uIHByb2NldWRyZXMuIEluIHRoZSByZWFjdGl2 ZSBjYXNlIGl0IGlzIG5lY2Vzc2FyeSB0byBpbnRlcnJvZ2F0ZSB0aGUgcE1BRyB0byBvYnRhaW4g c3VjaCBpbmZvcm1hdGlvbi4NCg0KDQo+IFRoZSBzYXZpbmdzIGR1ZSB0byBSQU1TIGFwcGx5IG5v dCBvbmx5IHRvIFJGQzYyMjQsIGJ1dCB0byBhbnkgb3RoZXINCj4gc29sdXRpb24gd2hpY2ggY291 bGQgZGVwZW5kIG9uIHRoZSBhbnN3ZXIgb2YgdGhlIE1OIHRvIHRoZSBNTEQgUXVlcnkNCj4gc2Vu dCBieSB0aGUgbk1BRy4NCg0KTWF5YmUuIEJ1dCBteSBxdWVzdGlvbiBpcywgaW4gd2hhdCBraW5k IG9mIHNpdHVhdGlvbiAob3Igd2hhdCBpcyB0aGUgdXNlIGNhc2UgdGhhdCkgeW91ciByZWFjdGl2 ZSBoYW5kb3ZlciBpcyB1c2VmdWwsIG9yIGZhc3RlciB0aGFuIHByb2FjdGl2ZSBoYW5kb3Zlcj8N Cg0KW0x1aXM+Pl0gVGhlIHJlYWN0aXZlIGNhc2UgaXMgYWx3YXlzIGxvbmdlciB0aGFuIHRoZSBw cm9hY3RpdmUuIEJ1dCBib3RoIGNhc2VzIGFyZSBmZWFzaWJsZS4gSWYgdGhlIE1OIHNpZ25hbHMg dGhlIGRlLXJlZ2lzdHJhdGlvbiBiZWZvcmUgZW50ZXJpbmcgYSBuTUFHLCB0aGVuIHdlIGhhdmUg dGhlIHByb2FjdGl2ZSBjYXNlLiBPbiB0aGUgY29udHJhcnksIGlmIHRoZSBNTiBhdHRhY2hlcyBh IG5NQUcgd2l0aG91dCBhIHByZXZpb3VzIGRlLXJlZ2lzdHJhdGlvbiBvZiB0aGUgcE1BRywgd2Ug dGhlbiBoYXZlIGEgcmVhY3RpdmUgY2FzZS4gQm90aCBzaXR1YXRpb25zIGNhbiBoYXBwZW4gZHVy aW5nIHRoZSBsaWZldGltZSBvZiBhIGNvbW11bmljYXRpb24sIGFuZCBib3RoIGhhdmUgZGlmZmVy ZW50IHBlcmZvcm1hbmNlLg0KDQo+PiBSZWdhcmRpbmcgdGhlIHJlYWN0aXZlIGhhbmRvdmVyLCBz ZWN0LjQuMi4xIHNheXM7ICAiQWZ0ZXIgcmVjZWl2aW5nDQo+PiB0aGUgUEJVIG1lc3NhZ2UgZnJv bSB0aGUgbk1BRywgdGhlIExNQSB3aWxsIHRha2UgdGhlDQo+PiAgIGRlY2lzaW9uIG9mIGludGVy cm9nYXRpbmcgb3Igbm90IHRoZSBwTUFHIHJlZ2FyZGluZyBhbnkgZXhpc3RpbmcNCj4+ICAgbXVs dGljYXN0IHN1YnNjcmlwdGlvbiBmb3IgdGhhdCBNTi4NCj4+ICAgT25jZSB0aGUgbXVsdGljYXN0 IHN1YnNjcmlwdGlvbiBpbmZvcm1hdGlvbiBpcyByZXRyaWV2ZWQgZnJvbSB0aGUNCj4+ICAgcE1B RywgdGhlIExNQSBlbmNhcHN1bGF0ZXMgaXQgaW4gdGhlIFBCQSBtZXNzYWdlIGJ5IHVzaW5nIHRo ZSBUTFYNCj4+ICAgb3B0aW9uICJBY3RpdmUgTXVsdGljYXN0IFN1YnNjcmlwdGlvbiIsIGFuZCBm b3J3YXJkcyB0aGUgUEJBIG1lc3NhZ2UNCj4+ICAgdG8gdGhlIG5NQUcuIFRoZW4sIHRoZSBuTUFH IGNhbiBzdWJzY3JpYmUgdGhlIG11bHRpY2FzdCBmbG93IG9uDQo+PiAgIGJlaGFsZiBvZiB0aGUg TU4sIGlmIHRoZXJlIGlzIG5vIG90aGVyIE1OIHJlY2VpdmluZyBpdCBhbHJlYWR5IGF0IHRoZQ0K Pj4gICBuTUFHLiINCj4+IEhvd2V2ZXIsIHRoZSByZWFjdGl2ZSBoYW5kb3ZlciBleHBsYWluZWQg aW4gc2VjdGlvbiA0IHJlcXVpcmVzDQo+PiBleGNoYW5naW5nIG1hbnkgbWVzc2FnZXMgYW5kIGNv bXBsZXggcHJvY2VkdXJlcywgYW5kIEkgY2Fubm90IGZpbmQNCj4+IHRoZSBiaWcgYWR2YW50YWdl IG9mIHByb3ZpZGluZyBzdWNoIGV4dGVuc2lvbi4NCj4NCj4gTGV0IG1lIGV4cGxhaW4gaW4gZmV3 IHdvcmRzLiBUd28gYXJlIHRoZSBwcm9jZXNzZXMgaW52b2x2ZWQ6DQo+DQo+IDEvIFdoZW4gYW4g TU4gbWFpbnRhaW5zIGFuIGFjdGl2ZSBzdWJzY3JpcHRpb24sIGEgZmxhZyBpcyBtYWludGFpbmVk DQo+IGluIHRoZSBMTUEgaW5kaWNhdGluZyB0aGF0IChpdCBpcyBub3QgcmVsZXZhbnQgdGhlIGNo YW5uZWwgc3Vic2NyaWJlZCwNCj4gYmVjYXVzZSB0aGlzIGlzIGR5bmltaWM7IGl0IGlzIG9ubHkg cmVsZXZhbnQgdGhhdCB0aGUgTU4gaGFzIGFuIGFjdGl2ZQ0KPiBzdWJzY3JpcHRpb24pDQoNCkkg bWF5IG5vdCB1bmRlcnN0YW5kIHRoaXMuDQpXaGVuZXZlciBNTiBzdWJzY3JpYmVzIHNvbWUgY2hh bm5lbHMsIHBNQUcgc2VuZHMgRGVSZWcgUEJVIGluY2x1ZGluZyB0aGUgc3Vic2NyaXB0aW9uIGlu Zm9ybWF0aW9uICgqKSB0byBMTUEsIGFuZCBMTUEgdHJhbnNmZXJzIGl0IHRvIG5NQUcgdmlhIFBC QSBpbmNsdWRpbmcgdGhlIHN1YnNjcmlwdGlvbiBpbmZvcm1hdGlvbiAoKikuIFRoZW4gbk1BRyBv cGVyYXRlcyB0byBmb3J3YXJkIGRhdGEgdG8gdGhlIE1OIGlmIG5lZWRlZC4NCldoeSBhbm90aGVy ICJhY3RpdmUiIGZsYWcgYW5kIG1lc3NhZ2UgdHJhbnNtaXNzaW9uIGlzIG5lZWRlZD8NCg0KKCop IFRoaXMgbWVzc2FnZSBleHRlbnNpb24gaXMgbmVlZGVkLiBJbiBteSBQTUlQdjYgZXh0ZW5zaW9u IGRyYWZ0LCBQQlUtTSBhbmQgUEJBLU0gYXJlIGRlZmluZWQgZm9yIGVhY2guDQoNCltMdWlzPj5d IEkgdGhpbmsgd2UgaGF2ZSB0byBpbXByb3ZlIHRoZSB0ZXh0IG9mIHRoZSBwcm9wb3NhbCBpbiBv cmRlciB0byBtYWtlIGl0IGNsZWFyLiBUaGUgZmxhZyBmb3IgYWN0aXZpdHkgaW5kaWNhdGlvbiBp cyBuZWVkZWQgb25seSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBNTiBtYWludGFpbnMgYW4gYWN0aXZl IHN1YnNjcmlwdGlvbi4gVGhhdCBmbGFnIGlzIHN0b3JlZCBpbiB0aGUgTE1BIChpdCBjb3VsZCBi ZSBhbHNvIHN0b3JlZCBpbiB0aGUgcHJvZmlsZSkuIFRoaXMgZmxhZyBpcyBhY3RpdmF0ZWQgb25j ZSB0aGUgTU4gcmVxdWVzdCBhIGNoYW5uZWwgZm9yIGZpcnN0IHRpbWUgKGUuZy4sIGJ5IG1lYW5z IG9mIGFuIE1MRCBSZXBvcnQpLiBBbiBzdGF0aW9uYXJ5IE1OIHdoaWNoIGNoYW5nZSBpdHMgc3Vi c2NyaXB0aW9uIHJlcXVlc3RpbmcgYSBkaWZmZXJlbnQgY2hhbm5lbCBkb2VzIG5vdCBpbnRyb2R1 Y2UgbmV3IHNpZ25hbGluZy4gQW55dGhpbmcgY2hhbmdlcy4gVGhlIGZsYWcgY29udGludW91cyB0 byBiZSBzZXQgdXAuIE9uY2UgdGhlIE1OIGNoYW5nZXMgZnJvbSBwTUFHIHRvIG5NQUcgaXMgd2hl biBlaXRoZXIgdGhlIHJlYWN0aXZlIG9yIHRoZSBwcm9hY3RpdmUgbWVjaGFuaXNtcyB0YWtlIHBs YWNlLiBBbmQgdGhlc2UgbWVjaGFuaXNtcyBhcmUgaW50cm9kdWNlZCB0byB0cmFuc2ZlciB0aGUg c3Vic2NyaXB0aW9uIGluZm9ybWF0aW9uLiBIb3BlIGl0IGlzIG1vcmUgY2xlYXIgbm93Lg0KDQo+ IDIvIFdoZW4gdGhlIE1OIG1vdmVzIHRvIGEgbmV3IGFjY2VzcyBuZXR3b3JrLCBhcyBjb25zZXF1 ZW5jZSBvZiB0aGUNCj4gcmVnaXN0cmF0aW9uIHByb2Nlc3MgYXQgdGhlIG5NQUcsIHRoZSBMTUEg Y2hlY2tzIHRoZSBmbGFnLCBhbmQgaW4gY2FzZQ0KPiB0aGUgZmxhZyBpcyBzZXQsIGl0IHJlcXVl c3QgdG8gdGhlIHBNQUcgdGhlIHN1YnNjcmlwdGlvbiBpbmZvcm1hdGlvbg0KPiAoSVAgYWRkcmVz c2VzIG9mIHRoZSBzb3VyY2UgYW5kIHRoZSBtdWx0aWNhc3QgZ3JvdXApIHRvIGJlIHBhc3NlZCB0 bw0KPiB0aGUgbk1BRywgY29tcGxldGluZyB0aGUgcmVnaXN0cmF0aW9uLiAoSW4gY2FzZSB0aCBm bGFnIGlzIG5vdCBzZXQgdXAsDQo+IG1lYW5pbmcgdGhhdCB0aGVyZSBpcyBubyBhY3RpdmUgc3Vi c2NyaXB0aW9uLCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MNCj4gaXMgZG9uZSBhcyBpbg0KPiBS RkM1MjEzKQ0KDQpXaGV0aGVyIHRoZSBNTiBzdWJzY3JpYmVzIHNvbWUgY2hhbm5lbCBvciBub3Qs IExNQSBnZXRzIERlUmVnIFBCVS4NCklmIERlUmVnIFBCVSBpbmNsdWRlcyBNTidzIHN1YnNjcmlw dGlvbiBpbmZvLCBMTUEgZG9lcyBub3QgbmVlZCB0byBuZXdseSBhc2sgdGhlIE1OJ3Mgc3Vic2Ny aXB0aW9uIGluZm9ybWF0aW9uLg0KV2h5IGFkZGl0aW9uYWwgbWVzc2FnZSBmb3IgdHJhbnNtaXR0 aW5nIHRoZSBzdWJzY3JpcHRpb24gaW5mbyBtdXN0IGJlIGRlZmluZWQ/DQoNCltMdWlzPj5dIFRo ZSBuZXcgbWVzc2FnZSBpcyBuZWVkZWQgaW4gdGhlIHJlYWN0aXZlIGNhc2UsIGJlY2F1c2UgdGhl cmUgaXMgbm8gcHJldmlvdXMgZGUtcmVnaXN0cmF0aW9uIGZyb20gcE1BRyAodGhlIExNQSByZWdp c3RlcnMgdGhhdCB0aGUgTU4gaXMgeWV0IGFuY2hvcmVkIHRvIHBNQUcpDQoNCg0KPiBIb3BlZnVs bHkgbm93IGlzIGJldHRlciB1bmRlcnN0b29kLg0KDQpJIHRoaW5rIEkgdW5kZXJzdGFuZCB0aGUg cHJvY2VkdXJlIHlvdSBkZWZpbmVkLiBCdXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB5b3VyIHJl YWN0aXZlIGhhbmRvdmVyIHByb2NlZHVyZSBzaG91bGQgYmUgZGVmaW5lZCBhcyB3ZWxsIGFzIHRo ZSBwcm9hY3RpdmUgaGFuZG92ZXIuDQpJcyB0aGVyZSBhbnkgdGVjaG5pY2FsIHJlYXNvbj8gT3Ig dGhlcmUgaXMgc29tZSBjb25maWd1cmF0aW9uIG9yIHBvbGljeSByZXF1aXJlbWVudCBJIG1pc3Nl ZD8NCg0KW0x1aXM+Pl0gSSBob3BlIG5vdyBpcyBtb3JlIGNsZWFyLiBJZiBub3QsIHBsZWFzZSBs ZXQgbWUga25vdy4gSSdsbCB0cnkgdG8gYW5zd2VyIHF1aWNrZXIuIEFueXdheSBJIHNlZSB0aGF0 IHRoZSB0ZXh0IG9mIHRoZSBwcm9wb3NhbCBzaG91bGQgYmUgc2V2ZXJlbHkgaW1wcm92ZWQgdG8g bWFrZSBpdCBtb3JlIGNsZWFyLg0KQmVzdCByZWdhcmRzLA0KDQpMdWlzDQoNCg0KUmVnYXJkcywN Ci0tDQpIaXRvc2hpIEFzYWVkYQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm11bHRpbW9iIG1haWxpbmcgbGlzdA0KbXVsdGltb2JAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2INCg0KRXN0ZSBtZW5z YWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29u c3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVv IGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNz YWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNl bmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0 Lg0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From asaeda@sfc.wide.ad.jp Thu Dec 8 00:56: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 E439121F8AF3 for ; Thu, 8 Dec 2011 00:56:53 -0800 (PST) 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 Zprsok0Hv9La for ; Thu, 8 Dec 2011 00:56:53 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA2421F8AB9 for ; Thu, 8 Dec 2011 00:56:53 -0800 (PST) Received: from localhost (dhcp-143-200.sfc.wide.ad.jp [203.178.143.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id EE1822780B4; Thu, 8 Dec 2011 17:56:48 +0900 (JST) Date: Thu, 08 Dec 2011 17:56:48 +0900 (JST) Message-Id: <20111208.175648.98542654.asaeda@sfc.wide.ad.jp> To: lmcm@tid.es From: Hitoshi Asaeda In-Reply-To: References: <20111111.192321.79370633.asaeda@sfc.wide.ad.jp> 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] comments for draft-contreras-multimob-rams-03 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, 08 Dec 2011 08:56:54 -0000 Hi Luis, Thank you for your reply. I understand most of the points. >> 1/ When an MN maintains an active subscription, a flag is maintained >> in the LMA indicating that (it is not relevant the channel subscribed, >> because this is dynimic; it is only relevant that the MN has an active >> subscription) > > I may not understand this. > Whenever MN subscribes some channels, pMAG sends DeReg PBU including > the subscription information (*) to LMA, and LMA transfers it to > nMAG via PBA including the subscription information (*). Then nMAG > operates to forward data to the MN if needed. > Why another "active" flag and message transmission is needed? > > (*) This message extension is needed. In my PMIPv6 extension draft, > PBU-M and PBA-M are defined for each. > >> [Luis>>] I think we have to improve the text of the proposal in >> order to make it clear. The flag for activity indication is needed >> only to indicate that the MN maintains an active subscription. That >> flag is stored in the LMA (it could be also stored in the >> profile). This flag is activated once the MN request a channel for >> first time (e.g., by means of an MLD Report). An stationary MN >> which change its subscription requesting a different channel does >> not introduce new signaling. Anything changes. The flag continuous >> to be set up. Once the MN changes from pMAG to nMAG is when either >> the reactive or the proactive mechanisms take place. And these >> mechanisms are introduced to transfer the subscription >> information. Hope it is more clear now. I'd like to read the improved text for this extension in the revised draft as there may be some question about the active flag. Thanks for your effort. Regards, -- Hitoshi Asaeda From sarikaya2012@gmail.com Thu Dec 8 12:53:34 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 25A0121F8ADE for ; Thu, 8 Dec 2011 12:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, 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 vEqC6GL6b-KS for ; Thu, 8 Dec 2011 12:53:33 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77421F8ACE for ; Thu, 8 Dec 2011 12:53:30 -0800 (PST) Received: by yenm7 with SMTP id m7so2072968yen.31 for ; Thu, 08 Dec 2011 12:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=RmGF+/Hfhh34iAawGqoygwbf0iRw8UglD4CMyAoDVpA=; b=tDVqs41KgIaHZPk4J7+YS7hWzoM93WArlL5q73HsdmXGPz8Ij5eq71pMOua0hFdATp Js57qNJoeEB89+wMjCGFLSvrPcO7VVm3e1gRhZ90EHe2dqw2hnUT2yRYlLU88+LpQDNH m286IvlFQDb7yZdi3YKBgkC7BgH2I9A5mLzpQ= MIME-Version: 1.0 Received: by 10.236.174.3 with SMTP id w3mr7332492yhl.117.1323377610015; Thu, 08 Dec 2011 12:53:30 -0800 (PST) Received: by 10.236.125.201 with HTTP; Thu, 8 Dec 2011 12:53:29 -0800 (PST) Date: Thu, 8 Dec 2011 14:53:29 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:53:34 -0000 Hello all, There was consensus on the tunnel convergence solution draft in Taipei. This mail is to confirm the consensus. This document can be found at: http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt This mail starts a WG adoption call on this draft. The intended status for this document is proposed standard. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-tunnel-convergence. Please your comments by December 15, 2011. Chairs From asaeda@sfc.wide.ad.jp Thu Dec 8 16:07:44 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 1BEEE11E8089 for ; Thu, 8 Dec 2011 16:07:44 -0800 (PST) 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 iSgR9bS99-jS for ; Thu, 8 Dec 2011 16:07:43 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4F61911E807F for ; Thu, 8 Dec 2011 16:07:43 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0FC21278085 for ; Fri, 9 Dec 2011 09:07:40 +0900 (JST) Date: Fri, 09 Dec 2011 09:07:39 +0900 (JST) Message-Id: <20111209.090739.138669235.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: References: 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 Subject: Re: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 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: Fri, 09 Dec 2011 00:07:44 -0000 Hello, > =A0 There was consensus=A0on the source mobility solution draft in Ta= ipei. > This mail is to confirm the consensus. > = > = > This document can be found at: > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt > = > This mail starts a WG adoption call on this draft. > = > The intended status for this document is proposed standard. > If adopted, the draft will be named: > = > draft-ietf-multimob-pmipv6-source-mobility. > = > Please your comments by December 12, 2011. 1. The goal of this document is unclear. It seems that it focuses on both the MLD proxy type MAG and the PIM support. But there is no description about PIM support. See section 5. It just says "TODO" for both PIM-SM and Bidir PIM. It is impossible to understand anything from this condition. Moreover, this draft does not consider multicast routing functions on MAG. Except incomplete section5, only in section 1, it says; "Alternate solutions leverage performance optimization by providing multicast routing at the access routers directly, or by other dedicated schemes." I'd suggest that this draft just focuses on the source mobility only for rfc6224 and clearly mentions it. Title should be also changed as the current one is too broad. 2. With the regular MLD proxy (rfc4605), multicast packets sent from a host that attaches to the downstream link of an MLD proxy can be forwarded to both the downstream and upstream links. The problem for source mobility in rfc6224 is that multicast packets sent by MN should be directed to eliminate detour of the packets in case of MNs not charing MAG and/or LMA in some case and should not be directed in other cases, according to operators' policy. This scenario should be also considered when multiple MLD proxy instances are enabled in a MAG. Addressing this issue is the main contribution of source mobility for rfc6224. However, there is no detail discussion about it in section 6.1 and no solution defined at all. Section 6.1 only says "TODO datails" at the end. 3. There is no source handover discussion. A source mobility draft should be also described it with appropriate scenarios and data flows. According to these considerations, it is too early to decide that this draft is adopted. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Thu Dec 8 16:31: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 82D481F0C38 for ; Thu, 8 Dec 2011 16:31:53 -0800 (PST) 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 W0sjUtB094RO for ; Thu, 8 Dec 2011 16:31:53 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 019D11F0C36 for ; Thu, 8 Dec 2011 16:31:53 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E80C52780A5; Fri, 9 Dec 2011 09:31:48 +0900 (JST) Date: Fri, 09 Dec 2011 09:31:48 +0900 (JST) Message-Id: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, sarikaya2012@gmail.com From: Hitoshi Asaeda In-Reply-To: References: 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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 09 Dec 2011 00:31:53 -0000 Behcet, > There was consensus on the tunnel convergence solution draft in Taipei. > This mail is to confirm the consensus. > > > This document can be found at: > http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt > > This mail starts a WG adoption call on this draft. > > The intended status for this document is proposed standard. > If adopted, the draft will be named: > > draft-ietf-multimob-pmipv6-tunnel-convergence. > > Please your comments by December 15, 2011. I don't think there was any consensus about adoption of this draft at the last meeting. We've proposed the tunnel convergence problem solution draft; draft-asaeda-multimob-pmip6-extension-07 Why you eliminate the discussions in the meeting and the chance to discuss in the mailing list? Before explaining the thoughts about draft-zuniga draft, I'd make you understand the situation of our draft. 1. I think Thomas always misunderstands the point. MAG is a router and has its own RIB. PIM can use its RIB and can copy it to its MRIB. When we need to define dedicate multicast routes, we can configure the ones. We do not need PMIPv6-based policy routing for RPF check. After the last meeting I understand Thomas's misinterpretation comes from this. I will clearly emntion it in the revised version. 2. My -06 draft defines GRE type M-Tunnel to define MAG's upstream IF to distinguish the regular IPv6 tunnel. But according to the previous discussion in the ML, we eliminate the way to distinguish unicast and multicast tunnels to make the story simple in -07 draft. But I recognized this elimination was not always correct, because we cannot assume that a unocast route toward sources outside of PMIPv6 domain defined in MAG's RIB always goes through the regular IPv6 tunnel. Therefore GRE type M-Tunnel will be recalled from -06 to the revision -08. 3. One important discussion missing in -06 is the way to select a single M-Tunnel when multiple M-Tunnels are configured for the same (S,G) or (*,G). This can be addressed in the revised draft, too. For your question, I don't think draft-zuniga-multimob-pmipv6-ropt-01.txt should be adopted now. Regards, -- Hitoshi Asaeda From multimob2011@gmail.com Thu Dec 8 18:52:42 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 0C9C121F8484 for ; Thu, 8 Dec 2011 18:52:42 -0800 (PST) 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 wuZ0dDU3LPbv for ; Thu, 8 Dec 2011 18:52:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7168521F8467 for ; Thu, 8 Dec 2011 18:52:40 -0800 (PST) Received: by iaek3 with SMTP id k3so4068019iae.31 for ; Thu, 08 Dec 2011 18:52:40 -0800 (PST) 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 :content-type; bh=q1PXty8XGK76kTJO2amEYwsWvJsnLClVuWsluYNrfRY=; b=lTQrcnwGM4jDQ7xv309sYE71NZNJqv48sMLPdbBpwFOPQPzZZAuQUNvsmv0Jffcu3u xnblPg4fPUKpx2q+wdKmo3FwT3lCEmuU9DqdYm+GHOJz3b8OzZ0LAiPDMK9TAoh/xdKu vegUHqA5pbOLAIQDbwt6Y6++c6rbW1pSbCtdI= MIME-Version: 1.0 Received: by 10.50.196.196 with SMTP id io4mr1578246igc.55.1323399160064; Thu, 08 Dec 2011 18:52:40 -0800 (PST) Received: by 10.50.220.197 with HTTP; Thu, 8 Dec 2011 18:52:40 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Dec 2011 10:52:40 +0800 Message-ID: From: Aaron Feng To: multimob@ietf.org Content-Type: multipart/alternative; boundary=14dae93407d3d4eb4204b39fe0eb Subject: Re: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 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: Fri, 09 Dec 2011 02:52:42 -0000 --14dae93407d3d4eb4204b39fe0eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think draft-schm=E2=80=8Bidt-multim=E2=80=8Bob-pmipv6-=E2=80=8Bsource-00 = can be adopted as wg ID, though it still needs some extensions to optimize. In BIDIR PIM 1) there's no need to check whether the source is directly connected, which is suitable for moilbe scenario. 2) If there are only receivers on branches of the network between the source and the RP in PIM SM, traffic will also only flow toward the RP up to that branching point, but not further on toward the RP, which may contribute to local routhing. Therefore, BIDIR PIM may be another hint. Best Regards, Aaron --14dae93407d3d4eb4204b39fe0eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I=C2=A0think=C2=A0draft-schm=E2=80=8Bidt-multim=E2=80=8Bob-pmipv6-= =E2=80=8Bsource-00=C2=A0can=C2=A0be=C2=A0adopted=C2=A0as=C2=A0wg=C2=A0ID,= =C2=A0though=C2=A0it still needs some extensions to optimize.=C2=A0
In BIDIR PIM
1) there's no need to check whether the source is directly connect= ed, which is suitable for moilbe scenario.
2) If there are only receivers on branches of the network between the = source and the RP in PIM SM, traffic will also only flow toward the RP up t= o that branching point, but not further on toward the RP, which may contrib= ute to local routhing.=C2=A0
Therefore, BIDIR PIM=C2=A0may be another=C2=A0hint.=C2=A0=C2=A0=C2=A0= =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Best= Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Aaron=C2= =A0
--14dae93407d3d4eb4204b39fe0eb-- From prvs=317cfe919=schmidt@informatik.haw-hamburg.de Thu Dec 8 22:33:54 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 3EEBA21F84B8 for ; Thu, 8 Dec 2011 22:33:54 -0800 (PST) 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 Bprpo6KQz2hg for ; Thu, 8 Dec 2011 22:33:53 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id EF63121F84B9 for ; Thu, 8 Dec 2011 22:33:52 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 09 Dec 2011 07:33:31 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id D4ADF102C0C7; Fri, 9 Dec 2011 07:33:31 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07770-01; Fri, 9 Dec 2011 07:33:31 +0100 (CET) Received: from [172.17.192.67] (75-148-178-225-Houston.hfc.comcastbusiness.net [75.148.178.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 83AC61039E84; Fri, 9 Dec 2011 07:33:30 +0100 (CET) Message-ID: <4EE1ABC3.4010208@informatik.haw-hamburg.de> Date: Fri, 09 Dec 2011 00:33:39 -0600 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> In-Reply-To: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org, sarikaya2012@gmail.com Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 09 Dec 2011 06:33:54 -0000 Hi Hitoshi, On 08.12.2011 18:31, Hitoshi Asaeda wrote: > > I don't think there was any consensus about adoption of this draft at > the last meeting. > > We've proposed the tunnel convergence problem solution draft; > draft-asaeda-multimob-pmip6-extension-07 > > Why you eliminate the discussions in the meeting and the chance to > discuss in the mailing list? > > Before explaining the thoughts about draft-zuniga draft, I'd make you > understand the situation of our draft. > > 1. I think Thomas always misunderstands the point. MAG is a router and > has its own RIB. PIM can use its RIB and can copy it to its MRIB. No, MAG's RIB doesn't reflect PMIP routing and the proposed implications are a simple mistake. Hitoshi, I spent half the summer trying to explain to you how PMIP routing works - you wouldn't listen and I gave up. Then Sri stepped in and explained the same thing again: The MAG performs policy-based routing according to policy filters, not according to a regular RIB. Again in Taipei, Sri explained PMIP routing and I guess (almost) everybody in the room understood his words. So, if you still argue on the issue, please argue against the PMIP authors, not against me. I have no iron in the fire, here, and only tried to mediate ... Cheers, 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 asaeda@sfc.wide.ad.jp Thu Dec 8 23:06: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 B0D101F0C52 for ; Thu, 8 Dec 2011 23:06:41 -0800 (PST) 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 h4KilqyNcqzq for ; Thu, 8 Dec 2011 23:06:40 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id B560B1F0C50 for ; Thu, 8 Dec 2011 23:06:40 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5C2092780B1; Fri, 9 Dec 2011 16:06:38 +0900 (JST) Date: Fri, 09 Dec 2011 16:06:37 +0900 (JST) Message-Id: <20111209.160637.115933298.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4EE1ABC3.4010208@informatik.haw-hamburg.de> References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> <4EE1ABC3.4010208@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, sarikaya2012@gmail.com Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 09 Dec 2011 07:06:41 -0000 >> 1. I think Thomas always misunderstands the point. MAG is a router and >> has its own RIB. PIM can use its RIB and can copy it to its MRIB. > > No, MAG's RIB doesn't reflect PMIP routing and the proposed > implications are a simple mistake. Sure. MAG's RIB doesn't need to reflect PMIP *unicast* routing. I said again and again, MAG's RIB is constructed independently and PIM can use the MAG's RIB for its RPF check. PIM does not use PMIP's policy route for MNs for its RPF check. And if PIM doesn't want to use MAG's RIB for some multicast channels, then independent M-Tunnel can be configured as their upstream IF into its MRIB. > Hitoshi, I spent half the summer trying to explain to you how PMIP > routing works - you wouldn't listen and I gave up. Good! So could you kindly keep silent for a while? Then we can communicate well and go forward. > Then Sri stepped in and explained the same thing again: The MAG > performs policy-based routing according to policy filters, not > according to a regular RIB. He said about unicast routes for MNs. PMIP's policy routing is the one. He did not say anything about PIM's RPF check and admitted MAG has its own RIB. And I've been saying MAG's RIB can be used as PIM for *PRF check*. Sri, if I'm wrong, please tell me. > Again in Taipei, Sri explained PMIP routing and I guess (almost) > everybody in the room understood his words. Yes, he was correct. He explained that PMIP is policy based routing for sending unicast packets to MNs. It is unicast communication for MNs. Multicast is completely different. > So, if you still argue on the issue, please argue against the PMIP > authors, not against me. I have no iron in the fire, here, and only > tried to mediate ... I only explain the truth in my sense. I've never argued against reasonable comments. I'm waiting for reasonable comments. Sri? Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Fri Dec 9 01:42:39 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 2587F21F8610 for ; Fri, 9 Dec 2011 01:42:39 -0800 (PST) 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 fsLNy2ZXXl7k for ; Fri, 9 Dec 2011 01:42:38 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9911921F85FF for ; Fri, 9 Dec 2011 01:42:38 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1D528278097; Fri, 9 Dec 2011 18:42:35 +0900 (JST) Date: Fri, 09 Dec 2011 18:42:34 +0900 (JST) Message-Id: <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4EE1ABC3.4010208@informatik.haw-hamburg.de> References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> <4EE1ABC3.4010208@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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 09 Dec 2011 09:42:39 -0000 Thomas, > Then Sri stepped in and explained the same thing again: The MAG > performs policy-based routing according to policy filters, not > according to a regular RIB. Then we should ask you one thing. Why your source mobility draft introduces PIM-SM and Bidir PIM on MAG? In Section 5, your source mobility draft says; "a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM [RFC5015] deployed at the MAGs." It constitutes a contradiction with your all statements. I hope this WG goes in the right direction. Regards, -- Hitoshi Asaeda From prvs=317cfe919=schmidt@informatik.haw-hamburg.de Fri Dec 9 10:10:38 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 5BA1921F8A7A for ; Fri, 9 Dec 2011 10:10:38 -0800 (PST) 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 pG4aduECF3yP for ; Fri, 9 Dec 2011 10:10:37 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6125E21F8A96 for ; Fri, 9 Dec 2011 10:10:37 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 09 Dec 2011 19:10:21 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 774CC102C0D1; Fri, 9 Dec 2011 19:10:21 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02722-07; Fri, 9 Dec 2011 19:10:21 +0100 (CET) Received: from [10.42.0.70] (gbcc-66-78-229-142.smartcity.com [66.78.229.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 68F0A102C0C3; Fri, 9 Dec 2011 19:10:20 +0100 (CET) Message-ID: <4EE24F17.9050809@informatik.haw-hamburg.de> Date: Fri, 09 Dec 2011 12:10:31 -0600 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> <4EE1ABC3.4010208@informatik.haw-hamburg.de> <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> In-Reply-To: <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 09 Dec 2011 18:10:38 -0000 Hitoshi, On 09.12.2011 03:42, Hitoshi Asaeda wrote: >> Then Sri stepped in and explained the same thing again: The MAG >> performs policy-based routing according to policy filters, not >> according to a regular RIB. > > Then we should ask you one thing. > Why your source mobility draft introduces PIM-SM and Bidir PIM on MAG? > > In Section 5, your source mobility draft says; > > "a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM > [RFC5015] deployed at the MAGs." > We are considering the direct mcast routing deployment (not following PMIP) - for receivers, this is the solution of Seil. There is no problem with it. Your proposal under debate is: Use PIM-SM on PMIP tunnels and in concordance with PMIP routing, which is a completely different story. However, to resolve the debate, there is a very simple reality-check: For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs associated to either LMA), please just write down *one* PIM-SM multicast routing table that accounts for PMIP routing and works for all MNs attached to the MAG. If you can do so correctly, you have proved that your approach is feasible. Thanks, 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 sarikaya2012@gmail.com Fri Dec 9 15:07:44 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 8EB9921F8586 for ; Fri, 9 Dec 2011 15:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, 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 SFsTAfj1WcKc for ; Fri, 9 Dec 2011 15:07:44 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E451021F8558 for ; Fri, 9 Dec 2011 15:07:43 -0800 (PST) Received: by yenm7 with SMTP id m7so3228584yen.31 for ; Fri, 09 Dec 2011 15:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=0x1QmQm711FhBG6nct8Kuo+4tYpqcLYMyTZUdjQSO8o=; b=FaC0rtlva7Zl8Es712pwUPhloXrwxfeIzVnXI7Qcu47R+aMSWNdBINSSAJwg/+/qqr bFkCJcCsQ2iQ96Ro9Fnx1VsdleM6xRt9kW2ZpB8lUlvJSiln3+p+PvOCiFoydapgYlV4 N0Kx+9QMeQfLPgwV1ndJh8E08nCcd+5NbFcy4= MIME-Version: 1.0 Received: by 10.236.174.3 with SMTP id w3mr14747277yhl.117.1323472063490; Fri, 09 Dec 2011 15:07:43 -0800 (PST) Received: by 10.236.125.201 with HTTP; Fri, 9 Dec 2011 15:07:43 -0800 (PST) In-Reply-To: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> Date: Fri, 9 Dec 2011 17:07:43 -0600 Message-ID: From: Behcet Sarikaya To: Hitoshi Asaeda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 23:07:44 -0000 Hi Hitoshi, Please see inline. Regards, Behcet On Thu, Dec 8, 2011 at 6:31 PM, Hitoshi Asaeda wrot= e: > Behcet, > >> =A0 There was consensus on the tunnel convergence solution draft in Taip= ei. >> =A0This mail is to confirm the consensus. >> Yes, there was. Please check the minutes. >> >> This document can be found at: >> http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt >> >> This mail starts a WG adoption call on this draft. >> >> The intended status for this document is proposed standard. >> If adopted, the draft will be named: >> >> draft-ietf-multimob-pmipv6-tunnel-convergence. >> >> Please your comments by December 15, 2011. > > I don't think there was any consensus about adoption of this draft at > the last meeting. > > We've proposed the tunnel convergence problem solution draft; > draft-asaeda-multimob-pmip6-extension-07 > Your draft and draft-zuniga present totally different approaches. They do not overlap with each other. > Why you eliminate the discussions in the meeting and the chance to > discuss in the mailing list? > Who said so? Your draft is still up for discussion. I already saw some comments on it in the list. So you should be happy. > Before explaining the thoughts about draft-zuniga draft, I'd make you > understand the situation of our draft. > > 1. I think Thomas always misunderstands the point. MAG is a router and > =A0 has its own RIB. PIM can use its RIB and can copy it to its MRIB. > =A0 When we need to define dedicate multicast routes, we can configure > =A0 the ones. We do not need PMIPv6-based policy routing for RPF check. > =A0 After the last meeting I understand Thomas's misinterpretation > =A0 comes from this. I will clearly emntion it in the revised version. > > 2. My -06 draft defines GRE type M-Tunnel to define MAG's upstream IF > =A0 to distinguish the regular IPv6 tunnel. But according to the previous > =A0 discussion in the ML, we eliminate the way to distinguish unicast > =A0 and multicast tunnels to make the story simple in -07 draft. > =A0 But I recognized this elimination was not always correct, because > =A0 we cannot assume that a unocast route toward sources outside of > =A0 PMIPv6 domain defined in MAG's RIB always goes through the regular > =A0 IPv6 tunnel. Therefore GRE type M-Tunnel will be recalled from -06 > =A0 to the revision -08. > > 3. One important discussion missing in -06 is the way to select a single > =A0 M-Tunnel when multiple M-Tunnels are configured for the same (S,G) > =A0 or (*,G). This can be addressed in the revised draft, too. > The above has nothing to do with draft-zuniga so we can not take it as a technical comment. Sorry. > For your question, I don't think > draft-zuniga-multimob-pmipv6-ropt-01.txt should be adopted now. > > Regards, > -- > Hitoshi Asaeda > From prvs=317cfe919=schmidt@informatik.haw-hamburg.de Fri Dec 9 15:59:10 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 5D60621F84C5 for ; Fri, 9 Dec 2011 15:59:10 -0800 (PST) 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 IsupmViTnTyY for ; Fri, 9 Dec 2011 15:59:09 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3A79321F84C2 for ; Fri, 9 Dec 2011 15:59:03 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 10 Dec 2011 00:59:02 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id A904E102C0D1; Sat, 10 Dec 2011 00:59:02 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12109-06; Sat, 10 Dec 2011 00:59:02 +0100 (CET) Received: from [172.16.2.204] (unknown [12.14.62.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 75A96102C0C3; Sat, 10 Dec 2011 00:59:01 +0100 (CET) Message-ID: <4EE2A0D0.50303@informatik.haw-hamburg.de> Date: Fri, 09 Dec 2011 17:59:12 -0600 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org, Behcet Sarikaya Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 09 Dec 2011 23:59:10 -0000 Hi all, some feedback: In general, I support adopting this document as a WG item - it presents two valid deployment scenarios. But I guess, the intended status should be informational, as this is just presenting deployment advice (I know, currently the document does more ...). We've been discussing the two solutions (Multicast-Tunnelendpoint, direct routing) for quite a while and we should come to conclusions ... on the current document I only had a very brief look (apologies!). Here are three comments: 1.) On the quick run, I cannot see what Section 3.5 "PMIPv6 enhancements" really is needed for. I know, I should re-read this (no time now), still the MTM approach should work without protocol modifications, I guess. 2.) There should be a section / solution on IPv4 compatibility (including address collisions ...) as needed for PMIPv6. 3.) The direct routing section (4) is still rather superficial. It should explain in detail how to deploy protocols, e.g., PIM-SM in the presence of these PMIP tunnels ... just to avoid the confusion that has been evident on this list since Quebec ;) . That's only for a quick feedback, Thomas On 08.12.2011 14:53, Behcet Sarikaya wrote: > Hello all, > There was consensus on the tunnel convergence solution draft in Taipei. > This mail is to confirm the consensus. > > > This document can be found at: > http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt > > This mail starts a WG adoption call on this draft. > > The intended status for this document is proposed standard. > If adopted, the draft will be named: > > draft-ietf-multimob-pmipv6-tunnel-convergence. > > Please your comments by December 15, 2011. > > > Chairs > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- 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 asaeda@sfc.wide.ad.jp Fri Dec 9 17:14:37 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 15CD021F84B2 for ; Fri, 9 Dec 2011 17:14:37 -0800 (PST) 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 MgjI-5xWAR+i for ; Fri, 9 Dec 2011 17:14:35 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6DF21F8476 for ; Fri, 9 Dec 2011 17:14:35 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 17EF427809C; Sat, 10 Dec 2011 10:14:31 +0900 (JST) Date: Sat, 10 Dec 2011 10:14:30 +0900 (JST) Message-Id: <20111210.101430.184553484.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4EE24F17.9050809@informatik.haw-hamburg.de> References: <4EE1ABC3.4010208@informatik.haw-hamburg.de> <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Sat, 10 Dec 2011 01:14:37 -0000 Thomas, >>> Then Sri stepped in and explained the same thing again: The MAG >>> performs policy-based routing according to policy filters, not >>> according to a regular RIB. >> >> Then we should ask you one thing. >> Why your source mobility draft introduces PIM-SM and Bidir PIM on MAG? >> >> In Section 5, your source mobility draft says; >> >> "a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM >> [RFC5015] deployed at the MAGs." > > We are considering the direct mcast routing deployment (not following > PMIP) - for receivers, this is the solution of Seil. There is no > problem with it. Ok, so you now admit MAG has its own RIB and PIM can use it, where this is my basic assumption. That's a relief. > Your proposal under debate is: Use PIM-SM on PMIP tunnels and in > concordance with PMIP routing, which is a completely different story. No, it's not true. Our solution does not need to conform to PMIP *unicast* routing *to MNs*. To construct multicast routing tree, knowing unicast route to each receiver is not necessary. Only multicast routers need to understand the interface toward sources. It's the way the regular multicast routing does. > However, to resolve the debate, there is a very simple reality-check: > > For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs associated > to either LMA), please just write down *one* PIM-SM multicast routing > table that accounts for PMIP routing and works for all MNs attached to > the MAG. > > If you can do so correctly, you have proved that your approach is > feasible. Oh, finally you understand the point. Good! Yes, it is mentioned in our working plan to address it in my yesterday's mail. Regards, -- Hitoshi Asaeda From seiljeon@gmail.com Fri Dec 9 23:17:11 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 1CCD521F8549 for ; Fri, 9 Dec 2011 23:17:11 -0800 (PST) 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 DwwRIEM6d4ZC for ; Fri, 9 Dec 2011 23:17:10 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF8EF21F8446 for ; Fri, 9 Dec 2011 23:17:09 -0800 (PST) Received: by pbbb4 with SMTP id b4so696033pbb.31 for ; Fri, 09 Dec 2011 23:17:09 -0800 (PST) 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=AJAuLNiHSJn0/PGTh6KMtNH5/dGvBTHCmXqzBu4ewV4=; b=qnbTeBaKtuFtmWgVfmX2Su8SHuo8SdNI7xTk1+QNKof95T8u2NRi7V2+irW/el1QTP ZgsRKBjQ5163jz+BoK3kPl6xuDfTCVqEITdC58g0+elP3xQghUBOfF+9nF3/ACa4U2i0 wqrV60ASySfdbc3e6hU0L/Q8Yt67dZN0kO88I= MIME-Version: 1.0 Received: by 10.68.73.104 with SMTP id k8mr12628443pbv.104.1323501429558; Fri, 09 Dec 2011 23:17:09 -0800 (PST) Sender: seiljeon@gmail.com Received: by 10.68.50.162 with HTTP; Fri, 9 Dec 2011 23:17:09 -0800 (PST) In-Reply-To: <20111209.090739.138669235.asaeda@sfc.wide.ad.jp> References: <20111209.090739.138669235.asaeda@sfc.wide.ad.jp> Date: Sat, 10 Dec 2011 16:17:09 +0900 X-Google-Sender-Auth: jxv8FUzzwKMQtW9vAnsG_6LX77I Message-ID: From: seil jeon To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=f46d041706e3918ca104b3b7b0a0 Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 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: Sat, 10 Dec 2011 07:17:11 -0000 --f46d041706e3918ca104b3b7b0a0 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, I feel that the scope of this document is not clear because as you know, we have no problem statement but only base deployment solution presented in multimob. My thought to move forward is as followed. 1. If this document targets to source mobility can be applied in RFC 6224, that is MLD proxy on MAG, I agree for WG adoption of this document on the condition that the document is well arranged after the section of routing optimizations is removed in access network. The introduction is now addressed as "This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains as it is provided by the base deployment scenario [RFC6224], as well as optimizations throughout the access network infrastructure to efficiently solve the source mobility problem as dicussed in [RFC5757]." 2. If this document includes routing optimizations, I think the document is not ready to move forward. As Hitoshi pointed out, it needs to consider and address potential issues. Now, section 5 seems to me as simple consideration not the solution for multicast routing optimizations. Best Regards, Seil Jeon ----------------------------------------------------------------------------------------- Soongsil Univ. Ubiquitous Network Research Center (SUNRC) Homepage: http://sites.google.com/site/seiljeon 2011/12/9 Hitoshi Asaeda > Hello, > > > There was consensus on the source mobility solution draft in Taipei. > > This mail is to confirm the consensus. > > > > > > This document can be found at: > > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt > > > > This mail starts a WG adoption call on this draft. > > > > The intended status for this document is proposed standard. > > If adopted, the draft will be named: > > > > draft-ietf-multimob-pmipv6-source-mobility. > > > > Please your comments by December 12, 2011. > > 1. The goal of this document is unclear. It seems that it focuses on > both the MLD proxy type MAG and the PIM support. But there is no > description about PIM support. See section 5. It just says "TODO" > for both PIM-SM and Bidir PIM. It is impossible to understand > anything from this condition. > Moreover, this draft does not consider multicast routing functions > on MAG. Except incomplete section5, only in section 1, it says; > "Alternate solutions leverage performance optimization by providing > multicast routing at the access routers directly, or by other > dedicated schemes." > I'd suggest that this draft just focuses on the source mobility > only for rfc6224 and clearly mentions it. Title should be also > changed as the current one is too broad. > > 2. With the regular MLD proxy (rfc4605), multicast packets sent from a > host that attaches to the downstream link of an MLD proxy can be > forwarded to both the downstream and upstream links. The problem > for source mobility in rfc6224 is that multicast packets sent by MN > should be directed to eliminate detour of the packets in case of > MNs not charing MAG and/or LMA in some case and should not be > directed in other cases, according to operators' policy. This > scenario should be also considered when multiple MLD proxy > instances are enabled in a MAG. Addressing this issue is the main > contribution of source mobility for rfc6224. > However, there is no detail discussion about it in section 6.1 and > no solution defined at all. Section 6.1 only says "TODO datails" at > the end. > > 3. There is no source handover discussion. A source mobility draft > should be also described it with appropriate scenarios and data > flows. > > According to these considerations, it is too early to decide that this > draft is adopted. > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --f46d041706e3918ca104b3b7b0a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
=A0
I=A0feel that the scope of this document is not clear because as you k= now, we have no problem statement but only base deployment solution present= ed in multimob.
=A0
My thought to move forward is as followed.
=A0
1. If this document targets to source mobility can be applied in=A0RFC= 6224, that is MLD proxy on MAG, I agree for WG adoption of this document o= n the condition=A0that the document is well arranged after the section of= =A0routing optimizations is removed in access network.
=A0
The introduction is now addressed as "This document describes the= support of mobile multicast senders in Proxy Mobile IPv6 domains as it is = provided by the base deployment scenario [RFC6224], as well as optimization= s throughout the access network infrastructure to efficiently solve the sou= rce mobility problem as dicussed in [RFC5757]."
=A0
2. If this document includes routing optimizations, I think the docume= nt is not ready to move forward.
=A0=A0 As Hitoshi pointed out, it needs to consider=A0and address pote= ntial issues. Now, section 5 seems to me as simple consideration not the so= lution for multicast routing optimizations.
=A0
=A0
Best Regards,
=A0
Seil Jeon
=A0
----------------------------------------------------------------------= -------------------

Soongsil Univ. Ubiquitous Network Research Center (SUNRC)
=A0Homepage: http://sites.= google.com/site/seiljeon
=A0
=A0
=A0
2011/12/9 Hitoshi Asaeda <<= a href=3D"mailto:asaeda@sfc.wide.ad.jp">asaeda@sfc.wide.ad.jp>
Hello,

> =A0 There was consensus=A0on the source mobility= solution draft in Taipei.
> =A0This mail is to confirm the consensus= .
>
>
> This document can be found at:
> http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source= -00.txt
>
> This mail starts a WG adoption call on this draft.
>
= > The intended status for this document is proposed standard.
> If= adopted, the draft will be named:
>
> draft-ietf-multimob-pmip= v6-source-mobility.
>
> Please your comments by December 12, 2011.

1. The= goal of this document is unclear. It seems that it focuses on
=A0 both = the MLD proxy type MAG and the PIM support. But there is no
=A0 descript= ion about PIM support. See section 5. It just says "TODO"
=A0 for both PIM-SM and Bidir PIM. It is impossible to understand
=A0 an= ything from this condition.
=A0 Moreover, this draft does not consider m= ulticast routing functions
=A0 on MAG. Except incomplete section5, only = in section 1, it says;
=A0 "Alternate solutions leverage performance optimization by providin= g
=A0 =A0multicast routing at the access routers directly, or by other=A0 =A0dedicated schemes."
=A0 I'd suggest that this draft ju= st focuses on the source mobility
=A0 only for rfc6224 and clearly mentions it. Title should be also
=A0 c= hanged as the current one is too broad.

2. With the regular MLD prox= y (rfc4605), multicast packets sent from a
=A0 host that attaches to the= downstream link of an MLD proxy can be
=A0 forwarded to both the downstream and upstream links. The problem
=A0= for source mobility in rfc6224 is that multicast packets sent by MN
=A0= should be directed to eliminate detour of the packets in case of
=A0 MN= s not charing MAG and/or LMA in some case and should not be
=A0 directed in other cases, according to operators' policy. This
= =A0 scenario should be also considered when multiple MLD proxy
=A0 insta= nces are enabled in a MAG. Addressing this issue is the main
=A0 contrib= ution of source mobility for rfc6224.
=A0 However, there is no detail discussion about it in section 6.1 and
= =A0 no solution defined at all. Section 6.1 only says "TODO datails&qu= ot; at
=A0 the end.

3. There is no source handover discussion. A = source mobility draft
=A0 should be also described it with appropriate scenarios and data
=A0 = flows.

According to these considerations, it is too early to decide = that this
draft is adopted.

Regards,
--
Hitoshi Asaeda
_______________________________________________
multim= ob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--f46d041706e3918ca104b3b7b0a0-- From seiljeon@gmail.com Sat Dec 10 00:08:14 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 7ADA921F84A5 for ; Sat, 10 Dec 2011 00:08:14 -0800 (PST) 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, SARE_HTML_USL_OBFU=1.666] 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 WEa5TrTxjwKU for ; Sat, 10 Dec 2011 00:08:13 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD3521F8AFA for ; Sat, 10 Dec 2011 00:08:13 -0800 (PST) Received: by pbbb4 with SMTP id b4so706892pbb.31 for ; Sat, 10 Dec 2011 00:08:12 -0800 (PST) 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=z/0LSBBlR/cNbIRQhQve6F4IFykY7vJ4//myF3gM2S4=; b=Y2cC8mTjpB8WfOvxl5oVZX+keaMvf6TWods++VMcRpYk4zbId504fLscoC9K02eBaR SJuj0E4Yw0vLIhdh8pzh0U5p432LLknCx3f8AgNhCwUMAyG8SyeZRL52SsSBeEaLt/hW 7HxPbW9mzcyk4v7kS6YL8SdxaivVqiGzFTvyE= MIME-Version: 1.0 Received: by 10.68.74.71 with SMTP id r7mr13157383pbv.121.1323504492135; Sat, 10 Dec 2011 00:08:12 -0800 (PST) Sender: seiljeon@gmail.com Received: by 10.68.50.162 with HTTP; Sat, 10 Dec 2011 00:08:12 -0800 (PST) In-Reply-To: <4EE2A0D0.50303@informatik.haw-hamburg.de> References: <4EE2A0D0.50303@informatik.haw-hamburg.de> Date: Sat, 10 Dec 2011 17:08:12 +0900 X-Google-Sender-Auth: YUoaUHPk7n80dyCn4u_L3142QfE Message-ID: From: seil jeon To: "Thomas C. Schmidt" , "Zuniga, Juan Carlos" Content-Type: multipart/alternative; boundary=f46d041b47dc1cc57104b3b86749 Cc: multimob@ietf.org, Behcet Sarikaya Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Sat, 10 Dec 2011 08:08:14 -0000 --f46d041b47dc1cc57104b3b86749 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks for your valuable comments from your busy schedule. Please see inline. Best Regards, Seil Jeon 2011/12/10 Thomas C. Schmidt > Hi all, > > some feedback: > > In general, I support adopting this document as a WG item - it presents > two valid deployment scenarios. But I guess, the intended status should b= e > informational, as this is just presenting deployment advice (I know, > currently the document does more ...). > > We've been discussing the two solutions (Multicast-Tunnelendpoint, direc= t > routing) for quite a while and we should come to conclusions ... on the > current document I only had a very brief look (apologies!). > > Here are three comments: > > 1.) On the quick run, I cannot see what Section 3.5 "PMIPv6 > enhancements" really is needed for. I know, I should re-read this (no tim= e > now), still the MTM approach should work without protocol modifications, = I > guess. > =3D> Maybe, Zuniga needs to talk about it. > > 2.) There should be a section / solution on IPv4 compatibility (includin= g > address collisions ...) as needed for PMIPv6. > =3D> We'll check what kinds of considerations including address collisions for IPv4 support with Zuniga. > 3.) The direct routing section (4) is still rather superficial. It shoul= d > explain in detail how to deploy protocols, e.g., PIM-SM in the presence o= f > these PMIP tunnels ... just to avoid the confusion that has been evident = on > this list since Quebec ;). > =3D> In next version, the operations of MAG and MN will be updated. Additional considerations will be added. > > That's only for a quick feedback, > > Thomas > > > > > On 08.12.2011 14:53, Behcet Sarikaya wrote: > >> Hello all, >> There was consensus on the tunnel convergence solution draft in Taipei= . >> This mail is to confirm the consensus. >> >> >> This document can be found at: >> http://tools.ietf.org/id/**draft-zuniga-multimob-pmipv6-**ropt-01.txt >> >> This mail starts a WG adoption call on this draft. >> >> The intended status for this document is proposed standard. >> If adopted, the draft will be named: >> >> draft-ietf-multimob-pmipv6-**tunnel-convergence. >> >> Please your comments by December 15, 2011. >> >> >> Chairs >> ______________________________**_________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/**listinfo/multimob >> > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-**hamburg.de/~schmidt Fax: +49-40-42875-8409 =B0 > ______________________________**_________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/**listinfo/multimob > --f46d041b47dc1cc57104b3b86749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
=A0
Thanks for your valuable comments from your busy schedule.
=A0
Please see inline.
=A0
=A0
Best Regards,
=A0
Seil Jeon
=A0

=A0
2011/12/10 Thomas C. Schmidt &= lt;schmidt@informatik.= haw-hamburg.de>
Hi all,

some feedback:

= =A0In general, I support adopting this document as a WG item - it presents = two valid deployment scenarios. But I guess, the intended status should be = informational, as this is just presenting deployment advice (I know, curren= tly the document does more ...).

=A0We've been discussing the two solutions (Multicast-Tunnelendpoin= t, direct routing) for quite a while and we should come to conclusions ... = on the current document I only had a very brief look (apologies!).

=A0Here are three comments:

=A01.) On the quick run, I cannot see wh= at Section 3.5 =A0"PMIPv6 enhancements" really is needed for. I k= now, I should re-read this (no time now), still the MTM approach should wor= k without protocol modifications, I guess.
=A0
=3D> Maybe, Zuniga needs to talk about it.
=A0

=A02.) There should be a section = / solution on IPv4 compatibility (including address collisions ...) as need= ed for PMIPv6.
=3D> We'll check what kinds of considerations including address= collisions=A0for IPv4 support with Zuniga.
=A0
=A03.) The direct routing section (4)= is still rather superficial. It should explain in detail how to deploy pro= tocols, e.g., PIM-SM in the presence of these PMIP tunnels ... just to avoi= d the confusion that has been evident on this list since Quebec ;).
=3D> In=A0next version, the operations of MAG=A0and=A0MN will be up= dated. Additional considerations will be added.
=A0

That's only for a quick feedb= ack,

Thomas=20




On 08.12.2011 14:53, Behcet Sarikaya wrot= e:
Hello all,
=A0 There was consensus= on the tunnel convergence solution draft in Taipei.
=A0This mail is to = confirm the consensus.


This document can be found at:
http://tools= .ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt

This mail starts a WG adoption call on this draft.

The intended = status for this document is proposed standard.
If adopted, the draft wil= l be named:

draft-ietf-multimob-pmipv6-tunnel-convergence.
Please your comments by December 15, 2011.


Chairs
_______= ________________________________________
multimob mailing listmultimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--

Prof. Dr. Thomas C. Schmidt
=B0 Hamb= urg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berl= iner Tor 7 =B0
=B0 Dept. Informatik, Internet Technologies Group =A0 =A0= 20099 Hamburg, Germany =B0
=B0 http://www= .haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42= 875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt =A0 =A0Fax: +49-40-42875-8409 =B0
_______________________________________________multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listin= fo/multimob

--f46d041b47dc1cc57104b3b86749-- From seiljeon@gmail.com Sat Dec 10 00:15: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 3B07021F8669 for ; Sat, 10 Dec 2011 00:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 A7XRsX0qJrNO for ; Sat, 10 Dec 2011 00:15:54 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D54721F863E for ; Sat, 10 Dec 2011 00:15:54 -0800 (PST) Received: by dajz8 with SMTP id z8so4659654daj.31 for ; Sat, 10 Dec 2011 00:15:54 -0800 (PST) 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=ST/kYTNr27Jj3n6k2wdRC4INiN5OzfPjY4lNOqIgRas=; b=Y3rcY7FsmijVp92tBAUZVZ5JeQ7Wtga6Bc9OqQbcYHsNzIuH4nQcXYPjDYZsqL2NG+ lyJ1GN4dlEW3lYA1ZDpBYfrdGUU3DQt8jDB5XVhrPhsm8WMFO4bnoGNVa+5mgiVyoEpM yDdA6B9y1mUsT/6VRd6wUP8L175DE9UNiJt/k= MIME-Version: 1.0 Received: by 10.68.213.41 with SMTP id np9mr13052070pbc.70.1323504953988; Sat, 10 Dec 2011 00:15:53 -0800 (PST) Sender: seiljeon@gmail.com Received: by 10.68.50.162 with HTTP; Sat, 10 Dec 2011 00:15:53 -0800 (PST) In-Reply-To: <4EE24F17.9050809@informatik.haw-hamburg.de> References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> <4EE1ABC3.4010208@informatik.haw-hamburg.de> <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@informatik.haw-hamburg.de> Date: Sat, 10 Dec 2011 17:15:53 +0900 X-Google-Sender-Auth: ifZVG9d50AGHLeyOR3cZS4Pw7ME Message-ID: From: seil jeon To: "Thomas C. Schmidt" , Hitoshi Asaeda Content-Type: multipart/alternative; boundary=e89a8ff1bfa8a4149304b3b882db Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Sat, 10 Dec 2011 08:15:56 -0000 --e89a8ff1bfa8a4149304b3b882db Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Hitoshi, This discussion has been continuing repeatedly. Please check my understanding is correct from the dicussion between Thomas and Hitoshi. When the MAG is connected with other PIM-SM router not over LMA, there's no problem. PIM-SM establishes multicast routing path using RPF algorithm through reflecting MAG's RIB. But when the MAG is connected with several LMAs including PIM-SM, MRIB SHOULD get information from PMIP routing table but "MAG's RIB doesn't reflect PMIP routing" (Thomas and Hitoshi agreed it). So, Thomas, you think that this does not solve tunnel convergence problem. Is it clear? Thomas 2011/12/10 Thomas C. Schmidt > Hitoshi, > > > On 09.12.2011 03:42, Hitoshi Asaeda wrote: > > Then Sri stepped in and explained the same thing again: The MAG >>> performs policy-based routing according to policy filters, not >>> according to a regular RIB. >>> >> >> Then we should ask you one thing. >> Why your source mobility draft introduces PIM-SM and Bidir PIM on MAG? >> >> In Section 5, your source mobility draft says; >> >> "a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM >> [RFC5015] deployed at the MAGs." >> >> > We are considering the direct mcast routing deployment (not following > PMIP) - for receivers, this is the solution of Seil. There is no problem > with it. > > Your proposal under debate is: Use PIM-SM on PMIP tunnels and in > concordance with PMIP routing, which is a completely different story. > > However, to resolve the debate, there is a very simple reality-check: > > For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs associated to > either LMA), please just write down *one* PIM-SM multicast routing table > that accounts for PMIP routing and works for all MNs attached to the MAG. > > If you can do so correctly, you have proved that your approach is > feasible. > > Thanks, > > Thomas > > > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-**hamburg.de/~schmidt Fax: +49-40-42875-8409 =B0 > > ______________________________**_________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/**listinfo/multimob > --e89a8ff1bfa8a4149304b3b882db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas, Hitoshi,
=A0

This discussion has been continuing repeatedly.

Please check my understanding is correct from the dicussion between Thom= as and Hitoshi.

When the MAG is connected with other PIM-SM router not over LMA, there&#= 39;s no problem. PIM-SM establishes multicast routing path using RPF algori= thm through reflecting MAG's RIB.

But when the MAG is connected with several LMAs including PIM-SM, MRIB S= HOULD get information from PMIP routing table but "MAG's RIB doesn= 't reflect PMIP routing" (Thomas and Hitoshi agreed it).

So,=A0Thomas, you think that this=A0does not solve tunnel convergence pr= oblem.

Is it clear? Thomas

2011/12/10 Thomas C. Schmidt &= lt;schmidt@informatik.= haw-hamburg.de>
Hitoshi,=20


On 09.12.2011 03:42, Hitoshi Asaeda wrote:
Then Sri stepped in and explained the= same thing again: The MAG
performs policy-based routing according to po= licy filters, not
according to a regular RIB.

Then we should ask you one = thing.
Why your source mobility draft introduces PIM-SM and Bidir PIM on= MAG?

In Section 5, your source mobility draft says;

=A0 &quo= t;a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM
=A0 =A0[RFC5015] deployed at the MAGs."


= We are considering the direct mcast routing deployment (not following PMIP)= - for receivers, this is the solution of Seil. There is no problem with it= .

Your proposal under debate is: Use PIM-SM on PMIP tunnels and in concor= dance with PMIP routing, which is a completely different story.

Howe= ver, to resolve the debate, there is a very simple reality-check:

=A0For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs associated to = either LMA), please just write down *one* PIM-SM multicast routing table th= at accounts for PMIP routing and works for all MNs attached to the MAG.

=A0If you can do so correctly, you have proved that your approach is fe= asible.

Thanks,

Thomas



--

Prof. Dr. Thomas C. Schmidt
=B0 Hambu= rg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berli= ner Tor 7 =B0
=B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Hamburg, Ger= many =B0
=B0 http://www.haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fo= n: +49-40-42875-8452 =B0
=B0 http://www.informatik.haw-hamburg.d= e/~schmidt =A0 =A0Fax: +49-40-42875-8409 =B0=20

______________________________________________= _
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/= listinfo/multimob

--e89a8ff1bfa8a4149304b3b882db-- From prvs=31812d226=schmidt@informatik.haw-hamburg.de Sat Dec 10 08:33:08 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 1DD5A21F8BB8 for ; Sat, 10 Dec 2011 08:33:08 -0800 (PST) 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 irykcSMlMfTK for ; Sat, 10 Dec 2011 08:33:07 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id CA23F21F8B10 for ; Sat, 10 Dec 2011 08:33:06 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 10 Dec 2011 17:33:05 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 652CA102C0C4; Sat, 10 Dec 2011 17:33:05 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04518-10; Sat, 10 Dec 2011 17:33:04 +0100 (CET) Received: from [172.17.192.67] (75-148-178-225-Houston.hfc.comcastbusiness.net [75.148.178.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id DD4B7102C0CC; Sat, 10 Dec 2011 17:33:03 +0100 (CET) Message-ID: <4EE389CB.40704@informatik.haw-hamburg.de> Date: Sat, 10 Dec 2011 10:33:15 -0600 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: seil jeon References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> <4EE1ABC3.4010208@informatik.haw-hamburg.de> <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Sat, 10 Dec 2011 16:33:08 -0000 Hi Seil, On 10.12.2011 02:15, seil jeon wrote: > But when the MAG is connected with several LMAs including PIM-SM, MRIB > SHOULD get information from PMIP routing table but "MAG's RIB doesn't > reflect PMIP routing" (Thomas and Hitoshi agreed it). > the "problem" that causes these repeated errors in reasoning here on the list is the following (quoting Sri): 1. PMIP routing is not ordinary routing, but policy-based. This means, it is not based on the destination address, but on policy filters, in this case *source* addresses. 2. The consequence is: You cannot write PMIP routing rules in a regular routing table. 3. Because you cannot write PMIP routing in *one* normal RIB, you also cannot built a (PIM-SM) MRIB from it. (And this is the reality-check for Hitoshi: he will see that he cannot write an MRIB in this case ...). In general, there is no big deal about this. The fuzz is only that draft-asaeda-multimob-pmip6-extension-07 is built upon an error from misunderstanding PMIP routing ... Your problem of draft http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt is a different one. You need to describe deployment of direct routing (e.g, PIM) at a MAG that runs PMIP routing (including tunnel interfaces) and normal routing in the access network (the non-PMIP case). You should explain this in your draft so well that readers can understand and successfully deploy. In the current version you just say "turn on PIM" ... and that's not all, I guess. Best, Thomas > 2011/12/10 Thomas C. Schmidt > > > Hitoshi, > > > On 09.12.2011 03:42, Hitoshi Asaeda wrote: > > Then Sri stepped in and explained the same thing again: The MAG > performs policy-based routing according to policy filters, not > according to a regular RIB. > > > Then we should ask you one thing. > Why your source mobility draft introduces PIM-SM and Bidir PIM > on MAG? > > In Section 5, your source mobility draft says; > > "a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM > [RFC5015] deployed at the MAGs." > > > We are considering the direct mcast routing deployment (not > following PMIP) - for receivers, this is the solution of Seil. There > is no problem with it. > > Your proposal under debate is: Use PIM-SM on PMIP tunnels and in > concordance with PMIP routing, which is a completely different story. > > However, to resolve the debate, there is a very simple reality-check: > > For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs > associated to either LMA), please just write down *one* PIM-SM > multicast routing table that accounts for PMIP routing and works for > all MNs attached to the MAG. > > If you can do so correctly, you have proved that your approach is > feasible. > > Thanks, > > 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 ° > > _________________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/__listinfo/multimob > > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- 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 Akbar.Rahman@InterDigital.com Sun Dec 11 12:35:59 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 C13F221F8496 for ; Sun, 11 Dec 2011 12:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.566, 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 qfgXveazFvpz for ; Sun, 11 Dec 2011 12:35:59 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 295B121F8495 for ; Sun, 11 Dec 2011 12:35:58 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Dec 2011 15:35:54 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Dec 2011 15:35:50 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG adoption call ondraft-schmidt-multimob-pmipv6-source-00 Thread-Index: AcyzmZRXeoasTt5jSLKq2oYOx1TgGgEpJ0pw References: From: "Rahman, Akbar" To: X-OriginalArrivalTime: 11 Dec 2011 20:35:54.0162 (UTC) FILETIME=[7AA1E920:01CCB844] Subject: Re: [multimob] WG adoption call ondraft-schmidt-multimob-pmipv6-source-00 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: Sun, 11 Dec 2011 20:35:59 -0000 Hi Bechet/Thomas, I support adopting draft-schmidt-multimob-pmipv6-source-00 as a WG = draft. I also have the following comments which I think can be addressed in the = next update once it becomes a WG draft: 1) Editorial - 2nd paragraph of section 1 (Introduction) - From: "... on the price of possibly ..." - To: "... at the price of possibly ..." 2) Section 3 (Base Solution for Source Mobility: Overview), 2nd = paragraph - Is it really a "downstream" link in this perspective or an "upstream" = link? Anyways, I know in cellular the direction from the MN to the = network is referred to as the "uplink". - Also in the next paragraph (3rd paragraph), you refer to "upstream" = ... Maybe this points to the need to really clearly define = upstream/downstream directions in this I-D. 3) Figure 1 - The bottom half of the Figure containing the "Multicast Senders and = Listeners" is very busy and hard to decipher. I suggest cleaning up = this part of the figure as it took me a few reads of the associated text = to understand it. 4) Section 3 - There is a reference of an MN "using its source address with Home = Network Prefix (HNP)". Can you explain to me how this works for a 3GPP = cellular network? My understanding in 3GPP is that the GGSN assigns a = dynamic IP address which is seen by anyone communicating with the MN in = the Internet. So is this GGSN assigned address the HNP you are = referring to (i.e. the GGSN address would be the multicast source = address)? Or is this GGSN address different from the PMIP HNP you are = referring to? That's all for now. I will continue reading the draft and send more = comments later on. Akbar -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Behcet Sarikaya Sent: Monday, December 05, 2011 5:02 PM To: multimob@ietf.org Subject: [multimob] WG adoption call = ondraft-schmidt-multimob-pmipv6-source-00 Hello all, =A0 There was consensus=A0on the source mobility solution draft in = Taipei. This mail is to confirm the consensus. This document can be found at: http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt This mail starts a WG adoption call on this draft. The intended status for this document is proposed standard. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-source-mobility. Please your comments by December 12, 2011. Chairs _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From Akbar.Rahman@InterDigital.com Sun Dec 11 12:39:51 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 4596821F849E for ; Sun, 11 Dec 2011 12:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.425, 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 bqGXcUdYbv7l for ; Sun, 11 Dec 2011 12:39:50 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9465C21F8495 for ; Sun, 11 Dec 2011 12:39:45 -0800 (PST) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Dec 2011 15:39:44 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Dec 2011 15:39:41 -0500 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Thread-Index: Acy17Y7A4XbAgFD7RhiLvzYZyccmagCVz1yQ References: From: "Rahman, Akbar" To: X-OriginalArrivalTime: 11 Dec 2011 20:39:44.0811 (UTC) FILETIME=[041C27B0:01CCB845] Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Sun, 11 Dec 2011 20:39:51 -0000 Hi Bechet, I agree that there was good consensus on draft-zuniga-multimob-pmipv6-ropt during the IETF meeting in Taipei. So I support adopting this document as a WG I-D. Akbar -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya Sent: Thursday, December 08, 2011 3:53 PM To: multimob@ietf.org Subject: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Hello all, There was consensus on the tunnel convergence solution draft in Taipei. This mail is to confirm the consensus. This document can be found at: http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt This mail starts a WG adoption call on this draft. The intended status for this document is proposed standard. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-tunnel-convergence. Please your comments by December 15, 2011. Chairs _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From nkong@cnnic.cn Sun Dec 11 17:44:51 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 3498521F850B for ; Sun, 11 Dec 2011 17:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy9diddLrlOM for ; Sun, 11 Dec 2011 17:44:50 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id BE5DC21F8509 for ; Sun, 11 Dec 2011 17:44:49 -0800 (PST) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 12 Dec 2011 09:44:41 +0800 From: "Ning Kong" To: Date: Mon, 12 Dec 2011 09:44:39 +0800 Message-ID: <015601ccb86f$9d112950$d7337bf0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acy4b0u8AC0JEYyqSiibJOKfI8lEQw== Content-Language: zh-cn Subject: Re: [multimob] WG adoption call on draft-schmidt-multimob-pmipv6-source-00 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, 12 Dec 2011 01:44:51 -0000 Hi folks, I also support adopting the draft-schmidt-multimob-pmipv6-source-00 as a = WG draft. Please see my comments inline. 1) IMHO it will be more readable if the terminologies used in this = document can be listed and clearly explained in the "2. Terminology" section. 2) With the proposed scheme, the profile of MN also should be extended = with the multicast source related information. I suppose these extensions = should be considered and included in this document. Cheers, Ning > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On > Behalf Of Behcet Sarikaya > Sent: Monday, December 05, 2011 5:02 PM > To: multimob@ietf.org > Subject: [multimob] WG adoption call > ondraft-schmidt-multimob-pmipv6-source-00 >=20 > Hello all, > =A0 There was consensus=A0on the source mobility solution draft in = Taipei. > This mail is to confirm the consensus. >=20 >=20 > This document can be found at: > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt >=20 > This mail starts a WG adoption call on this draft. >=20 > The intended status for this document is proposed standard. > If adopted, the draft will be named: >=20 > draft-ietf-multimob-pmipv6-source-mobility. >=20 > Please your comments by December 12, 2011. >=20 >=20 > Chairs > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From gaoxlh@gmail.com Sun Dec 11 19:02:56 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 1CBBB21F853A for ; Sun, 11 Dec 2011 19:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.204 X-Spam-Level: *** X-Spam-Status: No, score=3.204 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 OJ6MPoI3ZqUa for ; Sun, 11 Dec 2011 19:02:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9876621F849E for ; Sun, 11 Dec 2011 19:02:55 -0800 (PST) Received: by iaek3 with SMTP id k3so9408871iae.31 for ; Sun, 11 Dec 2011 19:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=d6yGFL9JKEz/Ys7KEAXF0NlB/D070GmhmIP0sAkwhVQ=; b=soIA6glJ6LemWAblOE+ba/RmeGFAn8mlq99QkXlztg264dxhR/TAlw7XdKw86CwYnw QG9X4No9mEVYwGEC1H++Qlqhbu3zKS8p1h0TJBapTC3G4O/3wvIQ4I/BWIY0+49TrWQK Hob/36HuQzQMboc3wAd6Sn91jg26k7gqgDdGs= Received: by 10.42.156.195 with SMTP id a3mr10419412icx.25.1323658975283; Sun, 11 Dec 2011 19:02:55 -0800 (PST) Received: from John-PC ([60.247.46.41]) by mx.google.com with ESMTPS id b31sm45325377ibh.9.2011.12.11.19.02.51 (version=SSLv3 cipher=OTHER); Sun, 11 Dec 2011 19:02:54 -0800 (PST) Date: Mon, 12 Dec 2011 11:02:51 +0800 From: "Shuai Gao" To: "sarikaya2012" Message-ID: <201112121102479725697@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: multimob Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 03:02:56 -0000 SGkgYWxsLA0KICAgRm9yIHRoZSB0dW5uZWwgY29udmVyZ2VuY2UgcHJvYmxlbSwgd2UgaGF2ZSBk aXNjdXNzZWQgZm9yIHZlcnkgbG9uZyB0aW1lLiBOb3cgdGhlIGRyYWZ0LXp1bmlnYS1tdWx0aW1v Yi1wbWlwdjYtcm9wdC0wMSBsb29rcyBtb3JlIGdlbmVyYWwgYW5kIEkgc3VwcG9ydCB0byBhZG9w dCB0aGlzIGRyYWZ0IGFzIHRoZSBXRyBJRCB0bw0Kc3BlZWQgdXAgdGhlIHN0YW5kYXJkIHByb2Nl c3MuIA0KICAgRm9yIHRoaXMgZHJhZnQsIEkgaGF2ZSBzb21lIGNvbW1lbnRzIGZvciBjb25zaWRl cmF0aW9uLg0KCTEpIFRoZSBhc3NvY2lhdGlvbiBzY2hlbWUgYW1vbmcgdGhlIE1BR3MgYW5kIHRo ZSBNVE1BcyBpcyBub3QgY2xlYXIuICBUaGUgTUFHIGlzIGFzc29jaWF0ZWQgd2l0aCBhIE1UTUEg YWNjb3JkaW5nIHRvIGdyb3VwIGNoYW5uZWwgYWRkcmVzcyBvciBNTj8gIA0KDQogICAgMikgSW4g My4yICJEZXBsb3ltZW50IFNjZW5hcmlvcyIsIEkgc3VnZ2VzdCB0byBhZGQgYSBkaXNjdXNzaW9u IGFib3V0IHRoZSBzY2VuYXJpbyBpbiB3aGljaCBhIE1OIGlzIHJlY2VpdmluZyB0d28gZGlmZmVy ZW50IG11bHRpY2FzdCBzZXJ2aWNlIGFzc29jaWF0ZWQgd2l0aCB0d28gZGlmZmVyZW50IE1UTUFz Lg0KDQogICAgMykgVGhlIGNob2ljZSBhYm91dCBMb2NhbCBzdWJzY3JpcHRpb24gb3IgIFJlbW90 ZSBzdWJzY3JpcHRpb24gbmVlZCB0byBiZSBjbGFyaWZlZCB0byBiZSBtb3JlIGZlYXNpYmxlIGZv ciBkZXBsb3ltZW50LiANCg0KICAgIDQpIFRoZSB3cml0dGVuIHN0eWxlIG9mIHNlY3Rpb24gNCBu ZWVkIHRvIGJlIGNvbnNpc3RhbnQgd2l0aCBvdGhlciBzZWN0aW9ucy4gDQoNClNodWFpIA0KDQoJ DQoNCj09PT09PT0gMjAxMS0xMi0wOSAwNDo1Mzo0MSDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0K DQo+SGVsbG8gYWxsLA0KPiAgVGhlcmUgd2FzIGNvbnNlbnN1cyBvbiB0aGUgdHVubmVsIGNvbnZl cmdlbmNlIHNvbHV0aW9uIGRyYWZ0IGluIFRhaXBlaS4NCj4gVGhpcyBtYWlsIGlzIHRvIGNvbmZp cm0gdGhlIGNvbnNlbnN1cy4NCj4NCj4NCj5UaGlzIGRvY3VtZW50IGNhbiBiZSBmb3VuZCBhdDoN Cj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtenVuaWdhLW11bHRpbW9iLXBtaXB2Ni1y b3B0LTAxLnR4dA0KPg0KPlRoaXMgbWFpbCBzdGFydHMgYSBXRyBhZG9wdGlvbiBjYWxsIG9uIHRo aXMgZHJhZnQuDQo+DQo+VGhlIGludGVuZGVkIHN0YXR1cyBmb3IgdGhpcyBkb2N1bWVudCBpcyBw cm9wb3NlZCBzdGFuZGFyZC4NCj5JZiBhZG9wdGVkLCB0aGUgZHJhZnQgd2lsbCBiZSBuYW1lZDoN Cj4NCj5kcmFmdC1pZXRmLW11bHRpbW9iLXBtaXB2Ni10dW5uZWwtY29udmVyZ2VuY2UuDQo+DQo+ UGxlYXNlIHlvdXIgY29tbWVudHMgYnkgRGVjZW1iZXIgMTUsIDIwMTEuDQo+DQo+DQo+Q2hhaXJz DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tdWx0 aW1vYiBtYWlsaW5nIGxpc3QNCj5tdWx0aW1vYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXVsdGltb2INCg0KPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0g PSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0KoaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogDQoJCQkJ IA0KU2h1YWkgR2FvDQpOYXRpb25hbCBFbmdpbmVlcmluZyBMYWIgZm9yIE5leHQgR2VuZXJhdGlv biBJbnRlcm5ldCBJbnRlcmNvbm5lY3Rpb24gRGV2aWNlcw0KQmVpamluZyBKaWFvdG9uZyBVbml2 ZXJzaXR5DQpCZWlqaW5nLCBDaGluYSwgMTAwMDQ0DQpnYW94bGhAZ21haWwuY29tDQoyMDExLTEy LTEyDQoNCg== From asaeda@sfc.wide.ad.jp Sun Dec 11 21:59:34 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 D6F5A21F8479 for ; Sun, 11 Dec 2011 21:59:34 -0800 (PST) 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 QAPrdzBUqAnR for ; Sun, 11 Dec 2011 21:59:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 22E1A21F8467 for ; Sun, 11 Dec 2011 21:59:33 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:1c0:2014:5a55:caff:fef6:4c5]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 99527278069; Mon, 12 Dec 2011 14:59:27 +0900 (JST) Date: Mon, 12 Dec 2011 14:59:31 +0900 (JST) Message-Id: <20111212.145931.127674860.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, sarikaya2012@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> 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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 05:59:35 -0000 Behcet and others, >>> This document can be found at: >>> http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt >>> >>> This mail starts a WG adoption call on this draft. >> >> I don't think there was any consensus about adoption of this draft at >> the last meeting. > > Yes, there was. Please check the minutes. Hmm, I didn't notice at all.. >> We've proposed the tunnel convergence problem solution draft; >> draft-asaeda-multimob-pmip6-extension-07 >> > Your draft and draft-zuniga present totally different approaches. They > do not overlap with each other. Right. They are totally different. >> Why you eliminate the discussions in the meeting and the chance to >> discuss in the mailing list? > > Who said so? Your draft is still up for discussion. I already saw some > comments on it in the list. So you should be happy. It is not important whose draft is adopted. Showing technical feasibility and contributions to communities is all that really matters for WGs. Ok, let's move on the discussion for draft-zuniga. Maybe draft-zuniga has some value as it can escape from the tunnel convergence problem. Briefly, the approach requires that MAG attaches *one* multicast-dedicate LMA (MTMA, the draft calls) and always uses it, instead of the regular rfc5312 based LMAs, for all external multicast streams. According to this fact, it does not provide protocol improvement and is not optimized (as all are done by operation), but simply proposes a multicast service model for PMIPv6 to escape from the tunnel convergence problem. If people agree on the adoption, it's Ok. But I cannot find the reason that it is proposed standard. Informational would fit to the current approach if adopted. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Sun Dec 11 22:21: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 A598521F86A0 for ; Sun, 11 Dec 2011 22:21:28 -0800 (PST) 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 CB5nItX7in1p for ; Sun, 11 Dec 2011 22:21:28 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22F21F8672 for ; Sun, 11 Dec 2011 22:21:21 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:1c0:2014:5a55:caff:fef6:4c5]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 53AF2278068; Mon, 12 Dec 2011 15:21:18 +0900 (JST) Date: Mon, 12 Dec 2011 15:21:22 +0900 (JST) Message-Id: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> To: sijeon79@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@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, schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 06:21:28 -0000 Hi Seil, > This discussion has been continuing repeatedly. It'd be better to move on more fundamental discussion, though.. > When the MAG is connected with other PIM-SM router not over LMA, there's no > problem. PIM-SM establishes multicast routing path using RPF algorithm > through reflecting MAG's RIB. Whether routing "over LMA" or not is not precise. > But when the MAG is connected with several LMAs including PIM-SM, MRIB > SHOULD get information from PMIP routing table but "MAG's RIB doesn't > reflect PMIP routing" (Thomas and Hitoshi agreed it). Not very precise. PIM-SM does not need to use PMIP policy routing at all. Some MRIB entries are copied from MAG's RIB, other MRIB entries are separately configured if needed. The MRIB entries may use M-Tunnel established between MAG and LMA. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Sun Dec 11 22:25: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 9ADDA21F8753 for ; Sun, 11 Dec 2011 22:25:55 -0800 (PST) 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 JAlnOtWQRDj6 for ; Sun, 11 Dec 2011 22:25:55 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 22BEC21F86F6 for ; Sun, 11 Dec 2011 22:25:55 -0800 (PST) Received: from localhost (net74-dhcp7.sfc.keio.ac.jp [133.27.74.16]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 78E33278069; Mon, 12 Dec 2011 15:25:53 +0900 (JST) Date: Mon, 12 Dec 2011 15:25:57 +0900 (JST) Message-Id: <20111212.152557.163007131.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4EE389CB.40704@informatik.haw-hamburg.de> References: <4EE24F17.9050809@informatik.haw-hamburg.de> <4EE389CB.40704@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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 06:25:55 -0000 > the "problem" that causes these repeated errors in reasoning here on > the list is the following (quoting Sri): > > 1. PMIP routing is not ordinary routing, but policy-based. > This means, it is not based on the destination address, but > on policy filters, in this case *source* addresses. For multicast tree construction, knowing receiver's address is not necessary for PIM. PIM only needs to recognize an upstream interface toward sources or RP. Therefore PMIP policy routing for MNs is *not needed* for MAG enabling PIM. > 2. The consequence is: You cannot write PMIP routing rules in a > regular routing table. We don't need it. > 3. Because you cannot write PMIP routing in *one* normal RIB, you also > cannot built a (PIM-SM) MRIB from it. > (And this is the reality-check for Hitoshi: he will see that he cannot > write an MRIB in this case ...). Not we *cannot*. It is *not needed*. Regards, -- Hitoshi Asaeda From gaoxlh@gmail.com Sun Dec 11 23:44:39 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 15AA321F8532 for ; Sun, 11 Dec 2011 23:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.904 X-Spam-Level: * X-Spam-Status: No, score=1.904 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 KPWl8DtIYMDG for ; Sun, 11 Dec 2011 23:44:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75CD321F8560 for ; Sun, 11 Dec 2011 23:44:38 -0800 (PST) Received: by iaek3 with SMTP id k3so9792400iae.31 for ; Sun, 11 Dec 2011 23:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=KOVOAb7g3QH0BRLWvLuUVss/UCKN8UBCSSxf19lptUQ=; b=gWuS0RzBp7h/OdU1/+sq3p6dIIscImSkuKoKU3rqFFURWqWPvgI1gDf0hnsPEfKgdh zG0Wf/7STh0/78mod/LdNcg/D1X5Uenk56SNWkQiNFbxlm5di4P8UsSs179dNWl0vhcv onIyxYU6GNhAtythTAJjD1FclMYqYb5aJKBDM= Received: by 10.50.12.161 with SMTP id z1mr13720327igb.85.1323675878070; Sun, 11 Dec 2011 23:44:38 -0800 (PST) Received: from John-PC ([60.247.46.41]) by mx.google.com with ESMTPS id 36sm47997883ibc.6.2011.12.11.23.44.35 (version=SSLv3 cipher=OTHER); Sun, 11 Dec 2011 23:44:37 -0800 (PST) Date: Mon, 12 Dec 2011 15:44:34 +0800 From: "Shuai Gao" To: "Hitoshi Asaeda" References: <4EE24F17.9050809@informatik.haw-hamburg.de>, , <4EE389CB.40704@informatik.haw-hamburg.de> Message-ID: <201112121544313704789@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: multimob Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 07:44:39 -0000 SGkgSGl0b3NoaSwNCglMZXQgbWUgZXhwcmVzcyBteSB1bmRlcnN0YW5kaW5nIGZvciB0aGUgZGlz Y3Vzc2VkIHByb2JsZW0gcmVjZW50bHkuICANCglJbiB5b3VyIGRyYWZ0LCBhIExNQSBvciBhbiBh ZGphY2VudCByb3V0ZXIgaXMgY2hvc2VuIGFzIGFuIHVwc3RyZWFtIHJvdXRlci4gQW5kIHlvdSBt ZW50aW9uZWQgdGhhdCB0aGUgdXBzdGVhbSByb3V0ZXIgaXMgc2VsZWN0ZWQgYnkgdGhlIFJldmVy c2UgUGF0aCBGb3J3YXJkaW5nIChSUEYpIGFsZ29yaXRobSAoc2VjdGlvbiAzLjIpLCB3aGljaCBt YXkgbm90IHdvcmsgYWN0dWFsbHkuICAgSSBhc3N1bWUgdGhhdCB5b3VyIFJQRiBhbGdvcml0aG0g aGVyZSBpcyBwZXJmb3JtZWQgdG8gZmluZCBhbiB1cHN0cmVhbSByb3V0ZXIgdG8gdGhlIFJQIG9y IHNwZWNpZmljIHJvdXRlci4gIElzIGl0IHJpZ2h0PyBJZiBzbywgSSdtIGFmcmFpZCB0aGF0IHRo ZSBMTUEgd2lsbCBoYXZlIG5vIGNoYW5jZSB0byBiZSBjaG9zZW4gYXMgdGhlIHVwc3RyZWFtIHJv dXRlciBieSB0aGUgUlBGLCBiZWNhdXNlIFBNSVAgcm91dGluZyBpcyBwb2xpY3ktYmFzZWQgcm91 dGluZyAgYXQgdGhlIE1BRyBmb3Igc3BlY2lmaWMgbW9iaWxlIHNvdXJjZXMgcmF0aGVyIHRoYW4g b3RoZXIgcm91dGVycy4gICBUaGF0J3MgdGhlIHByb2JsZW0gY29uY2VybmVkIGJ5IHRoZSBmb2xr cyBoZXJlLCBJIHRoaW5rLiANCg0KCSBIb3BlIHRvIGhlbHAgeW91Lg0KDQpTaHVhaQ0KPT09PT09 PSAyMDExLTEyLTEyIDE0OjI2OjAyIMT61NrAtNDF1tDQtLXAo7o9PT09PT09DQoNCj4+IHRoZSAi cHJvYmxlbSIgdGhhdCBjYXVzZXMgdGhlc2UgcmVwZWF0ZWQgZXJyb3JzIGluIHJlYXNvbmluZyBo ZXJlIG9uDQo+PiB0aGUgbGlzdCBpcyB0aGUgZm9sbG93aW5nIChxdW90aW5nIFNyaSk6DQo+PiAN Cj4+ICAgMS4gUE1JUCByb3V0aW5nIGlzIG5vdCBvcmRpbmFyeSByb3V0aW5nLCBidXQgcG9saWN5 LWJhc2VkLg0KPj4gICAgICBUaGlzIG1lYW5zLCBpdCBpcyBub3QgYmFzZWQgb24gdGhlIGRlc3Rp bmF0aW9uIGFkZHJlc3MsIGJ1dA0KPj4gICAgICBvbiBwb2xpY3kgZmlsdGVycywgaW4gdGhpcyBj YXNlICpzb3VyY2UqIGFkZHJlc3Nlcy4NCj4NCj5Gb3IgbXVsdGljYXN0IHRyZWUgY29uc3RydWN0 aW9uLCBrbm93aW5nIHJlY2VpdmVyJ3MgYWRkcmVzcyBpcyBub3QNCj5uZWNlc3NhcnkgZm9yIFBJ TS4gUElNIG9ubHkgbmVlZHMgdG8gcmVjb2duaXplIGFuIHVwc3RyZWFtIGludGVyZmFjZQ0KPnRv d2FyZCBzb3VyY2VzIG9yIFJQLiBUaGVyZWZvcmUgUE1JUCBwb2xpY3kgcm91dGluZyBmb3IgTU5z IGlzICpub3QNCj5uZWVkZWQqIGZvciBNQUcgZW5hYmxpbmcgUElNLg0KPg0KPj4gICAyLiBUaGUg Y29uc2VxdWVuY2UgaXM6IFlvdSBjYW5ub3Qgd3JpdGUgUE1JUCByb3V0aW5nIHJ1bGVzIGluIGEN Cj4+ICAgcmVndWxhciByb3V0aW5nIHRhYmxlLg0KPg0KPldlIGRvbid0IG5lZWQgaXQuDQo+DQo+ PiAgIDMuIEJlY2F1c2UgeW91IGNhbm5vdCB3cml0ZSBQTUlQIHJvdXRpbmcgaW4gKm9uZSogbm9y bWFsIFJJQiwgeW91IGFsc28NCj4+ICAgY2Fubm90IGJ1aWx0IGEgKFBJTS1TTSkgTVJJQiBmcm9t IGl0Lg0KPj4gICAgICAoQW5kIHRoaXMgaXMgdGhlIHJlYWxpdHktY2hlY2sgZm9yIEhpdG9zaGk6 IGhlIHdpbGwgc2VlIHRoYXQgaGUgY2Fubm90DQo+PiAgICAgIHdyaXRlIGFuIE1SSUIgaW4gdGhp cyBjYXNlIC4uLikuDQo+DQo+Tm90IHdlICpjYW5ub3QqLiBJdCBpcyAqbm90IG5lZWRlZCouDQo+ DQo+UmVnYXJkcywNCj4tLQ0KPkhpdG9zaGkgQXNhZWRhDQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5tdWx0aW1vYiBtYWlsaW5nIGxpc3QNCj5tdWx0 aW1vYkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXVs dGltb2INCg0KPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0K oaGhoaGhoaGhoaGhoaGhodbCDQrA8aOhDQogDQoJCQkJIA0KU2h1YWkgR2FvDQpOYXRpb25hbCBF bmdpbmVlcmluZyBMYWIgZm9yIE5leHQgR2VuZXJhdGlvbiBJbnRlcm5ldCBJbnRlcmNvbm5lY3Rp b24gRGV2aWNlcw0KQmVpamluZyBKaWFvdG9uZyBVbml2ZXJzaXR5DQpCZWlqaW5nLCBDaGluYSwg MTAwMDQ0DQpnYW94bGhAZ21haWwuY29tDQoyMDExLTEyLTEyDQoNCg== From asaeda@sfc.wide.ad.jp Mon Dec 12 00:00:46 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 8054321F891D for ; Mon, 12 Dec 2011 00:00:46 -0800 (PST) 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 Sg3ULfPdW0t5 for ; Mon, 12 Dec 2011 00:00:44 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0975721F889A for ; Mon, 12 Dec 2011 00:00:44 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6B1DE278088; Mon, 12 Dec 2011 17:00:40 +0900 (JST) Date: Mon, 12 Dec 2011 17:00:40 +0900 (JST) Message-Id: <20111212.170040.232978851.asaeda@sfc.wide.ad.jp> To: gaoxlh@gmail.com From: Hitoshi Asaeda In-Reply-To: <201112121544313704789@gmail.com> References: <4EE389CB.40704@informatik.haw-hamburg.de> <201112121544313704789@gmail.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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 08:00:46 -0000 Hi Shuai, > Let me express my understanding for the discussed problem recently. > In your draft, a LMA or an adjacent router is chosen as an > upstream router. And you mentioned that the upsteam router is > selected by the Reverse Path Forwarding (RPF) algorithm > (section 3.2), which may not work actually. I assume that > your RPF algorithm here is performed to find an upstream > router to the RP or specific router. Is it right? If so, I'm > afraid that the LMA will have no chance to be chosen as the > upstream router by the RPF, because PMIP routing is > policy-based routing at the MAG for specific mobile sources > rather than other routers. That's the problem concerned by > the folks here, I think. If LMA is not selected as the upstream router for some multicast channel, then operator configures M-Tunnel established between MAG and LMA and adds the routes using that M-Tunnel for appropriate group prefix of source prefix (i.e. into MRIB). This is what I'm saying. (One appology is that I eliminated GRE type M-Tunnel from -06, and -07 draft does not mention it. That change was for eliminating the complexity, but it was not correct. If you hence confuse that point, I'd apologige.) Regards, -- Hitoshi Asaeda From seiljeon@gmail.com Mon Dec 12 00:06:44 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 93CAC21F8A64 for ; Mon, 12 Dec 2011 00:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 Xmj5Nn+9BBII for ; Mon, 12 Dec 2011 00:06:43 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B508121F891D for ; Mon, 12 Dec 2011 00:06:42 -0800 (PST) Received: by dajz8 with SMTP id z8so6392425daj.31 for ; Mon, 12 Dec 2011 00:06:42 -0800 (PST) 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=JkkocaNqupy58AOxRa6bJOul2syMFIf48o/xWDyRr18=; b=QyZG7+kaZnEIeGM3tnd9rDWxtqFbu3M2pfXV0UDjfSZmJwQzQsBJQJccs7EjxIL4Yp uKcTDXQ9lYTRYXS6/FAZHsAJtgXptnAiwoREn4MxTCx4gGdwdDphzdlc68KUuyZirhCg 7bdzvG9MAYEaX/jrb6bT6uv9YjXdrJVO6KEr4= MIME-Version: 1.0 Received: by 10.68.191.8 with SMTP id gu8mr31861034pbc.36.1323677201288; Mon, 12 Dec 2011 00:06:41 -0800 (PST) Sender: seiljeon@gmail.com Received: by 10.68.50.162 with HTTP; Mon, 12 Dec 2011 00:06:41 -0800 (PST) In-Reply-To: <4EE389CB.40704@informatik.haw-hamburg.de> References: <20111209.093148.123963742.asaeda@sfc.wide.ad.jp> <4EE1ABC3.4010208@informatik.haw-hamburg.de> <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@informatik.haw-hamburg.de> <4EE389CB.40704@informatik.haw-hamburg.de> Date: Mon, 12 Dec 2011 17:06:41 +0900 X-Google-Sender-Auth: QJb8Fvnp_eK3_lo3Q0KvFzS5y_c Message-ID: From: seil jeon To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=e89a8ff1c094614f1804b3e09d50 Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 08:06:44 -0000 --e89a8ff1c094614f1804b3e09d50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Thomas, Please see inline. Regards, Seil Jeon 2011/12/11 Thomas C. Schmidt > Hi Seil, > > > On 10.12.2011 02:15, seil jeon wrote: > > > But when the MAG is connected with several LMAs including PIM-SM, MRIB >> SHOULD get information from PMIP routing table but "MAG's RIB doesn't >> reflect PMIP routing" (Thomas and Hitoshi agreed it). >> >> > the "problem" that causes these repeated errors in reasoning here on the > list is the following (quoting Sri): > > > 1. PMIP routing is not ordinary routing, but policy-based. > This means, it is not based on the destination address, but > on policy filters, in this case *source* addresses. > > 2. The consequence is: You cannot write PMIP routing rules in a regular > routing table. > > 3. Because you cannot write PMIP routing in *one* normal RIB, you also > cannot built a (PIM-SM) MRIB from it. > (And this is the reality-check for Hitoshi: he will see that he canno= t > write an MRIB in this case ...). > > In general, there is no big deal about this. The fuzz is only that draft-asaeda-multimob-pmip6-**extension-07 is built upon an error from misunderstanding PMIP routing ... =3D> My intention was to clarify the differences between you and Hitoshi. Now, I think the issue is getting more clear. Your problem of draft http://tools.ietf.org/id/** draft-zuniga-multimob-pmipv6-**ropt-01.txtis a different one. You need to describe deployment of direct routing (e.g, PIM) at a MAG that runs PMIP routing (including tunnel interfaces) and normal routing in the access network (the non-PMIP case). You should explain this in your draft so well that readers can understand and successfully deploy. In the current version you just say "turn on PIM" ... and that's not all, I guess. =3D> Yes, definitely. As I told it in the previous list, it will be added explicitly and arrange two solutions with consistence of written style. > Best, > > Thomas > > 2011/12/10 Thomas C. Schmidt >> >> >> >> >> >> Hitoshi, >> >> >> On 09.12.2011 03:42, Hitoshi Asaeda wrote: >> >> Then Sri stepped in and explained the same thing again: The M= AG >> performs policy-based routing according to policy filters, no= t >> according to a regular RIB. >> >> >> Then we should ask you one thing. >> Why your source mobility draft introduces PIM-SM and Bidir PIM >> on MAG? >> >> In Section 5, your source mobility draft says; >> >> "a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-P= IM >> [RFC5015] deployed at the MAGs." >> >> >> We are considering the direct mcast routing deployment (not >> following PMIP) - for receivers, this is the solution of Seil. There >> is no problem with it. >> >> Your proposal under debate is: Use PIM-SM on PMIP tunnels and in >> concordance with PMIP routing, which is a completely different story. >> >> However, to resolve the debate, there is a very simple reality-check: >> >> For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs >> associated to either LMA), please just write down *one* PIM-SM >> multicast routing table that accounts for PMIP routing and works for >> all MNs attached to the MAG. >> >> If you can do so correctly, you have proved that your approach is >> feasible. >> >> Thanks, >> >> Thomas >> >> >> >> -- >> >> Prof. Dr. Thomas C. Schmidt >> =B0 Hamburg University of Applied Sciences Berliner >> Tor 7 =B0 >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, >> Germany =B0 >> =B0 http://www.haw-hamburg.de/inet Fon: >> +49-40-42875-8452 =B0 >> =B0 http://www.informatik.haw-__**hamburg.de/~schmidt >> > >> Fax: >> +49-40-42875-8409 =B0 >> >> ______________________________**___________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/multimob >> > >> >> >> >> >> >> >> ______________________________**_________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/**listinfo/multimob >> > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-**hamburg.de/~schmidt Fax: +49-40-42875-8409 =B0 > --e89a8ff1c094614f1804b3e09d50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
Please see inline.
=A0
Regards,
=A0
Seil Jeon
=A0
2011/12/11 Thomas C. Schmidt &= lt;schmidt@informatik.= haw-hamburg.de>
Hi Seil,=20


On 10.12.2011 02:15, seil jeon wrote:


But when the MAG is connected with se= veral LMAs including PIM-SM, MRIB
SHOULD get information from PMIP routi= ng table but "MAG's RIB doesn't
reflect PMIP routing" (Thomas and Hitoshi agreed it).


the "problem" that causes these repeated errors in = reasoning here on the list is the following (quoting Sri):


=A01.= PMIP routing is not ordinary routing, but policy-based.
=A0 =A0 This means, it is not based on the destination address, but
=A0 = =A0 on policy filters, in this case *source* addresses.

=A02. The co= nsequence is: You cannot write PMIP routing rules in a regular routing tabl= e.

=A03. Because you cannot write PMIP routing in *one* normal RIB, you al= so cannot built a (PIM-SM) MRIB from it.
=A0 =A0 (And this is the realit= y-check for Hitoshi: he will see that he cannot write an MRIB in this case = ...).


In general, there is no big deal about this. The fuzz is only that= draft-asaeda-multimob-pmip6-extension-07 is built upon an error fro= m misunderstanding PMIP routing ...
=3D> My intention was to clarify the differences between you and Hi= toshi. Now, I think the issue is getting more clear.


Your problem of draft http://tools.ietf.o= rg/id/draft-zuniga-multimob-pmipv6-ropt-01.txt is a diffe= rent one. You need to describe deployment of direct routing (e.g, PIM) at a= MAG that runs PMIP routing (including tunnel interfaces) and normal routin= g in the access network (the non-PMIP case). You should explain this in you= r draft so well that readers can understand and successfully deploy. In the= current version you just say "turn on PIM" ... and that's no= t all, I guess.

=A0=3D> Yes, definitely. As I told it in the previous list, it will= be added explicitly and arrange two solutions with consistence of written = style.
=A0
=A0
Best,

Thomas

2011/12/10 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de
<mailto:schmidt@informatik.haw-hamburg.de>>=20


=A0 =A0Hitoshi,


=A0 =A0On 09.12.2011 0= 3:42, Hitoshi Asaeda wrote:

=A0 =A0 =A0 =A0 =A0 =A0Then Sri stepped = in and explained the same thing again: The MAG
=A0 =A0 =A0 =A0 =A0 =A0pe= rforms policy-based routing according to policy filters, not
=A0 =A0 =A0 =A0 =A0 =A0according to a regular RIB.


=A0 =A0 =A0 = =A0Then we should ask you one thing.
=A0 =A0 =A0 =A0Why your source mobi= lity draft introduces PIM-SM and Bidir PIM
=A0 =A0 =A0 =A0on MAG?
=A0 =A0 =A0 =A0In Section 5, your source mobility draft says;

=A0 =A0 =A0 =A0"a multicast routing protocol such as PIM-SM [RFC46= 01] or BIDIR-PIM
=A0 =A0 =A0 =A0 =A0 =A0[RFC5015] deployed at the MAGs.&= quot;


=A0 =A0We are considering the direct mcast routing deploym= ent (not
=A0 =A0following PMIP) - for receivers, this is the solution of= Seil. There
=A0 =A0is no problem with it.

=A0 =A0Your proposal under debate is: = Use PIM-SM on PMIP tunnels and in
=A0 =A0concordance with PMIP routing, = which is a completely different story.

=A0 =A0However, to resolve th= e debate, there is a very simple reality-check:

=A0 =A0 =A0For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs=A0 =A0associated to either LMA), please just write down *one* PIM-SM
= =A0 =A0multicast routing table that accounts for PMIP routing and works for=
=A0 =A0all MNs attached to the MAG.

=A0 =A0 =A0If you can do so correctly, you have proved that your approa= ch is
=A0 =A0feasible.

=A0 =A0Thanks,

=A0 =A0Thomas


=A0 =A0--

=A0 =A0Prof. Dr. Thomas C. Schmidt
=A0 =A0=B0 = Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = Berliner
=A0 =A0Tor 7 =B0
=A0 =A0=B0 Dept. Informatik, Internet Technologies Grou= p =A0 =A020099 Hamburg,
=A0 =A0Germany =B0
=A0 =A0=B0 http://www.haw-hamburg.de/ine= t =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon:
=A0 =A0+49-40-42875-8452 =B0
=A0 =A0=B0 http://www.inform= atik.haw-__hamburg.de/~schmidt
=A0 =A0<http://www.informa= tik.haw-hamburg.de/~schmidt> =A0 =A0Fax:
=A0 =A0+49-40-42875-8409 =B0

=A0 =A0_________________________________________________
=A0 =A0multimob mailing list
=A0 =A0multimob@ietf.org <m= ailto:multimob@ietf.= org>
=A0 =A0https://www.ietf.org/mailman/__listinfo/multimob
= =A0 =A0<https://www.ietf.org/mailman/listinfo/multimob>= =20





______________________________= _________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/m= ailman/listinfo/multimob

--

Prof. Dr. Thomas C. Schmidt
=B0 Hamburg= University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Berline= r Tor 7 =B0
=B0 Dept. Informatik, Internet Technologies Group =A0 =A0200= 99 Hamburg, Germany =B0
=B0 http://www= .haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42= 875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt =A0 =A0Fax: +49-40-42875-8409 =B0

--e89a8ff1c094614f1804b3e09d50-- From sijeon79@gmail.com Mon Dec 12 00:20: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 EF03721F84FC for ; Mon, 12 Dec 2011 00:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 8dhjc7a7kjJU for ; Mon, 12 Dec 2011 00:20:00 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2139C21F84B1 for ; Mon, 12 Dec 2011 00:20:00 -0800 (PST) Received: by ghrr18 with SMTP id r18so4398301ghr.31 for ; Mon, 12 Dec 2011 00:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:x-mimeole; bh=BH90ufupa/KLv6rTKnEBJFUdb6A+pQHeTuXhVhPUglc=; b=tZ8cS5Esmi7fV4xvE3QsVC8dNpW7zvvl4byeg9AdAzQFTQlVIoFX7QvwNthh95Hfd/ aWba/PacNdDPfRd0uqsmxYlGdGRXdCcxHVK1UZQEeuyttGA/XxU9W83g95VOj8mOAzup 7EOvDCW33FBIHzkWf+8GdzodJgu36iNkj9mxI= Received: by 10.236.91.67 with SMTP id g43mr23537684yhf.68.1323677997619; Mon, 12 Dec 2011 00:19:57 -0800 (PST) Received: from sijeonPC ([220.149.84.224]) by mx.google.com with ESMTPS id d6sm48328515anm.16.2011.12.12.00.19.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Dec 2011 00:19:57 -0800 (PST) From: "Seil Jeon" To: "'Shuai Gao'" , "'sarikaya2012'" References: <201112121102479725697@gmail.com> In-Reply-To: <201112121102479725697@gmail.com> Date: Mon, 12 Dec 2011 17:19:49 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acy4epHjGc3FKja8Rg6e1gMXL1PGYAAKzyPw X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Cc: 'multimob' Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 08:20:01 -0000 Hi Shuai, Thanks for valuable comment in your busy time. Please see inline. Your regards, Seil Jeon=20 =20 --------------------------------------------------------- =20 Soongsil Univ. Ubiquitous Network Research Center (SUNRC) =20 Homepage: http://sites.google.com/site/seiljeon =20 -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Shuai Gao Sent: Monday, December 12, 2011 12:03 PM To: sarikaya2012 Cc: multimob Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Hi all, For the tunnel convergence problem, we have discussed for very long = time. Now the draft-zuniga-multimob-pmipv6-ropt-01 looks more general and I support to adopt this draft as the WG ID to speed up the standard = process.=20 For this draft, I have some comments for consideration. 1) The association scheme among the MAGs and the MTMAs is not clear. The MAG is associated with a MTMA according to group channel address or = MN? 2) In 3.2 "Deployment Scenarios", I suggest to add a discussion = about the scenario in which a MN is receiving two different multicast service associated with two different MTMAs. 3) The choice about Local subscription or Remote subscription need = to be clarifed to be more feasible for deployment.=20 =3D> Definitely. It was requested for updated version in Taipei meeting. = And we'll add the description of the choice of local/remote subscription. 4) The written style of section 4 need to be consistant with other sections.=20 =3D> Due to submission deadline, merging two solutions was suddenly = made. During the process, there was some inconsistence of written style. In updated version, it will be arranged with consistence. Shuai=20 =09 =3D=3D=3D=3D=3D=3D=3D 2011-12-09 04:53:41 = =C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA=3D=3D=3D=3D=3D=3D=3D >Hello all, > There was consensus on the tunnel convergence solution draft in = Taipei. > This mail is to confirm the consensus. > > >This document can be found at: >http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt > >This mail starts a WG adoption call on this draft. > >The intended status for this document is proposed standard. >If adopted, the draft will be named: > >draft-ietf-multimob-pmipv6-tunnel-convergence. > >Please your comments by December 15, 2011. > > >Chairs >_______________________________________________ >multimob mailing list >multimob@ietf.org >https://www.ietf.org/mailman/listinfo/multimob =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D =09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2 =C0=F1=A3=A1 =20 =20 Shuai Gao National Engineering Lab for Next Generation Internet Interconnection Devices Beijing Jiaotong University Beijing, China, 100044 = gaoxlh@gmail.com 2011-12-12 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From seiljeon@gmail.com Mon Dec 12 00:42:45 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 E5F0221F8A7E for ; Mon, 12 Dec 2011 00:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.973 X-Spam-Level: X-Spam-Status: No, score=-2.973 tagged_above=-999 required=5 tests=[AWL=0.625, 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 aUDCE8nUAsfd for ; Mon, 12 Dec 2011 00:42:45 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E01A21F8A6F for ; Mon, 12 Dec 2011 00:42:45 -0800 (PST) Received: by dajz8 with SMTP id z8so6422883daj.31 for ; Mon, 12 Dec 2011 00:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=M5J+QQkduITIxbIqZMu2UYcF6pgcafLBBZcjGYBaNR4=; b=qtMIwT+kGzKefmuVqkCT14vOOsxIVzP9EK+ub87KIP9W8jzLzn7O4BCWQlVjH1AEtg Lk9zwwwyrk4ApHDx5sfLPz8YOvgYhDcJ1xoCgovk0xAinHxshXTVwtBBp9SH81cGSPkI FSh4WGokF4MnHbu57yk7ccfWBiTRH83SddRy0= MIME-Version: 1.0 Received: by 10.68.191.8 with SMTP id gu8mr32151472pbc.36.1323679364137; Mon, 12 Dec 2011 00:42:44 -0800 (PST) Sender: seiljeon@gmail.com Received: by 10.68.50.162 with HTTP; Mon, 12 Dec 2011 00:42:43 -0800 (PST) Date: Mon, 12 Dec 2011 17:42:43 +0900 X-Google-Sender-Auth: OwadJl1F2k43c7mIlXeN2xZl8-I Message-ID: From: seil jeon To: Hitoshi Asaeda Content-Type: multipart/alternative; boundary=e89a8ff1c0944bc48c04b3e11e63 Cc: multimob@ietf.org, schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] Comment on draft-asaeda-multimob-pmip6-extension-07 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, 12 Dec 2011 08:42:46 -0000 --e89a8ff1c0944bc48c04b3e11e63 Content-Type: text/plain; charset=ISO-8859-1 Hi Hitoshi and all, I moved the issue discussion to other title. Regarding on the issue of Hitoshi's idea, we better use this title. Please see below. 2011/12/12 Hitoshi Asaeda > Hi Seil, > > > This discussion has been continuing repeatedly. > > It'd be better to move on more fundamental discussion, though.. > > > When the MAG is connected with other PIM-SM router not over LMA, there's > no > > problem. PIM-SM establishes multicast routing path using RPF algorithm > > through reflecting MAG's RIB. > > Whether routing "over LMA" or not is not precise. > > > But when the MAG is connected with several LMAs including PIM-SM, MRIB > > SHOULD get information from PMIP routing table but "MAG's RIB doesn't > > reflect PMIP routing" (Thomas and Hitoshi agreed it). > > Not very precise. > PIM-SM does not need to use PMIP policy routing at all. > Some MRIB entries are copied from MAG's RIB, other MRIB entries are > separately configured if needed. The MRIB entries may use M-Tunnel > established between MAG and LMA. > > Regards, > -- > Hitoshi Asaeda > O.K. If my understainding is correct, your PIM-SM idea is based on not "PMIP tunnel" but "M-Tunnel" between MAG and LMA to choose one LMA using RPF algorithm. And "M-Tunnel" information is in MAG's RIB. And if then, the upstream router of MAG has nothing to be an LMA, it can be another dedicated server for multicast support because it does not use PMIP tunnel. So, your idea appear to me as one of specific PIM-SM application method over dedicated multicast architecture. --e89a8ff1c0944bc48c04b3e11e63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hitoshi and all,
=A0
=A0
I moved the issue discussion to other title.
=A0
Regarding on the issue of Hitoshi's idea, we=A0better=A0use this t= itle.

Please see below.
=A0
=A0
2011/12/12 Hitoshi Asaeda <= asaeda@sfc.wide.ad.jp>
Hi Seil,

> This discussion has been continuing repeatedly.<= br>
It'd be better to move on more fundamental discussion, tho= ugh..

> When the MAG is connected with other PIM-SM rout= er not over LMA, there's no
> problem. PIM-SM establishes multica= st routing path using RPF algorithm
> through reflecting MAG's RI= B.

Whether routing "over LMA" or not is not precise.

> But when the MAG is connected with several LMAs = including PIM-SM, MRIB
> SHOULD get information from PMIP routing tab= le but "MAG's RIB doesn't
> reflect PMIP routing" (= Thomas and Hitoshi agreed it).

Not very precise.
PIM-SM does not need to use PMIP policy rout= ing at all.
Some MRIB entries are copied from MAG's RIB, other MRIB = entries are
separately configured if needed. The MRIB entries may use M-= Tunnel
established between MAG and LMA.

Regards,
= --
Hitoshi Asaeda
=

=A0
O.K. If my understainding is correct, your PIM-SM idea is based on not= "PMIP tunnel" but "M-Tunnel" between MAG and LMA to ch= oose one LMA using RPF algorithm.
And "M-Tunnel" information is in MAG's RIB.
=A0
And if then, the upstream router of MAG has nothing to be an LMA, it c= an be another dedicated server for multicast=A0support=A0because it does no= t use PMIP tunnel. So, your idea appear to me as one of specific PIM-SM app= lication method over dedicated multicast architecture.
=A0
=A0
--e89a8ff1c0944bc48c04b3e11e63-- From asaeda@sfc.wide.ad.jp Mon Dec 12 01:26:56 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 A7C9221F8A97 for ; Mon, 12 Dec 2011 01:26:56 -0800 (PST) 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 ZrSRRtzBsN+Q for ; Mon, 12 Dec 2011 01:26:56 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 12D1421F8A7E for ; Mon, 12 Dec 2011 01:26:56 -0800 (PST) Received: from localhost (dhcp-143-200.sfc.wide.ad.jp [203.178.143.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4D7A5278079; Mon, 12 Dec 2011 18:26:53 +0900 (JST) Date: Mon, 12 Dec 2011 18:26:51 +0900 (JST) Message-Id: <20111212.182651.233678588.asaeda@sfc.wide.ad.jp> To: sijeon79@gmail.com From: Hitoshi Asaeda In-Reply-To: References: 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] Comment on draft-asaeda-multimob-pmip6-extension-07 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, 12 Dec 2011 09:26:56 -0000 Hi Seil, >> PIM-SM does not need to use PMIP policy routing at all. >> Some MRIB entries are copied from MAG's RIB, other MRIB entries are >> separately configured if needed. The MRIB entries may use M-Tunnel >> established between MAG and LMA. > > O.K. If my understainding is correct, your PIM-SM idea is based on not > "PMIP tunnel" but "M-Tunnel" between MAG and LMA to choose one LMA using > RPF algorithm. If LMA is not an upstream router in MAG's RIB but if it should be in MAG's MRIB, M-Tunnel is used to attach. > And "M-Tunnel" information is in MAG's RIB. Precisely, "M-Tunnel information is in MAG's MRIB". > And if then, the upstream router of MAG has nothing to be an LMA, it can be > another dedicated server for multicast support because it does not use PMIP > tunnel. So, your idea appear to me as one of specific PIM-SM application > method over dedicated multicast architecture. I don't understand what "dedicated server" and "dedicated multicast architecture" mean. Let's see the case of direct routing. If operator thinks streams for some group (or source) prefixes do not need to go through LMA (as they are direct routing), MAG enabling PIM-SM simply forwards PIM join messages to its adjacent multicast router without M-Tunnel and can get the streams natively. Regards, -- Hitoshi Asaeda From gaoxlh@gmail.com Mon Dec 12 01:28: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 8FC4621F869E for ; Mon, 12 Dec 2011 01:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.254 X-Spam-Level: * X-Spam-Status: No, score=1.254 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 ArXXlLBEmCVu for ; Mon, 12 Dec 2011 01:28:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3FB21F8564 for ; Mon, 12 Dec 2011 01:28:40 -0800 (PST) Received: by iaek3 with SMTP id k3so9949815iae.31 for ; Mon, 12 Dec 2011 01:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:references:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=jcBPMdTCQEkNeWrWwLQRJpfKomuxs6Odvp183SK5rQU=; b=uyppYX4uW6aTWvrd+1m58EKyd5GWOjug+LRyEEFgNo49rmHpctNKe7deh4adpJtLqZ b4li3Lxaa6wiOcR/xnjvQYOqgXdocHkAEyLb0JNor/cbWv8heZ8BSwPC/VyGqjRK5niJ Qn7PvxPZPY0PHdTazwnlTKr/mr5uMO8tV/1cI= Received: by 10.42.175.134 with SMTP id ba6mr533107icb.23.1323682119790; Mon, 12 Dec 2011 01:28:39 -0800 (PST) Received: from John-PC ([60.247.46.41]) by mx.google.com with ESMTPS id wo4sm39518323igc.5.2011.12.12.01.28.36 (version=SSLv3 cipher=OTHER); Mon, 12 Dec 2011 01:28:38 -0800 (PST) Date: Mon, 12 Dec 2011 17:28:36 +0800 From: "Shuai Gao" To: "Hitoshi Asaeda" References: , <4EE389CB.40704@informatik.haw-hamburg.de>, <201112121544313704789@gmail.com> Message-ID: <201112121728329658607@gmail.com> X-mailer: Foxmail 6, 14, 103, 30 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: multimob Subject: Re: [multimob] WG adoption call ondraft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 09:28:40 -0000 SGkgSGl0b3NoaSwNCg0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuCQ0KDQo9PT09PT09 IDIwMTEtMTItMTIgMTY6MDA6NDUgxPrU2sC00MXW0NC0tcCjuj09PT09PT0NCg0KPkhpIFNodWFp LA0KPg0KPj4gCUxldCBtZSBleHByZXNzIG15IHVuZGVyc3RhbmRpbmcgZm9yIHRoZSBkaXNjdXNz ZWQgcHJvYmxlbSByZWNlbnRseS4gIA0KPj4gCUluIHlvdXIgZHJhZnQsIGEgTE1BIG9yIGFuIGFk amFjZW50IHJvdXRlciBpcyBjaG9zZW4gYXMgYW4NCj4+IAl1cHN0cmVhbSByb3V0ZXIuIEFuZCB5 b3UgbWVudGlvbmVkIHRoYXQgdGhlIHVwc3RlYW0gcm91dGVyIGlzDQo+PiAJc2VsZWN0ZWQgYnkg dGhlIFJldmVyc2UgUGF0aCBGb3J3YXJkaW5nIChSUEYpIGFsZ29yaXRobQ0KPj4gCShzZWN0aW9u IDMuMiksIHdoaWNoIG1heSBub3Qgd29yayBhY3R1YWxseS4gICBJIGFzc3VtZSB0aGF0DQo+PiAJ eW91ciBSUEYgYWxnb3JpdGhtIGhlcmUgaXMgcGVyZm9ybWVkIHRvIGZpbmQgYW4gdXBzdHJlYW0N Cj4+IAlyb3V0ZXIgdG8gdGhlIFJQIG9yIHNwZWNpZmljIHJvdXRlci4gIElzIGl0IHJpZ2h0PyBJ ZiBzbywgSSdtDQo+PiAJYWZyYWlkIHRoYXQgdGhlIExNQSB3aWxsIGhhdmUgbm8gY2hhbmNlIHRv IGJlIGNob3NlbiBhcyB0aGUNCj4+IAl1cHN0cmVhbSByb3V0ZXIgYnkgdGhlIFJQRiwgYmVjYXVz ZSBQTUlQIHJvdXRpbmcgaXMNCj4+IAlwb2xpY3ktYmFzZWQgcm91dGluZyAgYXQgdGhlIE1BRyBm b3Igc3BlY2lmaWMgbW9iaWxlIHNvdXJjZXMNCj4+IAlyYXRoZXIgdGhhbiBvdGhlciByb3V0ZXJz LiAgIFRoYXQncyB0aGUgcHJvYmxlbSBjb25jZXJuZWQgYnkNCj4+IAl0aGUgZm9sa3MgaGVyZSwg SSB0aGluay4gDQo+DQo+SWYgTE1BIGlzIG5vdCBzZWxlY3RlZCBhcyB0aGUgdXBzdHJlYW0gcm91 dGVyIGZvciBzb21lIG11bHRpY2FzdA0KPmNoYW5uZWwsIHRoZW4gb3BlcmF0b3IgY29uZmlndXJl cyBNLVR1bm5lbCBlc3RhYmxpc2hlZCBiZXR3ZWVuIE1BRyBhbmQNCj5MTUEgYW5kIGFkZHMgdGhl IHJvdXRlcyB1c2luZyB0aGF0IE0tVHVubmVsIGZvciBhcHByb3ByaWF0ZSBncm91cA0KPnByZWZp eCBvZiBzb3VyY2UgcHJlZml4IChpLmUuIGludG8gTVJJQikuIFRoaXMgaXMgd2hhdCBJJ20gc2F5 aW5nLg0KDQpTbyB5b3VyIHNvbHV0aW9uIGlzIGFkZGluZyBzcGVjaWFsIHBvbGljeS1iYXNlZCBt dWx0aWNhc3Qgcm91dGluZyBhdCB0aGUgTUFHPyAgSXQgbG9va3Mgb2ssIGJ1dCBtYXkgYmUNCmNv bXBsZXguIFlvdSBzaG91bGQgY2xhcmlmeSB0aGlzIGFuZCBjYWxsIGZvciBtb3JlIGRpc2N1c3Np b25zIG9uIGl0cyBmZWFzaWJpbGl0eS4gDQoNCj4oT25lIGFwcG9sb2d5IGlzIHRoYXQgSSBlbGlt aW5hdGVkIEdSRSB0eXBlIE0tVHVubmVsIGZyb20gLTA2LCBhbmQgLTA3DQo+ZHJhZnQgZG9lcyBu b3QgbWVudGlvbiBpdC4gVGhhdCBjaGFuZ2Ugd2FzIGZvciBlbGltaW5hdGluZyB0aGUNCj5jb21w bGV4aXR5LCBidXQgaXQgd2FzIG5vdCBjb3JyZWN0LiBJZiB5b3UgaGVuY2UgY29uZnVzZSB0aGF0 IHBvaW50LA0KPkknZCBhcG9sb2dpZ2UuKQ0KPg0KPlJlZ2FyZHMsDQo+LS0NCj5IaXRvc2hpIEFz YWVkYQ0KDQo9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCgkJCQ0KDQqh oaGhoaGhoaGhoaGhoaGh1sINCsDxo6ENCiANCgkJCQkgDQpTaHVhaSBHYW8NCk5hdGlvbmFsIEVu Z2luZWVyaW5nIExhYiBmb3IgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0IEludGVyY29ubmVjdGlv biBEZXZpY2VzDQpCZWlqaW5nIEppYW90b25nIFVuaXZlcnNpdHkNCkJlaWppbmcsIENoaW5hLCAx MDAwNDQNCmdhb3hsaEBnbWFpbC5jb20NCjIwMTEtMTItMTINCg0K From asaeda@sfc.wide.ad.jp Mon Dec 12 01:36: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 1670C21F8AF8 for ; Mon, 12 Dec 2011 01:36:05 -0800 (PST) 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 S25LPowDhGHB for ; Mon, 12 Dec 2011 01:36:04 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2704B21F8AF5 for ; Mon, 12 Dec 2011 01:36:04 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1A132278079; Mon, 12 Dec 2011 18:36:02 +0900 (JST) Date: Mon, 12 Dec 2011 18:36:01 +0900 (JST) Message-Id: <20111212.183601.211265136.asaeda@sfc.wide.ad.jp> To: gaoxlh@gmail.com From: Hitoshi Asaeda In-Reply-To: <201112121728329658607@gmail.com> References: <4EE389CB.40704@informatik.haw-hamburg.de> <201112121544313704789@gmail.com> <201112121728329658607@gmail.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] WG adoption call ondraft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 09:36:05 -0000 >>If LMA is not selected as the upstream router for some multicast >>channel, then operator configures M-Tunnel established between MAG and >>LMA and adds the routes using that M-Tunnel for appropriate group >>prefix of source prefix (i.e. into MRIB). This is what I'm saying. > > So your solution is adding special policy-based multicast routing at > the MAG? It looks ok, but may be > complex. You should clarify this and call for more discussions on > its feasibility. Well, I don't know this is "special policy-based" routing. Because separating RIB and MRIB is very common. One possible complexity is that we need to provide an upstream router selection mechanism for the case that multiple LMAs having different M-Tunnels could become an upstream router for the same prefix. It is not mentioned in -07 but it will be addressed in the revised draft. Regards, -- Hitoshi Asaeda From seiljeon@gmail.com Mon Dec 12 03:12: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 895EC21F8B22 for ; Mon, 12 Dec 2011 03:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, 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 2KzjzQFePnjJ for ; Mon, 12 Dec 2011 03:12:54 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3CBD21F8B17 for ; Mon, 12 Dec 2011 03:12:54 -0800 (PST) Received: by dajz8 with SMTP id z8so6564346daj.31 for ; Mon, 12 Dec 2011 03:12:54 -0800 (PST) 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=FhoDNzMQLF4qkqVh4m/LEwXmBMoOn6XFciaKUIbrT80=; b=CBjOEdlUgr/+KRYL7YaODMFYPnYkyROn96CvAHeftlpouZr/7mwPVoeV00kKnS0GCZ 6AJ3vHJnmsKFL7CaBFbmi7QIJkMlW+8Pz3/UpHZ+S+polwk4ErmFQvKgRhc9SYBc0d0g mmKxBAhKnnALBmFS1Fl2pY/5/56RmT6vvViD0= MIME-Version: 1.0 Received: by 10.68.73.104 with SMTP id k8mr32555173pbv.104.1323688374627; Mon, 12 Dec 2011 03:12:54 -0800 (PST) Sender: seiljeon@gmail.com Received: by 10.68.50.162 with HTTP; Mon, 12 Dec 2011 03:12:54 -0800 (PST) In-Reply-To: <20111212.182651.233678588.asaeda@sfc.wide.ad.jp> References: <20111212.182651.233678588.asaeda@sfc.wide.ad.jp> Date: Mon, 12 Dec 2011 20:12:54 +0900 X-Google-Sender-Auth: d4n0XuIBWXfjVspkkDzVhEt7J4o Message-ID: From: seil jeon To: Hitoshi Asaeda Content-Type: multipart/alternative; boundary=f46d041706e35cecb804b3e3377b Cc: multimob@ietf.org Subject: Re: [multimob] Comment on draft-asaeda-multimob-pmip6-extension-07 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, 12 Dec 2011 11:12:55 -0000 --f46d041706e35cecb804b3e3377b Content-Type: text/plain; charset=ISO-8859-1 Hi Hitoshi, Please see inline. 2011/12/12 Hitoshi Asaeda > Hi Seil, > > >> PIM-SM does not need to use PMIP policy routing at all. > >> Some MRIB entries are copied from MAG's RIB, other MRIB entries are > >> separately configured if needed. The MRIB entries may use M-Tunnel > >> established between MAG and LMA. > > > > O.K. If my understainding is correct, your PIM-SM idea is based on not > > "PMIP tunnel" but "M-Tunnel" between MAG and LMA to choose one LMA using > > RPF algorithm. > > If LMA is not an upstream router in MAG's RIB but if it should be in > MAG's MRIB, M-Tunnel is used to attach. > > > And "M-Tunnel" information is in MAG's RIB. > > Precisely, "M-Tunnel information is in MAG's MRIB". > > > And if then, the upstream router of MAG has nothing to be an LMA, it can > be > > another dedicated server for multicast support because it does not use > PMIP > > tunnel. So, your idea appear to me as one of specific PIM-SM application > > method over dedicated multicast architecture. > > I don't understand what "dedicated server" and "dedicated multicast > architecture" mean. > > => The multicast replicator, as it is, to deliver the multicast packets to all attached MAGs (e.g. MTMA named in draft-zuniga-multimob-pmipv6-ropt). > Let's see the case of direct routing. > If operator thinks streams for some group (or source) prefixes do not > need to go through LMA (as they are direct routing), MAG enabling > PIM-SM simply forwards PIM join messages to its adjacent multicast > router without M-Tunnel and can get the streams natively. > > => The issue is not the use of PIM-SM based direct routing. In my sense, the issue was raised because you has been calling the entity, establishing "M-Tunnel" with an MAG, an LMA. As I told you before, the entity cannot be an LMA but may be closely to a sort of multicast replicator server deliverying multicast packets to attached MAGs. > Regards, > -- > Hitoshi Asaeda > --f46d041706e35cecb804b3e3377b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hitoshi,
=A0
Please see inline.

2011/12/12 Hitoshi Asaeda <= asaeda@sfc.wide.ad.jp>
Hi Seil,

>> PIM-SM does not need to use PMIP policy rout= ing at all.
>> Some MRIB entries are copied from MAG's RIB, ot= her MRIB entries are
>> separately configured if needed. The MRIB = entries may use M-Tunnel
>> established between MAG and LMA.
>
> O.K. If my understainding is correct, your PIM-SM id= ea is based on not
> "PMIP tunnel" but "M-Tunnel"= between MAG and LMA to choose one LMA using
> RPF algorithm.

If LMA is not an upstream router in MAG's RIB but if it should be= in
MAG's MRIB, M-Tunnel is used to attach.

> And "M-Tunnel" information is in MAG&#= 39;s RIB.

Precisely, "M-Tunnel information is in MAG'= s MRIB".

> And if then, the upstream router of MAG has noth= ing to be an LMA, it can be
> another dedicated server for multicast = support because it does not use PMIP
> tunnel. So, your idea appear t= o me as one of specific PIM-SM application
> method over dedicated multicast architecture.

I don't= understand what "dedicated server" and "dedicated multicast=
architecture" mean.

=A0
=3D> The multicast replicator, as it is,=A0to deliver the multicast= packets to all attached MAGs (e.g. MTMA named in draft-zuniga-multimob-pmi= pv6-ropt).
=A0
Let's see the case of direct rout= ing.
If operator thinks streams for some group (or source) prefixes do n= ot
need to go through LMA (as they are direct routing), MAG enabling
PIM-SM= simply forwards PIM join messages to its adjacent multicast
router with= out M-Tunnel and can get the streams natively.

=A0
=3D> The issue is not the use of PIM-SM based direct routing. In my= sense, the issue was raised because you has been calling the entity, estab= lishing "M-Tunnel" with an MAG, an LMA. As I told you before, the= entity cannot be an LMA but may be closely to a sort of multicast replicat= or server deliverying multicast packets to attached MAGs.
=A0
=A0
=A0
Regards,
--
Hitoshi Asaeda

--f46d041706e35cecb804b3e3377b-- From asaeda@sfc.wide.ad.jp Mon Dec 12 06:17:07 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 6B2E921F8B26 for ; Mon, 12 Dec 2011 06:17:07 -0800 (PST) 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 yPMXgNjxwPyE for ; Mon, 12 Dec 2011 06:17:07 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF221F8B16 for ; Mon, 12 Dec 2011 06:17:06 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 001A5278086; Mon, 12 Dec 2011 23:17:02 +0900 (JST) Date: Mon, 12 Dec 2011 23:17:02 +0900 (JST) Message-Id: <20111212.231702.155007420.asaeda@sfc.wide.ad.jp> To: sijeon79@gmail.com From: Hitoshi Asaeda In-Reply-To: <20111212.182651.233678588.asaeda@sfc.wide.ad.jp> References: <20111212.182651.233678588.asaeda@sfc.wide.ad.jp> 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] Comment on draft-asaeda-multimob-pmip6-extension-07 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, 12 Dec 2011 14:17:07 -0000 >> And if then, the upstream router of MAG has nothing to be an LMA, it can be >> another dedicated server for multicast support because it does not use PMIP >> tunnel. So, your idea appear to me as one of specific PIM-SM application >> method over dedicated multicast architecture. > > I don't understand what "dedicated server" and "dedicated multicast > architecture" mean. => The multicast replicator, as it is, to deliver the multicast packets to all attached MAGs (e.g. MTMA named in draft-zuniga-multimob-pmipv6-ropt). We don't need to assume to have such special entity. > Let's see the case of direct routing. > If operator thinks streams for some group (or source) prefixes do not > need to go through LMA (as they are direct routing), MAG enabling > PIM-SM simply forwards PIM join messages to its adjacent multicast > router without M-Tunnel and can get the streams natively. => The issue is not the use of PIM-SM based direct routing. In my sense, the issue was raised because you has been calling the entity, establishing "M-Tunnel" with an MAG, an LMA. As I told you before, the entity cannot be an LMA but may be closely to a sort of multicast replicator server deliverying multicast packets to attached MAGs. There is no issue as you said. MAG enabling PIM-SM communicates with neighbor PIM-SM routers. The neighbor PIM-SM router may be the LMA enabling PIM-SM, may be an adjacent PIM-SM router, etc. No difference from the ordinal PIM-SM routing behavior. M-Tunnel is used to configure an upstream (neighbor) router when a multicast route for some group/source prefixes should be distinguished from the corresponding route in RIB. This is also same as of the regular situation (while dedicate M-Tunnel is a new definition of specific GRE tunnel). Regards, -- Hitoshi Asaeda From zzhang@juniper.net Mon Dec 12 06:39:46 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 EC19121F8AFD for ; Mon, 12 Dec 2011 06:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jXhwqUjO8L0c for ; Mon, 12 Dec 2011 06:39:44 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8EE21F8610 for ; Mon, 12 Dec 2011 06:39:44 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTuYSLz1h55+FPY6H3uLyczFNYjd5mmZj@postini.com; Mon, 12 Dec 2011 06:39:44 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Dec 2011 06:38:19 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 12 Dec 2011 09:38:18 -0500 From: "Jeffrey (Zhaohui) Zhang" To: "multimob@ietf.org" Date: Mon, 12 Dec 2011 09:38:17 -0500 Thread-Topic: Mailing list question Thread-Index: Acy4269dG2yXn4gyR6O32Pgc4/PurQ== Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E19EDCE@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [multimob] Mailing list question 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, 12 Dec 2011 14:39:47 -0000 Hi, I have always been getting multiple "multimob Digest, Vol XX, Issue YY" ema= il in a day with only ONE email in attached in each message. I double checked that the digest mode is set to on (which is desired, but I= have not got the desired effect): ------ If you turn digest mode on, you'll get posts bundled together (usually one = per day but possibly more on busy lists), instead of singly when they're se= nt. If digest mode is changed from on to off, you may receive one last dige= st. ----- I have not problem with OSPF/MPLS/L3VPN lists. Thought I'd ask the list to see if anyone else is seeing the problem or kno= ws the solution. Thanks. Jeffrey= From stig@venaas.com Mon Dec 12 12:24:38 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 A3B7721F84D5 for ; Mon, 12 Dec 2011 12:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 hn00qearm2dE for ; Mon, 12 Dec 2011 12:24:38 -0800 (PST) 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 1186321F84DA for ; Mon, 12 Dec 2011 12:24:38 -0800 (PST) Received: from [10.33.12.86] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 5E64A8012; Mon, 12 Dec 2011 21:24:34 +0100 (CET) Message-ID: <4EE662FA.2070608@venaas.com> Date: Mon, 12 Dec 2011 12:24:26 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@informatik.haw-hamburg.de> <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> In-Reply-To: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 12 Dec 2011 20:24:38 -0000 Regarding PMIP routing and PIM and MRIB etc. It seems to me that there is pretty much agreement on how this works. I still would like to say how I believe it works and what could be done. For PIM (and most multicast routing in general) RPF is essential and that is achieved using a routing table (MRIB). This MRIB is in many cases identical to the unicast RIB, but it need not be. Now since PMIP uses policy routing (you cannot tell where a packet should be forwarded just by its destination address), you cannot align PIM with PMIP using a single RIB. However, there are implementations that support multiple RIBs. That is multiple VRFs, see e.g. RFC 4364 section 3. In that case, each interface on a router would belong to a VRF (a default VRF if nothing in particular is configured), or some specific other VRF. I won't say for sure, but I think it should be possible to match PMIP routing and PIM on the MAG by having one VRF per LMA, where the MAG-LMA tunnel and each MAG-MN links (for the MNs belonging to that LMA). You might compare this to our base approach with multiple proxy instances. I think the per LMA VRF table would basically have a default route pointing to the MAG-LMA tunnel, and then a directly connected route per MAG-MN link. Does that look correct? Anyone see any issues with that? Stig From prvs=32197fba8=schmidt@informatik.haw-hamburg.de Mon Dec 12 17:38:10 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 6D0661F0C3F for ; Mon, 12 Dec 2011 17:38:10 -0800 (PST) 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 k5zGm3pun6X6 for ; Mon, 12 Dec 2011 17:38:09 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB701F0C35 for ; Mon, 12 Dec 2011 17:38:08 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 13 Dec 2011 02:38:07 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 67263102C0FA; Tue, 13 Dec 2011 02:38:07 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31860-07; Tue, 13 Dec 2011 02:38:06 +0100 (CET) Received: from [192.168.2.96] (dslc-082-083-155-084.pools.arcor-ip.net [82.83.155.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id A18EA102C0DD; Tue, 13 Dec 2011 02:38:06 +0100 (CET) Message-ID: <4EE6AC8E.5060603@informatik.haw-hamburg.de> Date: Tue, 13 Dec 2011 02:38:22 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Stig Venaas References: <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@informatik.haw-hamburg.de> <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> <4EE662FA.2070608@venaas.com> In-Reply-To: <4EE662FA.2070608@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 13 Dec 2011 01:38:10 -0000 Hi Stig, On 12.12.2011 21:24, Stig Venaas wrote: > For PIM (and most multicast routing in general) RPF is essential and > that is achieved using a routing table (MRIB). This MRIB is in many > cases identical to the unicast RIB, but it need not be. > > Now since PMIP uses policy routing (you cannot tell where a packet > should be forwarded just by its destination address), you cannot align > PIM with PMIP using a single RIB. > Bonne - well said. > However, there are implementations that support multiple RIBs. That > is multiple VRFs, see e.g. RFC 4364 section 3. In that case, each > interface on a router would belong to a VRF (a default VRF if > nothing in particular is configured), or some specific other VRF. > Oho ... this is really strong stuff. Let me try to rephrase to make sure I get you right: 1. You are considering plain unicast routing here. 2. You use the property of PtP-Links in PMIP: Because there is only a single IP address behind a downstream interface of a MAG, you regard this interface as a proxy of the MN / MN's IP address. 3. Considering a MAG as a Provider Edge (PE) router with downstream links as "Pseudo-VPN" endpoints, you adopt the option of RFC 4364 to assign a VPN Routing and Forwarding tables to each downstream, thereby turning the common filter(policy)-based routing into an interface-based VRF ... which indeed brings us back into the context of ordinary routing tables. 4. As a result, you have a unicast router with per-interface RIBs. Then the forwarding at a MAG looks as follows: For data sent from an MN, the VRF at its connecting interface is used which essentially has a default route to the corresponding MAG-LMA tunnel. For data sent to an MN, no special routing tables are actually required, as a default table actually should know all the downstream routes to the MNs. However, you could add a dedicated VRF at the LMA-MAG tunnel that only contains those downstream routes for MNs belonging to the LMA. This is redundant, but should not do harm. All together you end up with a VRF that corresponds to something like a proxy instance in the base solution ... This is unicast - but for multicast, the bigger question would be: Can PIM-SM work with a collection of interface-bound RIBs? This would mean that (*,G)/(S,G) tree states could overlap at a single router (that has to maintain multiple trees for the same group but different interfaces ...) How could this be handled by PIM?? I would at least deduce, that PIM would loose its tree optimization properties and duplicate data would arrive ... just as in the base solution - do you agree or am I ignoring something? Cheers, Thomas > I won't say for sure, but I think it should be possible to match > PMIP routing and PIM on the MAG by having one VRF per LMA, where > the MAG-LMA tunnel and each MAG-MN links (for the MNs belonging > to that LMA). You might compare this to our base approach with > multiple proxy instances. I think the per LMA VRF table would > basically have a default route pointing to the MAG-LMA tunnel, > and then a directly connected route per MAG-MN link. > > Does that look correct? Anyone see any issues with that? > > Stig > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- 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 stig@venaas.com Tue Dec 13 09:43:18 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 1086721F8AFF for ; Tue, 13 Dec 2011 09:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 gJdGumpF1iFy for ; Tue, 13 Dec 2011 09:43:17 -0800 (PST) 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 DA44821F8AF1 for ; Tue, 13 Dec 2011 09:43:16 -0800 (PST) Received: from [10.33.12.86] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 2ABD17FE9; Tue, 13 Dec 2011 18:43:13 +0100 (CET) Message-ID: <4EE78EAB.8020805@venaas.com> Date: Tue, 13 Dec 2011 09:43:07 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <20111209.184234.67901321.asaeda@sfc.wide.ad.jp> <4EE24F17.9050809@informatik.haw-hamburg.de> <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> <4EE662FA.2070608@venaas.com> <4EE6AC8E.5060603@informatik.haw-hamburg.de> In-Reply-To: <4EE6AC8E.5060603@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 13 Dec 2011 17:43:18 -0000 Please see inline On 12/12/2011 5:38 PM, Thomas C. Schmidt wrote: > Hi Stig, > > On 12.12.2011 21:24, Stig Venaas wrote: > >> For PIM (and most multicast routing in general) RPF is essential and >> that is achieved using a routing table (MRIB). This MRIB is in many >> cases identical to the unicast RIB, but it need not be. >> >> Now since PMIP uses policy routing (you cannot tell where a packet >> should be forwarded just by its destination address), you cannot align >> PIM with PMIP using a single RIB. >> > > Bonne - well said. > >> However, there are implementations that support multiple RIBs. That >> is multiple VRFs, see e.g. RFC 4364 section 3. In that case, each >> interface on a router would belong to a VRF (a default VRF if >> nothing in particular is configured), or some specific other VRF. >> > > Oho ... this is really strong stuff. Let me try to rephrase to make sure > I get you right: > > 1. You are considering plain unicast routing here. Basically this applies to VPNs, both unicast and multicast. > 2. You use the property of PtP-Links in PMIP: Because there is only a > single IP address behind a downstream interface of a MAG, you regard > this interface as a proxy of the MN / MN's IP address. > > 3. Considering a MAG as a Provider Edge (PE) router with downstream > links as "Pseudo-VPN" endpoints, you adopt the option of RFC 4364 to > assign a VPN Routing and Forwarding tables to each downstream, thereby > turning the common filter(policy)-based routing into an interface-based > VRF ... which indeed brings us back into the context of ordinary routing > tables. Talking about VPNs in general, each interface belongs to a VRF. And I believe each MN link also would belong to a VRF when making use of this. > 4. As a result, you have a unicast router with per-interface RIBs. > Then the forwarding at a MAG looks as follows: > > For data sent from an MN, the VRF at its connecting interface is used > which essentially has a default route to the corresponding MAG-LMA tunnel. > > For data sent to an MN, no special routing tables are actually required, > as a default table actually should know all the downstream routes to the > MNs. However, you could add a dedicated VRF at the LMA-MAG tunnel that > only contains those downstream routes for MNs belonging to the LMA. This > is redundant, but should not do harm. > > All together you end up with a VRF that corresponds to something like a > proxy instance in the base solution ... > > > This is unicast - but for multicast, the bigger question would be: Can > PIM-SM work with a collection of interface-bound RIBs? This would mean > that (*,G)/(S,G) tree states could overlap at a single router (that has > to maintain multiple trees for the same group but different interfaces > ...) How could this be handled by PIM?? The PIM state is also per VRF. So if you get (S,G)-joins on two different interfaces, belonging to two different VRFs, you will have two (S,G) entries, even if the S and G addresses are the same. Also the RPF interfaces for the two (S,G)s will be different. > I would at least deduce, that PIM would loose its tree optimization > properties and duplicate data would arrive ... just as in the base > solution - do you agree or am I ignoring something? Yes, it becomes exactly like the base solution. You just cannot have it two ways though. I mean, either you want multicast to be according to the PMIP routing, or you choose multicast to be something else. If you want for a given (S,G) to have a single tree (independent of which MNs join), then I think a single MRIB would be fine. Stig > > Cheers, > > Thomas > > >> I won't say for sure, but I think it should be possible to match >> PMIP routing and PIM on the MAG by having one VRF per LMA, where >> the MAG-LMA tunnel and each MAG-MN links (for the MNs belonging >> to that LMA). You might compare this to our base approach with >> multiple proxy instances. I think the per LMA VRF table would >> basically have a default route pointing to the MAG-LMA tunnel, >> and then a directly connected route per MAG-MN link. >> >> Does that look correct? Anyone see any issues with that? >> >> Stig >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > From multimob2011@gmail.com Tue Dec 13 19:31: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 55D5B11E8095 for ; Tue, 13 Dec 2011 19:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_91=0.6, NORMAL_HTTP_TO_IP=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 0kct6F1Wcnct for ; Tue, 13 Dec 2011 19:31:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62D7411E8093 for ; Tue, 13 Dec 2011 19:31:19 -0800 (PST) Received: by iaek3 with SMTP id k3so626694iae.31 for ; Tue, 13 Dec 2011 19:31:19 -0800 (PST) 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 :content-type; bh=Orx8RGlG7ku3z+LJ/AFW0nSYysP3p40maHzpQm30tBc=; b=LBYqfaC8BUgUqb+lT7Gk/nEmj1pv0Qkv/JcYyLhFSlaJG46PKS+6BBRnoIMwEWN+Vg PhjnLse545YeQ6gnf9VNufnx/SnIMF5PcBcP4d4rrRq8bSiEAAFacn8E+Hwhsu7rVFUa ybdG4x1l/EV70EvBH3NZ9DC4pO5hWKUL4s5cA= MIME-Version: 1.0 Received: by 10.50.236.40 with SMTP id ur8mr11947589igc.91.1323833478943; Tue, 13 Dec 2011 19:31:18 -0800 (PST) Received: by 10.50.220.197 with HTTP; Tue, 13 Dec 2011 19:31:18 -0800 (PST) In-Reply-To: <4EE7A905.9000201@venaas.com> References: <4EE7A905.9000201@venaas.com> Date: Wed, 14 Dec 2011 11:31:18 +0800 Message-ID: From: Aaron Feng To: Stig Venaas , multimob@ietf.org Content-Type: multipart/alternative; boundary=14dae93408fd4114b004b405008c Subject: [multimob] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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, 14 Dec 2011 03:31:20 -0000 --14dae93408fd4114b004b405008c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, At first, thank you for your reply! :) There are still some questions confusing me. I'm not sure about whether the mechanism of the protocol or the implemention leads to such result? a) If it's the protocol PMIP and PIM-SM, which shoud be modified or add some new rules to deal with such scenario? Do we need to treat the scenario of source-mobility specially? b) If it's the implemention If we create PMIP policy-routing info into RIB, I think, it seems not to work. For the MAG, could the MAG acting as DR for MN(MN acts as the source) use a soure-routing info in RIB to execute the check of direct connection? Besides, though the MAG has routing info about MNs and knows where the packets of MNs to foward, these routing info about MNs do NOT distribute to other routers (except LMA). If we create the MN routing info into RIB entries, is it diffused? If it's diffused, it will be a contradiction to PMIP protocol. c) If we modify the PIM about the check of direct connection, that will lead to the change of protocol of the PIM, which seems not to be allowed in MULTIMOB WG. Regards, Aaron ---------- Forwarded message ---------- From: Stig Venaas Date: 2011/12/14 Subject: Re: Questions for point-to-point link and the check of directly connection of the mcast source? To: Aaron Feng Hi Aaron This might be good to discuss on the multimob list, but I'll try to answer here. On 12/10/2011 5:17 AM, Aaron Feng wrote: > Hi! > According to the RFC 5213, the MAG emulates the mobile node=92s home > network on the access link by sending RA with MN's HNP ,so that the MN > could consider itself at its home network. > It's a point-to-point link between the MAG and MN. > However, for the MAG, there's not any physical interfaces assigned with > MN's HNP. If the MAG acts as the DR for the MN(MN acts as a mcast > source), according to the RFC4601, > the MAG needs to check whether the MN is directly connected. In my real > experiment, the MAG failed to foward the macst data form the MN that > acts as a mcast source. > Therefore,I'm not sure about > 1) how the DR checks whether it's directly connected with the source? By > checking routing tables or just matching the network prefix of the > physical interface(that receives the mcast data) with the source address > or something else? > This depends a lot on the implementation. On Cisco IOS and I think also Linux and BSD etc. you normally in your routing table (RIB) create routes for each of the interfaces (whether virtual or physical), so that if an interface is configured with say IP address and mask 10.1.2.1/30, then a route for 10.1.2.0/30 is added and with some flag saying it is a connected route. This can then be used by PIM to discover that a source (in this case 10.1.2.2) is directly connected. For PMIP it might be that the implementation does not add any such routes to the RIB. This all depends on the implementation. In that case PIM would probably not be able to find that they are directly connected. Since the PMIP routing is somewhat unusual, it could be that the implementation is done without creating any RIB entries, and IP addresses for the p-t-p links. If this is the case, then for PIM to work you may need to either add these entries to the RIB (or better to the MRIB if PIM can use a separate RIB), or you may need to modify PIM so it can in some other way know that these addresses are directly connected. Please also see what I posted related to this on the multimob list yesterday and today. Happy to continue this discussion on the list as it is very much related to the current wg discussions. Stig 2) how to grasp the concept of the point-to-point link? Does it need two > nodes with the same network prefix? > Looking foward to hearing from you back soon! > Regards, > Aaron > --14dae93408fd4114b004b405008c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,
At first, thank you=A0for your reply!=A0 :)
There are=A0still some questions confusing me.=A0I'm not sure abou= t
whether the mechanism of the protocol or the implemention leads to suc= h=A0result?
a) If it's the=A0protocol=A0
PMIP and PIM-SM, which shoud be modified or add some new rules to deal= with such scenario?=A0Do we=A0need to treat=A0the scenario of=A0source-mob= ility specially?
b) If it's the implemention
If we create=A0PMIP policy-routing info into RIB,=A0I think, it seems = not to=A0work. For the MAG, could the MAG acting as DR for MN(MN acts as th= e source)=A0use a soure-routing info in RIB to=A0execute the check of direc= t connection?
Besides, though the MAG has=A0routing info=A0about MNs and knows where= the packets of MNs to foward, these routing info about=A0MNs=A0do NOT=A0di= stribute to other routers (except LMA). If we create the MN routing info in= to RIB entries,=A0is=A0it=A0diffused? If it's diffused, it will be a co= ntradiction to PMIP protocol.
c) If we modify the PIM about the check of direct connection,=A0 that = will lead to the change of protocol of the PIM, which seems not to be allow= ed in MULTIMOB WG.=A0=A0=A0=A0=A0
=A0
=A0
Regards,
Aaron


=A0
---------- Forwarded message ----------
From:= Stig Venaas <stig@venaas.com>
Date: 2011/1= 2/14
Subject: Re: Questions for point-to-point link and the check of directly co= nnection of the mcast source?
To: Aaron Feng <multimob2011@gmail.com>


Hi Aaron

This might be good to discuss on the multimob list, but I'll try to=
answer here.=20


On 12/10/2011 5:17 AM, Aaron Feng wrote:
Hi!
According to the RFC 5213, the= MAG emulates the mobile node=92s home
network on the access link by sen= ding RA with MN's HNP ,so that the MN
could consider itself at its home network.
It's a point-to-point lin= k between the MAG and MN.
However, for the MAG, there's not any phys= ical interfaces assigned with
MN's HNP. If the MAG acts as the DR fo= r the MN(MN acts as a mcast
source), according to the RFC4601,
the MAG needs to check whether the MN= is directly connected. In my real
experiment, the MAG failed to foward = the macst data form the MN that
acts as a mcast source.
Therefore,I&#= 39;m not sure about
1) how the DR checks whether it's directly connected with the source? B= y
checking routing tables or just matching the network prefix of the
= physical interface(that receives the mcast data) with the source address or something else?

This depends a lot on the impl= ementation. On Cisco IOS and I think also
Linux and BSD etc. you normall= y in your routing table (RIB) create
routes for each of the interfaces (= whether virtual or physical), so that
if an interface is configured with say IP address and mask 10.1.2.1/30,
then a route for 10.1.2.0/30 is added and wi= th some flag saying it is a
connected route. This can then be used by PIM to discover that a source
= (in this case 10.1.2.2) is directly connected.

For PMIP it might be = that the implementation does not add any such
routes to the RIB. This al= l depends on the implementation. In that case
PIM would probably not be able to find that they are directly connected.
Since the PMIP routing is somewhat unusual, it could be that the
im= plementation is done without creating any RIB entries, and IP
addresses = for the p-t-p links. If this is the case, then for PIM
to work you may need to either add these entries to the RIB (or
better t= o the MRIB if PIM can use a separate RIB), or you may need
to modify PIM= so it can in some other way know that these addresses
are directly conn= ected.

Please also see what I posted related to this on the multimob list
y= esterday and today. Happy to continue this discussion on the list
as it = is very much related to the current wg discussions.

Stig=20


2) how to grasp the concept of the po= int-to-point link? Does it need two
nodes with the same network prefix?<= br> Looking foward to hearing from=A0you back soon!
Regards,
Aaron


--14dae93408fd4114b004b405008c-- From asaeda@sfc.wide.ad.jp Tue Dec 13 21:52:36 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 DEDD511E80BC for ; Tue, 13 Dec 2011 21:52:36 -0800 (PST) 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 TSxn-3UTxRIn for ; Tue, 13 Dec 2011 21:52:36 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0D611E80BA for ; Tue, 13 Dec 2011 21:52:36 -0800 (PST) Received: from localhost (dhcp-143-200.sfc.wide.ad.jp [203.178.143.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C4907278072; Wed, 14 Dec 2011 14:52:30 +0900 (JST) Date: Wed, 14 Dec 2011 14:52:30 +0900 (JST) Message-Id: <20111214.145230.267424073.asaeda@sfc.wide.ad.jp> To: stig@venaas.com From: Hitoshi Asaeda In-Reply-To: <4EE662FA.2070608@venaas.com> References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> <4EE662FA.2070608@venaas.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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 14 Dec 2011 05:52:37 -0000 Hi Stig, > Regarding PMIP routing and PIM and MRIB etc. It seems to me that there > is pretty much agreement on how this works. I still would like to say > how I believe it works and what could be done. Right. > For PIM (and most multicast routing in general) RPF is essential and > that is achieved using a routing table (MRIB). This MRIB is in many > cases identical to the unicast RIB, but it need not be. Exactly. > Now since PMIP uses policy routing (you cannot tell where a packet > should be forwarded just by its destination address), you cannot align > PIM with PMIP using a single RIB. It seems that people have been confused. As I said many times, it is *not necessary* to incorporate PMIP's unicast policy route into MAG's RIB, in my proposal. > However, there are implementations that support multiple RIBs. That > is multiple VRFs, see e.g. RFC 4364 section 3. In that case, each > interface on a router would belong to a VRF (a default VRF if > nothing in particular is configured), or some specific other VRF. > > I won't say for sure, but I think it should be possible to match > PMIP routing and PIM on the MAG by having one VRF per LMA, where > the MAG-LMA tunnel and each MAG-MN links (for the MNs belonging > to that LMA). You might compare this to our base approach with > multiple proxy instances. I think the per LMA VRF table would > basically have a default route pointing to the MAG-LMA tunnel, > and then a directly connected route per MAG-MN link. > > Does that look correct? Anyone see any issues with that? I think your proposal is also interesting in some condition. But multiple RIBs are not always required. I don't start discussing what kind of situation multiple RIBs are needed with PIM, because it gives another confusion. But if we do RPF solely based on the source address (or RP address) rather than which MN it is, then a single RIB (and a sigle MRIB) should work. PIM on MAG only needs to resolve upstream interfaces when it receives MLD join from MNs. In other words, PMIP unicast policy route is not needed for RPF check. MAG has its RIB. This RIB does not have any entry for MNs' prefixes. It's Ok. It doesn't affect anything for forwarding multicast packets received at MAG, because MNs are directly attached to MAG with P2P link and they can send MLD joins to the MAG directly. And MAG recognizes the receivers (and OIFs) and forwards packets to the MAG's OIFs. Again, if PIM on MAG can resolve RPF, it can just send PIM join toward source or RP and forward packets to directly attached MNs who have requested join. Do you agree, Stig? Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Wed Dec 14 00:11: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 EBEB621F8551 for ; Wed, 14 Dec 2011 00:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.796 X-Spam-Level: X-Spam-Status: No, score=-98.796 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6, 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 IAxCtNg701Vs for ; Wed, 14 Dec 2011 00:11:09 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0399021F854E for ; Wed, 14 Dec 2011 00:11:09 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1B9E127807D; Wed, 14 Dec 2011 17:11:04 +0900 (JST) Date: Wed, 14 Dec 2011 17:11:03 +0900 (JST) Message-Id: <20111214.171103.81892872.asaeda@sfc.wide.ad.jp> To: multimob2011@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <4EE7A905.9000201@venaas.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] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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, 14 Dec 2011 08:11:10 -0000 Hi Aaron, In the recent discussions in the ML, I've not talked about source mobility for PIM on MAG. Now let's move on discussion about source mobility in the situation of PIM-SM on MAG. The followings are my comments for it. > There are still some questions confusing me. I'm not sure about > whether the mechanism of the protocol or the implemention leads to > such result? > a) If it's the protocol > PMIP and PIM-SM, which shoud be modified or add some new rules to deal with > such scenario? Do we need to treat the scenario of source-mobility > specially? In a nutshell, source mobility for PIM on both MAG and LMA can work if receiver mobility for PIM works. There is only one issue, aka "detour", if we take into account routing optimization. When MAG realizes that the source is directly connected, the MAG can simply recognize the IIF for the source packets and do PIM register, etc. If some MNs subscribe a channel sent from an MN connecting the same MAG, the multicast packets are forwarded to RP or MNs directly. On the other hand, if other MNs connecting to different MAG subscribe the channel sent from the MN, the packets are forwarded through LMA. If we don't care for detour through LMA, no extra function is needed. (Well, this implies that effective routing (i.e. routing optimization) on PIM on MAG/LMA would be needed to consider if we propose source mobility for PIM on MAG/LMA.) BTW, this "detour" is more headache for MAG having multiple MLD proxies (i.e. base solution). When multiple MLD proxy instances may be co-located in a single MAG, one MLD proxy attaching downstream source needs to inject his multicast packets to other MLD proxy instances having the corresponding receivers if we want to avoid detour. Of course, this behavior has not considered with the standard MLD proxy definition (rfc4605). Please also see my mail sent on Dec 9 (for adoption call for the source mobility draft). > b) If it's the implemention > If we create PMIP policy-routing info into RIB, I think, it seems not > to work. For the MAG, could the MAG acting as DR for MN(MN acts as the > source) use a soure-routing info in RIB to execute the check of direct > connection? No, MAG is always DR and last hop router for MNs. > Besides, though the MAG has routing info about MNs and knows where the > packets of MNs to foward, these routing info about MNs do NOT distribute to > other routers (except LMA). If we create the MN routing info into RIB > entries, is it diffused? If it's diffused, it will be a contradiction to > PMIP protocol. MAG never advertises MNs' prefixes. > c) If we modify the PIM about the check of direct connection, that will > lead to the change of protocol of the PIM, which seems not to be allowed in > MULTIMOB WG. Well, I don't want to discuss about possibility of PIM-SM protocol modification for source mobility *optimization*, because it may need more study. But in general (e.g. with my current proposal), PIM modification is not required. Anyway, as you see, this is the reason that it is impossible to judge the adoption of draft-schmidt-multimob-pmipv6-source-00.txt at this moment. And I do recommend to concentrate only for source mobility for base solution for this draft and explicitly say so in the revised version. IMO, it is only the way to be adopted. Regards, -- Hitoshi Asaeda From Dirk.von-Hugo@telekom.de Thu Dec 15 05:37:52 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 D91FD21F85A8 for ; Thu, 15 Dec 2011 05:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJvohxGV4Gid for ; Thu, 15 Dec 2011 05:37:52 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id F0F1821F84D8 for ; Thu, 15 Dec 2011 05:37:51 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 15 Dec 2011 14:36:58 +0100 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.112]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 15 Dec 2011 14:36:57 +0100 From: To: , Date: Thu, 15 Dec 2011 14:32:31 +0100 Thread-Topic: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Thread-Index: Acy167bunjn292cLQfuqiYnwsmHvIwFOYv+Q Message-ID: <05C81A773E48DD49B181B04BA21A342A26809A8372@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sijeon@dcn.ssu.ac.kr, yhkim@dcn.ssu.ac.kr Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 15 Dec 2011 13:37:53 -0000 Dear all, AFAIU the draft does provide a base solution to tunnel convergence problem = in multimob and I agree to forward the merged document as WG document. Some comments for discussion (though not sure whether already posed on the = list): It surely should be obvious that different MNs at same MAG may be connected= to different LMAs or MTMAs but since it cannot be shown in Figs. 2 and 3 p= erhaps it should be mentioned explicitly - due to mobility it will happen a= nyway and later on in Fig. 4 it is included. Introduction of hybrid H-LMA is only applied to N:1 scenario. Do you exclud= e the 1:N case because here the scenario with several H-LMAs doesn't differ= much from the base protocol with combined unicast/multicast LMAs (and thus= does not solve the tunnel convergence problem)? Perhaps this could be elab= orated a bit. In sect. 3 in Figs. 5/6 PBU/PBA exchange is the first reaction of MAG on MN= attachment which seems to be reasonable, whereas in section 4 the flow cha= rt Fig. 10 proposes to do PBU/PBA after MLD query. Shouldn't this be change= d since otherways also the dynamic decision of MAG on local or remote routi= ng based on 'PBU/PBA signaling (which) can be used to carry the profile inf= ormation ...' as mentioned in 5.1 cannot be applied? Furthermore I am not sure whether in 4.2.2 for MAG as MR the expression 'as= described in chapter 3' would fit since ch.3 describes the PMIP-based MAG-= MTMA operation and does not cover multicast routing (but perhaps that touch= es the routing table discussion I did not understand completely). Finally I wonder whether due to possible dynamic configuration of MAG as MR= according to PIM not additional security concerns are introduced so that i= n ch. 6. also PIM RFCs should be included? Thanks and best regards Dirk -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftra= g von Behcet Sarikaya Gesendet: Donnerstag, 8. Dezember 2011 21:53 An: multimob@ietf.org Betreff: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Hello all, There was consensus on the tunnel convergence solution draft in Taipei. This mail is to confirm the consensus. This document can be found at: http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt This mail starts a WG adoption call on this draft. The intended status for this document is proposed standard. If adopted, the draft will be named: draft-ietf-multimob-pmipv6-tunnel-convergence. Please your comments by December 15, 2011. Chairs _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob2011@gmail.com Thu Dec 15 17:41: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 842CA1F0C5F for ; Thu, 15 Dec 2011 17:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 hhC-KXdq+nEb for ; Thu, 15 Dec 2011 17:41:57 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1C8F1F0C5D for ; Thu, 15 Dec 2011 17:41:56 -0800 (PST) Received: by iaek3 with SMTP id k3so4324360iae.31 for ; Thu, 15 Dec 2011 17:41:53 -0800 (PST) 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=3KH1iF3lXgrsjQDbjA/HcXipNJj2aurqZV4B4gDZHEU=; b=LkFs3LTzzkph5xU9d0VceNfyUFJNgWXr1UyJtE6M8Ivv4ihCMUVWZxneyTu8AiyAI2 S3C2GKIIw9YRcEJWnbMd+6UPURxPV5y5YyPAb67yoyw9qB/sEhfqtUikGztsEz8qUr8H My2gNXvylGhxZCCYupbvRCW6Yt1Fq4ZAZfNOc= MIME-Version: 1.0 Received: by 10.50.203.100 with SMTP id kp4mr5524134igc.7.1323999713769; Thu, 15 Dec 2011 17:41:53 -0800 (PST) Received: by 10.50.220.197 with HTTP; Thu, 15 Dec 2011 17:41:53 -0800 (PST) In-Reply-To: <20111214.171103.81892872.asaeda@sfc.wide.ad.jp> References: <4EE7A905.9000201@venaas.com> <20111214.171103.81892872.asaeda@sfc.wide.ad.jp> Date: Fri, 16 Dec 2011 09:41:53 +0800 Message-ID: From: Aaron Feng To: Hitoshi Asaeda Content-Type: multipart/alternative; boundary=14dae93407659f3a7b04b42bb44b Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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: Fri, 16 Dec 2011 01:41:57 -0000 --14dae93407659f3a7b04b42bb44b Content-Type: text/plain; charset=ISO-8859-1 Hi, > In a nutshell, source mobility for PIM on both MAG and LMA can work if > receiver mobility for PIM works. There is only one issue, aka > "detour", if we take into account routing optimization. > > When MAG realizes that the source is directly connected, the MAG can > simply recognize the IIF for the source packets and do PIM register, > etc. If some MNs subscribe a channel sent from an MN connecting the > same MAG, the multicast packets are forwarded to RP or MNs directly. > On the other hand, if other MNs connecting to different MAG subscribe > the channel sent from the MN, the packets are forwarded through LMA. > I think, there's some difference between source mobility and receiver mobility. For the receiver, when the MN subscribes a channel, it sends a MLD report message with its link address. It's not a very strong limitation because all the link address prefix is fe80::/64. However, for the source, the MN uses its global address to send mcast data. Since the MAG has not any physical interfaces assigned with MN's HNP, the check of direct connection might fail if the MAG acts as the DR. Regards, Aaron --14dae93407659f3a7b04b42bb44b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
In a nutshell, source mobility for PI= M on both MAG and LMA can work if
receiver mobility for PIM works. There= is only one issue, aka
"detour", if we take into account routing optimization.

Wh= en MAG realizes that the source is directly connected, the MAG can
simpl= y recognize the IIF for the source packets and do PIM register,
etc. If = some MNs subscribe a channel sent from an MN connecting the
same MAG, the multicast packets are forwarded to RP or MNs directly.
On = the other hand, if other MNs connecting to different MAG subscribe
the c= hannel sent from the MN, the packets are forwarded through LMA.
=A0 I think, there's=A0some difference between source mobility and= receiver mobility. For the receiver, when the MN subscribes a channel, it = sends a MLD report message with=A0its link address. It's not a very str= ong limitation because all the link address prefix is fe80::/64. However, f= or the source, the MN uses its global address to send mcast data.=A0Since t= he MAG has not any physical interfaces=A0assigned with MN's HNP,=A0the = check of direct connection=A0might fail if the MAG acts as the DR.
=A0=A0=A0=A0
Regards,
Aaron

--14dae93407659f3a7b04b42bb44b-- From asaeda@sfc.wide.ad.jp Thu Dec 15 20:10:35 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 1C65011E80C3 for ; Thu, 15 Dec 2011 20:10:35 -0800 (PST) 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 6ko6xwQjf0DW for ; Thu, 15 Dec 2011 20:10:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0FE11E80C2 for ; Thu, 15 Dec 2011 20:10:34 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D92CE278099; Fri, 16 Dec 2011 13:10:06 +0900 (JST) Date: Fri, 16 Dec 2011 13:10:06 +0900 (JST) Message-Id: <20111216.131006.111370807.asaeda@sfc.wide.ad.jp> To: multimob2011@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <20111214.171103.81892872.asaeda@sfc.wide.ad.jp> 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] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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: Fri, 16 Dec 2011 04:10:35 -0000 Hi, > because all the link address prefix is fe80::/64. However, for the source, > the MN uses its global address to send mcast data. Since the MAG has not > any physical interfaces assigned with MN's HNP, the check of direct > connection might fail if the MAG acts as the DR. I cannot understand your point. What does "the check of direct connection might fail if the MAG acts as the DR" mean? Why the problem happens only when MAG acts router? Why the problem happens only for multicast packets? Regards, -- Hitoshi Asaeda From multimob2011@gmail.com Thu Dec 15 23:23:26 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 67CDE21F8435 for ; Thu, 15 Dec 2011 23:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 X8z3WJc1i6X3 for ; Thu, 15 Dec 2011 23:23:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E651C21F86C3 for ; Thu, 15 Dec 2011 23:23:25 -0800 (PST) Received: by iaek3 with SMTP id k3so4779636iae.31 for ; Thu, 15 Dec 2011 23:23:25 -0800 (PST) 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=qM6r0J3EWvNoI6d5nzIwxvJNfBVgUDIKQjmQSd2DB10=; b=u3VzLqOdWraS8YuekshGPj/A23X/ERXDvIZGWqTTvQwtRobZnWEySl0FZrVoNTluUl 2uiFuoO49JM+SWOmPe645aNCclyCv7g7WtKGZnQP44WR1VvyozoSrI3JUAtBE84I95Tz 07P/0XNZp160/Nbkncl7rZCIl8ysDALVuWLV0= MIME-Version: 1.0 Received: by 10.50.178.68 with SMTP id cw4mr7055103igc.31.1324020205509; Thu, 15 Dec 2011 23:23:25 -0800 (PST) Received: by 10.50.220.197 with HTTP; Thu, 15 Dec 2011 23:23:25 -0800 (PST) In-Reply-To: <20111216.131006.111370807.asaeda@sfc.wide.ad.jp> References: <20111214.171103.81892872.asaeda@sfc.wide.ad.jp> <20111216.131006.111370807.asaeda@sfc.wide.ad.jp> Date: Fri, 16 Dec 2011 15:23:25 +0800 Message-ID: From: Aaron Feng To: Hitoshi Asaeda Content-Type: multipart/alternative; boundary=e89a8f503824065d1004b4307ae9 Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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: Fri, 16 Dec 2011 07:23:26 -0000 --e89a8f503824065d1004b4307ae9 Content-Type: text/plain; charset=ISO-8859-1 Hi, MLD report is the signaling message with only ONE hop, so it uses the link address. It's not a very strong limitation because all the link address prefix is fe80::/64. But for the mcast source, it sends the data with the global address. MAG acting as MN's DR should first checks whether the MN is in its subnet or say directly connected using MN's global address. Since the MAG has not any physical interfaces assigned with MN's HNP, the check of direct connection might fail. Regards, Aaron --e89a8f503824065d1004b4307ae9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
MLD report is the signaling message with only=A0ONE hop, so it uses th= e link address. It's not a very strong limitation because all the link = address prefix is fe80::/64.
But for the mcast source, it sends the data with the global address.
MAG acting as MN's DR should=A0first=A0checks whether the MN is in= its subnet or=A0say directly connected using MN's global address.=A0 S= ince the MAG has not any physical interfaces assigned with MN's HNP, th= e check of direct connection might fail.=A0
=A0
Regards,
Aaron=A0=A0=A0=A0=A0
--e89a8f503824065d1004b4307ae9-- From asaeda@sfc.wide.ad.jp Thu Dec 15 23:58:02 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 1EF2211E8093 for ; Thu, 15 Dec 2011 23:58:02 -0800 (PST) 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 v9-CcQPR9SjS for ; Thu, 15 Dec 2011 23:58:01 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF9B21F8549 for ; Thu, 15 Dec 2011 23:58:01 -0800 (PST) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D599F2780A3; Fri, 16 Dec 2011 16:57:56 +0900 (JST) Date: Fri, 16 Dec 2011 16:57:56 +0900 (JST) Message-Id: <20111216.165756.75577605.asaeda@sfc.wide.ad.jp> To: multimob2011@gmail.com From: Hitoshi Asaeda In-Reply-To: References: <20111216.131006.111370807.asaeda@sfc.wide.ad.jp> 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] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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: Fri, 16 Dec 2011 07:58:02 -0000 > MLD report is the signaling message with only ONE hop, so it uses the link > address. It's not a very strong limitation because all the link address > prefix is fe80::/64. Sure. > But for the mcast source, it sends the data with the global address. > MAG acting as MN's DR should first checks whether the MN is in its subnet > or say directly connected using MN's global address. Since the MAG has not > any physical interfaces assigned with MN's HNP, the check of direct > connection might fail. MN-HNP is a prefix assigned to the link between MN and MAG. MN-HoA is a global unique address from MN-HNP and used as a source address of MN's unicast and multicast packets. Regards, -- Hitoshi Asaeda From multimob2011@gmail.com Fri Dec 16 01:09:02 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 5F44A21F85F1 for ; Fri, 16 Dec 2011 01:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, 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 bHStFPtW0uCp for ; Fri, 16 Dec 2011 01:09:02 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7321F85DB for ; Fri, 16 Dec 2011 01:09:01 -0800 (PST) Received: by ghrr16 with SMTP id r16so2530807ghr.31 for ; Fri, 16 Dec 2011 01:09:00 -0800 (PST) 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:cc :content-type; bh=EVZ8z6BIwDa32sIllAF2kyKNgVDmTeoMxwJUnU7P4wM=; b=ZriKUuoFDTWmw4TkC5J0cbM3bzsJuaoHg1/zqw9assJTtQujs5VB74NqweuTNeb/i4 Df/681yVucpVKVuCDeUlUSPT6fQ2xactYW4HgCpW2m7n0pJTNdUzsXIxu7H6bo+EShKL WYS/Z3yZkPUu2n8euSZETJL9X5+Rw9VaV11RE= MIME-Version: 1.0 Received: by 10.50.207.40 with SMTP id lt8mr7640073igc.43.1324026539845; Fri, 16 Dec 2011 01:08:59 -0800 (PST) Received: by 10.50.220.197 with HTTP; Fri, 16 Dec 2011 01:08:59 -0800 (PST) In-Reply-To: <20111216.165756.75577605.asaeda@sfc.wide.ad.jp> References: <20111216.131006.111370807.asaeda@sfc.wide.ad.jp> <20111216.165756.75577605.asaeda@sfc.wide.ad.jp> Date: Fri, 16 Dec 2011 17:08:59 +0800 Message-ID: From: Aaron Feng Cc: multimob@ietf.org Content-Type: multipart/alternative; boundary=14dae934099194a93204b431f336 Subject: Re: [multimob] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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: Fri, 16 Dec 2011 09:09:02 -0000 --14dae934099194a93204b431f336 Content-Type: text/plain; charset=ISO-8859-1 > > > MN-HNP is a prefix assigned to the link between MN and MAG. > MN-HoA is a global unique address from MN-HNP and used as a source > address of MN's unicast and multicast packets. > Sure. When the MN sends Mcast data with the source address MN-HOA to MAG, the MAG acting as the DR checks whether the HNP is the same with the physical interface of the MAG. Since the MAG has not any physical interfaces assigned with MN's HNP, the check of direct connection might fail. Regards, Aaron --14dae934099194a93204b431f336 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
MN-HNP is a prefix assigned to the link between = MN and MAG.
MN-HoA is a global unique address from MN-HNP and used as a = source
address of MN's unicast and multicast packets.
Sure. When the MN sends Mcast data with the source address MN-HOA to M= AG, the MAG acting as the DR checks=A0whether the HNP is the same with=A0th= e physical interface of the MAG.=A0Since the MAG has not any physical inter= faces assigned with MN's HNP, the check of direct connection might fail= .
=A0
Regards,
Aaron=A0


--14dae934099194a93204b431f336-- From stig@venaas.com Wed Dec 21 11:15:44 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 EF4D821F8ABE for ; Wed, 21 Dec 2011 11:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 62oJjlqMZte0 for ; Wed, 21 Dec 2011 11:15:44 -0800 (PST) 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 5593221F8AB9 for ; Wed, 21 Dec 2011 11:15:44 -0800 (PST) Received: from [10.33.12.86] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9924E7FFE; Wed, 21 Dec 2011 20:15:40 +0100 (CET) Message-ID: <4EF2305A.9070308@venaas.com> Date: Wed, 21 Dec 2011 11:15:38 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Aaron Feng References: <20111216.131006.111370807.asaeda@sfc.wide.ad.jp> <20111216.165756.75577605.asaeda@sfc.wide.ad.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: Questions for point-to-point link and the check of directly connection of the mcast source? 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, 21 Dec 2011 19:15:45 -0000 On 12/16/2011 1:08 AM, Aaron Feng wrote: > MN-HNP is a prefix assigned to the link between MN and MAG. > MN-HoA is a global unique address from MN-HNP and used as a source > address of MN's unicast and multicast packets. > > Sure. When the MN sends Mcast data with the source address MN-HOA to > MAG, the MAG acting as the DR checks whether the HNP is the same > with the physical interface of the MAG. Since the MAG has not any > physical interfaces assigned with MN's HNP, the check of direct > connection might fail. Whether an interface is physical or not does not matter. What happens on several implementations (I think probably Linux and BSD as well) is that if you have an interface with an IP address and mask, you install a route in the RIB corresponding to this and with some flag marking it as directly connected (i.e., no next-hop). PIM can then use this to determine that the source is directly connected. For PIM to work with PMIP on the MAG, you may need to either ensure that these routes are installed, or have PIM use other information than just the RIB. Is your concern that the MAG may not have an interface corresponding to the MAG-MN tunnel? I guess this depends on the implementation, and how the tunnel is realized. Stig > Regards, > Aaron > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Wed Dec 21 11:21:56 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 0B30411E8073 for ; Wed, 21 Dec 2011 11:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 RYC6IiUljOyD for ; Wed, 21 Dec 2011 11:21:55 -0800 (PST) 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 E240621F8AF1 for ; Wed, 21 Dec 2011 11:21:54 -0800 (PST) Received: from [10.33.12.86] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 13C5E7FFE; Wed, 21 Dec 2011 20:21:52 +0100 (CET) Message-ID: <4EF231CE.909@venaas.com> Date: Wed, 21 Dec 2011 11:21:50 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> <4EE662FA.2070608@venaas.com> <20111214.145230.267424073.asaeda@sfc.wide.ad.jp> In-Reply-To: <20111214.145230.267424073.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 21 Dec 2011 19:21:56 -0000 On 12/13/2011 9:52 PM, Hitoshi Asaeda wrote: > Hi Stig, > >> Regarding PMIP routing and PIM and MRIB etc. It seems to me that there >> is pretty much agreement on how this works. I still would like to say >> how I believe it works and what could be done. > > Right. > >> For PIM (and most multicast routing in general) RPF is essential and >> that is achieved using a routing table (MRIB). This MRIB is in many >> cases identical to the unicast RIB, but it need not be. > > Exactly. > >> Now since PMIP uses policy routing (you cannot tell where a packet >> should be forwarded just by its destination address), you cannot align >> PIM with PMIP using a single RIB. > > It seems that people have been confused. > As I said many times, it is *not necessary* to incorporate PMIP's > unicast policy route into MAG's RIB, in my proposal. > >> However, there are implementations that support multiple RIBs. That >> is multiple VRFs, see e.g. RFC 4364 section 3. In that case, each >> interface on a router would belong to a VRF (a default VRF if >> nothing in particular is configured), or some specific other VRF. >> >> I won't say for sure, but I think it should be possible to match >> PMIP routing and PIM on the MAG by having one VRF per LMA, where >> the MAG-LMA tunnel and each MAG-MN links (for the MNs belonging >> to that LMA). You might compare this to our base approach with >> multiple proxy instances. I think the per LMA VRF table would >> basically have a default route pointing to the MAG-LMA tunnel, >> and then a directly connected route per MAG-MN link. >> >> Does that look correct? Anyone see any issues with that? > > I think your proposal is also interesting in some condition. But > multiple RIBs are not always required. > I don't start discussing what kind of situation multiple RIBs are > needed with PIM, because it gives another confusion. But if we do RPF > solely based on the source address (or RP address) rather than which > MN it is, then a single RIB (and a sigle MRIB) should work. Yes. If we don't attempt to have multicast routing correspond to PMIP routing (such as routing based on MN and not just source), then a single RIB might be sufficient. If the routing is solely on the source address, then a single RIB is fine. An interesting topic might be what kind of policies do we think are useful and how to get the RIB populated to achieve this. Is it OK to solely use the source address? > PIM on MAG only needs to resolve upstream interfaces when it receives > MLD join from MNs. In other words, PMIP unicast policy route is not > needed for RPF check. If RPF is just based on the source address, then a single RIB is fine. > MAG has its RIB. This RIB does not have any entry for MNs' prefixes. > It's Ok. It doesn't affect anything for forwarding multicast packets > received at MAG, because MNs are directly attached to MAG with P2P > link and they can send MLD joins to the MAG directly. And MAG > recognizes the receivers (and OIFs) and forwards packets to the MAG's > OIFs. > > Again, if PIM on MAG can resolve RPF, it can just send PIM join toward > source or RP and forward packets to directly attached MNs who have > requested join. > > Do you agree, Stig? Agree. Except, if the MNs are sources, then you may need RIB entries for the MNs prefixes to allow for directed connected check (see email I just sent in response to Aaron's question). Stig > Regards, > -- > Hitoshi Asaeda From prvs=32915d72e=schmidt@informatik.haw-hamburg.de Wed Dec 21 13:17:39 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 378C91F0C52 for ; Wed, 21 Dec 2011 13:17:39 -0800 (PST) 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 ZGH5sV2p+hMb for ; Wed, 21 Dec 2011 13:17:38 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 56A161F0C4D for ; Wed, 21 Dec 2011 13:17:36 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 21 Dec 2011 22:17:35 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 622AF102C0F9; Wed, 21 Dec 2011 22:17:35 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13756-03; Wed, 21 Dec 2011 22:17:34 +0100 (CET) Received: from [192.168.178.36] (e178063215.adsl.alicedsl.de [85.178.63.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id A8173102C0E1; Wed, 21 Dec 2011 22:17:33 +0100 (CET) Message-ID: <4EF24CF1.8020201@informatik.haw-hamburg.de> Date: Wed, 21 Dec 2011 22:17:37 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Stig Venaas References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> <4EE662FA.2070608@venaas.com> <20111214.145230.267424073.asaeda@sfc.wide.ad.jp> <4EF231CE.909@venaas.com> In-Reply-To: <4EF231CE.909@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 21 Dec 2011 21:17:39 -0000 Hi Stig, please see inline ... On 21.12.2011 20:21, Stig Venaas wrote: > On 12/13/2011 9:52 PM, Hitoshi Asaeda wrote: >> Hi Stig, >> >>> Regarding PMIP routing and PIM and MRIB etc. It seems to me that there >>> is pretty much agreement on how this works. I still would like to say >>> how I believe it works and what could be done. >> >> Right. >> >>> For PIM (and most multicast routing in general) RPF is essential and >>> that is achieved using a routing table (MRIB). This MRIB is in many >>> cases identical to the unicast RIB, but it need not be. >> >> Exactly. >> >>> Now since PMIP uses policy routing (you cannot tell where a packet >>> should be forwarded just by its destination address), you cannot align >>> PIM with PMIP using a single RIB. >> >> It seems that people have been confused. >> As I said many times, it is *not necessary* to incorporate PMIP's >> unicast policy route into MAG's RIB, in my proposal. >> >>> However, there are implementations that support multiple RIBs. That >>> is multiple VRFs, see e.g. RFC 4364 section 3. In that case, each >>> interface on a router would belong to a VRF (a default VRF if >>> nothing in particular is configured), or some specific other VRF. >>> >>> I won't say for sure, but I think it should be possible to match >>> PMIP routing and PIM on the MAG by having one VRF per LMA, where >>> the MAG-LMA tunnel and each MAG-MN links (for the MNs belonging >>> to that LMA). You might compare this to our base approach with >>> multiple proxy instances. I think the per LMA VRF table would >>> basically have a default route pointing to the MAG-LMA tunnel, >>> and then a directly connected route per MAG-MN link. >>> >>> Does that look correct? Anyone see any issues with that? >> >> I think your proposal is also interesting in some condition. But >> multiple RIBs are not always required. >> I don't start discussing what kind of situation multiple RIBs are >> needed with PIM, because it gives another confusion. But if we do RPF >> solely based on the source address (or RP address) rather than which >> MN it is, then a single RIB (and a sigle MRIB) should work. > > Yes. If we don't attempt to have multicast routing correspond to PMIP > routing (such as routing based on MN and not just source), then a > single RIB might be sufficient. If the routing is solely on the source > address, then a single RIB is fine. > > An interesting topic might be what kind of policies do we think are > useful and how to get the RIB populated to achieve this. > > Is it OK to solely use the source address? > If we do so, then we are in the case of plain "direct routing" as basically supported by Seil. Direct routing can of course be built on some uplink tunnel as pointed out in RFC 6224 - however, this solution is disjoint from any support by 'home services' as is the typical PMIP picture. So I believe, you rose the right point when asking about policies: There are two common policies in mobility (in particular in PMIP): (i) home network support, and (ii) visited network support. (ii) is direct routing and easy to achieve with PIM. (i) basically corresponds to PMIP routing and does not go well with PIM (as previously discussed). IMO it is quite hard to think of any reasonable policy that is somehow mixed. >> PIM on MAG only needs to resolve upstream interfaces when it receives >> MLD join from MNs. In other words, PMIP unicast policy route is not >> needed for RPF check. > > If RPF is just based on the source address, then a single RIB is fine. > However, if RPF is bound to the source address, then upstream signaling for MLD join must comply to the unique route that is used for RPF-check in the downstream. Thus PMIP unicast policy route cannot be used on the upstream signaling. >> MAG has its RIB. This RIB does not have any entry for MNs' prefixes. >> It's Ok. It doesn't affect anything for forwarding multicast packets >> received at MAG, because MNs are directly attached to MAG with P2P >> link and they can send MLD joins to the MAG directly. And MAG >> recognizes the receivers (and OIFs) and forwards packets to the MAG's >> OIFs. >> >> Again, if PIM on MAG can resolve RPF, it can just send PIM join toward >> source or RP and forward packets to directly attached MNs who have >> requested join. >> >> Do you agree, Stig? > > Agree. Except, if the MNs are sources, then you may need RIB entries for > the MNs prefixes to allow for directed connected check (see email I just > sent in response to Aaron's question). > Yes, mobile sources is sort of the other side of the coin ;) Cheers, 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 asaeda@sfc.wide.ad.jp Wed Dec 21 22:07:14 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 3E6CD21F8B91 for ; Wed, 21 Dec 2011 22:07:14 -0800 (PST) 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 fEH44-amltrh for ; Wed, 21 Dec 2011 22:07:13 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id AC39E21F8B8C for ; Wed, 21 Dec 2011 22:07:13 -0800 (PST) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 00B95278072; Thu, 22 Dec 2011 15:07:09 +0900 (JST) Date: Thu, 22 Dec 2011 15:07:09 +0900 (JST) Message-Id: <20111222.150709.31059540.asaeda@sfc.wide.ad.jp> To: stig@venaas.com From: Hitoshi Asaeda In-Reply-To: <4EF231CE.909@venaas.com> References: <4EE662FA.2070608@venaas.com> <20111214.145230.267424073.asaeda@sfc.wide.ad.jp> <4EF231CE.909@venaas.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] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 22 Dec 2011 06:07:14 -0000 Hi Stig, > Yes. If we don't attempt to have multicast routing correspond to PMIP > routing (such as routing based on MN and not just source), then a > single RIB might be sufficient. If the routing is solely on the source > address, then a single RIB is fine. > > An interesting topic might be what kind of policies do we think are > useful and how to get the RIB populated to achieve this. > > Is it OK to solely use the source address? Not only source address, but also source prefix(es). When MAG won't use unicast routes (i.e. RIB) for RPF check for outside sources (or outside source prefixes), it uses M-tunnel set up between LMA and MAG, and incorporates the multicast routes with the M-tunnel for the sources (or source prefixes) into its MRIB. >> PIM on MAG only needs to resolve upstream interfaces when it receives >> MLD join from MNs. In other words, PMIP unicast policy route is not >> needed for RPF check. > > If RPF is just based on the source address, then a single RIB is fine. Source prefix, too. >> MAG has its RIB. This RIB does not have any entry for MNs' prefixes. >> It's Ok. It doesn't affect anything for forwarding multicast packets >> received at MAG, because MNs are directly attached to MAG with P2P >> link and they can send MLD joins to the MAG directly. And MAG >> recognizes the receivers (and OIFs) and forwards packets to the MAG's >> OIFs. >> >> Again, if PIM on MAG can resolve RPF, it can just send PIM join toward >> source or RP and forward packets to directly attached MNs who have >> requested join. >> >> Do you agree, Stig? > > Agree. Except, if the MNs are sources, then you may need RIB entries > for > the MNs prefixes to allow for directed connected check (see email I > just > sent in response to Aaron's question). Whether the link is a physical or logicai is not the matter. It's an implementation issue. MAG just recognizes the *directly attached* MNs. Only the problem for source mobility is "detour", because MNs' prefixes are advertised from LMA. It would be possible to provide some optimized way to address "detour", but it does not mean "a single RIB does not work for source mobility in PIM". Regards, -- Hitoshi Asaeda From pierrick.seite@orange.com Thu Dec 22 05:58: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 B7F5321F8B09 for ; Thu, 22 Dec 2011 05:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 cwDgKnb79d5k for ; Thu, 22 Dec 2011 05:58:17 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4EB21F8B05 for ; Thu, 22 Dec 2011 05:58:17 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CBF2E4110C4; Thu, 22 Dec 2011 14:59:22 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id C482E41104D; Thu, 22 Dec 2011 14:59:22 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 14:58:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Dec 2011 14:58:14 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EF24CF1.8020201@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Thread-Index: AczAJfsgBHK2sQMvTvqtFcIZNWVTDgAiqGNA References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp><4EE662FA.2070608@venaas.com><20111214.145230.267424073.asaeda@sfc.wide.ad.jp><4EF231CE.909@venaas.com> <4EF24CF1.8020201@informatik.haw-hamburg.de> From: To: , X-OriginalArrivalTime: 22 Dec 2011 13:58:16.0282 (UTC) FILETIME=[C0C593A0:01CCC0B1] Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 22 Dec 2011 13:58:17 -0000 Hi, I'm confused about the following: > So I believe, you rose the right point when asking about policies: > There > are two common policies in mobility (in particular in PMIP): (i) home > network support, and (ii) visited network support. >=20 I can understand what is home network vs. visited network with MIP, but not with PMIP. The basic of PMIP is that the MN is roaming across its home network across the whole PMIP domain. Each MAG emulates the home network for the MN which remains unaware of the mobility, in other words, the MN plays with only one prefix: the Home network prefix; while a MIP client has to deal with two IP: the home address and the care-of-address. With PMIP, there is no distinction between visited and home network, we could say that PMIP brings a moving home network support... Pierrick From prvs=33044c448=schmidt@informatik.haw-hamburg.de Thu Dec 22 06:58:36 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 3513321F8B39 for ; Thu, 22 Dec 2011 06:58:36 -0800 (PST) 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 UF5P8I506nPP for ; Thu, 22 Dec 2011 06:58:32 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id B071B21F85A1 for ; Thu, 22 Dec 2011 06:58:27 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 22 Dec 2011 15:58:25 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id DCB95102C0DB; Thu, 22 Dec 2011 15:58:25 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13401-02; Thu, 22 Dec 2011 15:58:25 +0100 (CET) Received: from [192.168.178.36] (g231109020.adsl.alicedsl.de [92.231.109.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 2814B102C0C3; Thu, 22 Dec 2011 15:58:22 +0100 (CET) Message-ID: <4EF34592.6030901@informatik.haw-hamburg.de> Date: Thu, 22 Dec 2011 15:58:26 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: pierrick.seite@orange.com References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp><4EE662FA.2070608@venaas.com><20111214.145230.267424073.asaeda@sfc.wide.ad.jp><4EF231CE.909@venaas.com> <4EF24CF1.8020201@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 22 Dec 2011 14:58:36 -0000 Hi Pierrick, no reason for confusion, the picture is simple. First of all, the statement was a general one, but translated to PMIP it distinguishes the cases (i) "data flow via the LMA" and (ii) "local data flow at the MAG". From the policy perspective, this is independent of the IP prefix the MN sees. In the case of a single-operator PMIP domain, you may simple think about (ii) as a route optimization. However, if PMIP is operated across operators, then data services (in particular multicast) may differ and the provisioning really follows a (different) provider policy. The distinction of these two cases has of course strong implications in routing. If we want to provide (i) - like the base solution does - then we need to follow the association of MN <-> LMA, i.e., perform PMIP routing. On the contrary, if mcast data is brought (somehow) directly to the MAG, i.e. independent of the MNs that subscribe, then we can use regular IP routing, either shortest path or by some manually provisioned routing table. The question I extracted from Stigs writing was: "Is there any other reasonable policy that can be implemented in a single RIB ?" ... and this appears as a good, challenging question to me. Do you have any idea on this? Best wishes, Thomas On 22.12.2011 14:58, pierrick.seite@orange.com wrote: > Hi, > > I'm confused about the following: > >> So I believe, you rose the right point when asking about policies: >> There >> are two common policies in mobility (in particular in PMIP): (i) home >> network support, and (ii) visited network support. >> > > I can understand what is home network vs. visited network with MIP, but > not with PMIP. The basic of PMIP is that the MN is roaming across its > home network across the whole PMIP domain. Each MAG emulates the home > network for the MN which remains unaware of the mobility, in other > words, the MN plays with only one prefix: the Home network prefix; while > a MIP client has to deal with two IP: the home address and the > care-of-address. With PMIP, there is no distinction between visited and > home network, we could say that PMIP brings a moving home network > support... > > Pierrick -- 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 pierrick.seite@orange.com Fri Dec 23 14:39:52 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 2F5F221F8B4E for ; Fri, 23 Dec 2011 14:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 GygAAXBibwtT for ; Fri, 23 Dec 2011 14:39:50 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8962021F8B35 for ; Fri, 23 Dec 2011 14:39:50 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 26DAFE30377; Fri, 23 Dec 2011 23:50:49 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1F21DE30305; Fri, 23 Dec 2011 23:50:49 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Dec 2011 23:39:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Dec 2011 23:39:47 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB247@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EF34592.6030901@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Thread-Index: AczAuikIxwj4JKGVQQKn3BkHneO0PQAoTO0g References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp><4EE662FA.2070608@venaas.com><20111214.145230.267424073.asaeda@sfc.wide.ad.jp><4EF231CE.909@venaas.com> <4EF24CF1.8020201@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> <4EF34592.6030901@informatik.haw-hamburg.de> From: To: X-OriginalArrivalTime: 23 Dec 2011 22:39:49.0311 (UTC) FILETIME=[C7489CF0:01CCC1C3] Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 23 Dec 2011 22:39:52 -0000 Hi, > -----Message d'origine----- > De=A0: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > Envoy=E9=A0: jeudi 22 d=E9cembre 2011 15:58 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: stig@venaas.com; multimob@ietf.org > Objet=A0: Re: [multimob] WG adoption call on draft-zuniga-multimob- > pmipv6-ropt >=20 > Hi Pierrick, >=20 > no reason for confusion, the picture is simple. >=20 > First of all, the statement was a general one, but translated to PMIP > it > distinguishes the cases (i) "data flow via the LMA" and (ii) "local > data > flow at the MAG".=20 Ok, I see. I agree this is a valid use-case. Actually, this is the = scenario we're addressing in draft-asade-multimob-pmip6-extension-07 >From the policy perspective, this is independent of > the IP prefix the MN sees. >=20 > In the case of a single-operator PMIP domain, you may simple think > about > (ii) as a route optimization. However, if PMIP is operated across > operators, then data services (in particular multicast) may differ and > the provisioning really follows a (different) provider policy. > > The distinction of these two cases has of course strong implications = in > routing. If we want to provide (i) - like the base solution does - = then > we need to follow the association of MN <-> LMA, i.e., perform PMIP > routing. > On the contrary, if mcast data is brought (somehow) directly to the > MAG, > i.e. independent of the MNs that subscribe, then we can use regular IP > routing, either shortest path or by some manually provisioned routing > table. >=20 Again, I think we agree on the scenario and my understanding is that PIM = capable MAG could meet this requirement. > The question I extracted from Stigs writing was: "Is there any other > reasonable policy that can be implemented in a single RIB ?" ... and > this appears as a good, challenging question to me. >=20 > Do you have any idea on this? > I didn't read all messages regarding this topic and I may miss the point = but, according to discussions and Stig's message, it seems that PIM can = be used on the MAG. If I remember well, the question was to know if a = RIB can be used on the MAG. Actually, MAG is a mobility function usually = implemented on a router, so with a RIB. Regarding our use-case the MAG = has two upstream interfaces (i.e. the tunnel to the LMA and the regular = interface) that can be used to send PIM messages. Then, depending on the = source to reach, PIM messages can be sent either via the LMA or = "locally". I'm not a multicast expert, but I guess, this is a current = behavior for a multiple interfaces PIM router. =20 Best regards, Pierrick > Best wishes, >=20 > Thomas >=20 > On 22.12.2011 14:58, pierrick.seite@orange.com wrote: > > Hi, > > > > I'm confused about the following: > > > >> So I believe, you rose the right point when asking about policies: > >> There > >> are two common policies in mobility (in particular in PMIP): (i) > home > >> network support, and (ii) visited network support. > >> > > > > I can understand what is home network vs. visited network with MIP, > but > > not with PMIP. The basic of PMIP is that the MN is roaming across = its > > home network across the whole PMIP domain. Each MAG emulates the = home > > network for the MN which remains unaware of the mobility, in other > > words, the MN plays with only one prefix: the Home network prefix; > while > > a MIP client has to deal with two IP: the home address and the > > care-of-address. With PMIP, there is no distinction between visited > and > > home network, we could say that PMIP brings a moving home network > > support... > > > > Pierrick >=20 > -- >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor > 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875- > 8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875- > 8409 =B0 From prvs=3311d1620=schmidt@informatik.haw-hamburg.de Fri Dec 23 15:10:49 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 07BEF21F8B72 for ; Fri, 23 Dec 2011 15:10:49 -0800 (PST) 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 AM80wncX0sov for ; Fri, 23 Dec 2011 15:10:42 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6798421F8B6D for ; Fri, 23 Dec 2011 15:10:40 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 24 Dec 2011 00:10:39 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id A7AD6102BD33; Sat, 24 Dec 2011 00:10:39 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28123-02; Sat, 24 Dec 2011 00:10:39 +0100 (CET) Received: from [192.168.178.36] (g231108082.adsl.alicedsl.de [92.231.108.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 8A829102C0C8; Sat, 24 Dec 2011 00:10:38 +0100 (CET) Message-ID: <4EF50A73.6030602@informatik.haw-hamburg.de> Date: Sat, 24 Dec 2011 00:10:43 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: pierrick.seite@orange.com References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp><4EE662FA.2070608@venaas.com><20111214.145230.267424073.asaeda@sfc.wide.ad.jp><4EF231CE.909@venaas.com> <4EF24CF1.8020201@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> <4EF34592.6030901@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB247@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462021AB247@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Fri, 23 Dec 2011 23:10:49 -0000 Hi Pierrick, On 23.12.2011 23:39, pierrick.seite@orange.com wrote: >> -----Message d'origine----- >> De : Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] >> Envoyé : jeudi 22 décembre 2011 15:58 >> À : SEITE Pierrick RD-RESA-REN >> Cc : stig@venaas.com; multimob@ietf.org >> Objet : Re: [multimob] WG adoption call on draft-zuniga-multimob- >> pmipv6-ropt >> >> Hi Pierrick, >> >> no reason for confusion, the picture is simple. >> >> First of all, the statement was a general one, but translated to PMIP >> it >> distinguishes the cases (i) "data flow via the LMA" and (ii) "local >> data >> flow at the MAG". > > > Ok, I see. I agree this is a valid use-case. Actually, this is the scenario we're addressing in draft-asade-multimob-pmip6-extension-07 You speak about use-case (ii)? In the current versions of the draft, mcast signaling is explained to follow MN <-> LMA binding (see for example "Figure 2: MLD Report Messages Transmission") and this is use-case (i). > > From the policy perspective, this is independent of >> the IP prefix the MN sees. >> > > >> In the case of a single-operator PMIP domain, you may simple think >> about >> (ii) as a route optimization. However, if PMIP is operated across >> operators, then data services (in particular multicast) may differ and >> the provisioning really follows a (different) provider policy. >> >> The distinction of these two cases has of course strong implications in >> routing. If we want to provide (i) - like the base solution does - then >> we need to follow the association of MN<-> LMA, i.e., perform PMIP >> routing. >> On the contrary, if mcast data is brought (somehow) directly to the >> MAG, >> i.e. independent of the MNs that subscribe, then we can use regular IP >> routing, either shortest path or by some manually provisioned routing >> table. >> > > Again, I think we agree on the scenario and my understanding is that PIM capable MAG could meet this requirement. > Yes, this is fine - but this is the solution Seil is proposing. >> The question I extracted from Stigs writing was: "Is there any other >> reasonable policy that can be implemented in a single RIB ?" ... and >> this appears as a good, challenging question to me. >> >> Do you have any idea on this? >> > > I didn't read all messages regarding this topic and I may miss the point but, according to discussions and Stig's message, it seems that PIM can be used on the MAG. Yes, of course it can. > If I remember well, the question was to know if a RIB can be used on the MAG. Actually, MAG is a mobility function usually implemented on a router, so with a RIB. Yes, it's regular RIB is for the management. > Regarding our use-case the MAG has two upstream interfaces (i.e. the tunnel to the LMA and the regular interface) that can be used to send PIM messages. Normally, the MAG has many potential upstream interfaces, one for each LMA (the tunnels), and possibly one or several local interfaces for management and intra-provider purposes. > Then, depending on the source to reach, PIM messages can be sent either via the LMA or "locally". I'm not a multicast expert, but I guess, this is a current behavior for a multiple interfaces PIM router. Sources here are remote multicast senders or Rendezvous Points. For each of these "multicast originators" a unique route in the RIB is required. This could be an LMA-tunnel interface, meaning that all multicast traffic from that source flows via this particular LMA for all MNs (including those *not* associated with this particular LMA). This could also be a local route ... and this is the local routing option (case (ii)). Using a particular LMA for upstream (independent of the MN) is in the area of "mixed use-cases", and I guess that's what Stig asked about. Why should a particular LMA (possibly from a different provider) serve MNs that are in no relation to it? What is a reasonable rule to select LMAs according to multicast originators? What happens, if unicast handover management actually terminates the tunnel-relationship to this LMA, while other (unrelated) mobile receivers persist? Those questions seem difficult to answer to me ... and that's the background for asking about reasonable ideas or concepts of "mixed policies" ... currently, I don't see any. Best wishes, Thomas >> >> On 22.12.2011 14:58, pierrick.seite@orange.com wrote: >>> Hi, >>> >>> I'm confused about the following: >>> >>>> So I believe, you rose the right point when asking about policies: >>>> There >>>> are two common policies in mobility (in particular in PMIP): (i) >> home >>>> network support, and (ii) visited network support. >>>> >>> >>> I can understand what is home network vs. visited network with MIP, >> but >>> not with PMIP. The basic of PMIP is that the MN is roaming across its >>> home network across the whole PMIP domain. Each MAG emulates the home >>> network for the MN which remains unaware of the mobility, in other >>> words, the MN plays with only one prefix: the Home network prefix; >> while >>> a MIP client has to deal with two IP: the home address and the >>> care-of-address. With PMIP, there is no distinction between visited >> and >>> home network, we could say that PMIP brings a moving home network >>> support... >>> >>> Pierrick >> >> -- >> >> 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 ° > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- 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 pierrick.seite@orange.com Sat Dec 24 08:28: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 9C21F21F84AD for ; Sat, 24 Dec 2011 08:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 AlLDNHiyaDLu for ; Sat, 24 Dec 2011 08:28:14 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA8121F84AC for ; Sat, 24 Dec 2011 08:28:14 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0C536E30371; Sat, 24 Dec 2011 17:39:13 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 056E1E3036F; Sat, 24 Dec 2011 17:39:13 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Dec 2011 17:28:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Dec 2011 17:27:27 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB252@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EF50A73.6030602@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Thread-Index: AczByBc54FjjWMQySK2b2DGRzrPxTAAjgXoQ References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp><4EE662FA.2070608@venaas.com><20111214.145230.267424073.asaeda@sfc.wide.ad.jp><4EF231CE.909@venaas.com> <4EF24CF1.8020201@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> <4EF34592.6030901@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB247@ftrdmel0.rd.francetelecom.fr> <4EF50A73.6030602@informatik.haw-hamburg.de> From: To: X-OriginalArrivalTime: 24 Dec 2011 16:28:12.0822 (UTC) FILETIME=[07F42360:01CCC259] Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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: Sat, 24 Dec 2011 16:28:15 -0000 Hi Thomas, Good, it seems that we are all in agreement now: PIM on MAG works.=20 So, I'd suggest to document that behavior, then we could address related = issues like policy provisioning, interaction with unicast mobility = management, and so on. Just a suggestion to move forward... step by = step. =20 Regarding documents we have on the table, I was referring to Hitoshi's = draft because it was the first to tackle the issue and I didn't read = more recent proposals, so maybe you're right: Seil's draft is going in = the same direction. Anyway, it's good... we have enough materials to = move forward. Best regards and happy Cristmas. Pierrick > -----Message d'origine----- > De=A0: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > Envoy=E9=A0: samedi 24 d=E9cembre 2011 00:11 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: multimob@ietf.org > Objet=A0: Re: [multimob] WG adoption call on draft-zuniga-multimob- > pmipv6-ropt >=20 > Hi Pierrick, >=20 > On 23.12.2011 23:39, pierrick.seite@orange.com wrote: >=20 > >> -----Message d'origine----- > >> De : Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de] > >> Envoy=E9 : jeudi 22 d=E9cembre 2011 15:58 > >> =C0 : SEITE Pierrick RD-RESA-REN > >> Cc : stig@venaas.com; multimob@ietf.org > >> Objet : Re: [multimob] WG adoption call on draft-zuniga-multimob- > >> pmipv6-ropt > >> > >> Hi Pierrick, > >> > >> no reason for confusion, the picture is simple. > >> > >> First of all, the statement was a general one, but translated to > PMIP > >> it > >> distinguishes the cases (i) "data flow via the LMA" and (ii) "local > >> data > >> flow at the MAG's ". > > > > > > Ok, I see. I agree this is a valid use-case. Actually, this is the > scenario we're addressing in draft-asade-multimob-pmip6-extension-07 >=20 > You speak about use-case (ii)? In the current versions of the draft, > mcast signaling is explained to follow MN <-> LMA binding (see for > example "Figure 2: MLD Report Messages Transmission") and this is > use-case (i). >=20 > > > > From the policy perspective, this is independent of > >> the IP prefix the MN sees. > >> > > > > > >> In the case of a single-operator PMIP domain, you may simple think > >> about > >> (ii) as a route optimization. However, if PMIP is operated across > >> operators, then data services (in particular multicast) may differ > and > >> the provisioning really follows a (different) provider policy. > >> > >> The distinction of these two cases has of course strong = implications > in > >> routing. If we want to provide (i) - like the base solution does - > then > >> we need to follow the association of MN<-> LMA, i.e., perform PMIP > >> routing. > >> On the contrary, if mcast data is brought (somehow) directly to the > >> MAG, > >> i.e. independent of the MNs that subscribe, then we can use regular > IP > >> routing, either shortest path or by some manually provisioned > routing > >> table. > >> > > > > Again, I think we agree on the scenario and my understanding is that > PIM capable MAG could meet this requirement. > > >=20 > Yes, this is fine - but this is the solution Seil is proposing. >=20 > >> The question I extracted from Stigs writing was: "Is there any = other > >> reasonable policy that can be implemented in a single RIB ?" ... = and > >> this appears as a good, challenging question to me. > >> > >> Do you have any idea on this? > >> > > > > I didn't read all messages regarding this topic and I may miss the > point but, according to discussions and Stig's message, it seems that > PIM can be used on the MAG. >=20 > Yes, of course it can. >=20 > > If I remember well, the question was to know if a RIB can be used on > the MAG. Actually, MAG is a mobility function usually implemented on a > router, so with a RIB. >=20 > Yes, it's regular RIB is for the management. >=20 > > Regarding our use-case the MAG has two upstream interfaces (i.e. the > tunnel to the LMA and the regular interface) that can be used to send > PIM messages. >=20 > Normally, the MAG has many potential upstream interfaces, one for each > LMA (the tunnels), and possibly one or several local interfaces for > management and intra-provider purposes. >=20 > > Then, depending on the source to reach, PIM messages can be sent > either via the LMA or "locally". I'm not a multicast expert, but I > guess, this is a current behavior for a multiple interfaces PIM = router. >=20 > Sources here are remote multicast senders or Rendezvous Points. For > each > of these "multicast originators" a unique route in the RIB is > required. > This could be an LMA-tunnel interface, meaning that all multicast > traffic from that source flows via this particular LMA for all MNs > (including those *not* associated with this particular LMA). This = could > also be a local route ... and this is the local routing option (case > (ii)). >=20 > Using a particular LMA for upstream (independent of the MN) is in the > area of "mixed use-cases", and I guess that's what Stig asked about. >=20 > Why should a particular LMA (possibly from a different provider) serve > MNs that are in no relation to it? >=20 > What is a reasonable rule to select LMAs according to multicast > originators? >=20 > What happens, if unicast handover management actually terminates the > tunnel-relationship to this LMA, while other (unrelated) mobile > receivers persist? >=20 > Those questions seem difficult to answer to me ... and that's the > background for asking about reasonable ideas or concepts of "mixed > policies" ... currently, I don't see any. >=20 > Best wishes, >=20 > Thomas >=20 >=20 > >> > >> On 22.12.2011 14:58, pierrick.seite@orange.com wrote: > >>> Hi, > >>> > >>> I'm confused about the following: > >>> > >>>> So I believe, you rose the right point when asking about = policies: > >>>> There > >>>> are two common policies in mobility (in particular in PMIP): (i) > >> home > >>>> network support, and (ii) visited network support. > >>>> > >>> > >>> I can understand what is home network vs. visited network with = MIP, > >> but > >>> not with PMIP. The basic of PMIP is that the MN is roaming across > its > >>> home network across the whole PMIP domain. Each MAG emulates the > home > >>> network for the MN which remains unaware of the mobility, in other > >>> words, the MN plays with only one prefix: the Home network prefix; > >> while > >>> a MIP client has to deal with two IP: the home address and the > >>> care-of-address. With PMIP, there is no distinction between = visited > >> and > >>> home network, we could say that PMIP brings a moving home network > >>> support... > >>> > >>> Pierrick > >> > >> -- > >> > >> Prof. Dr. Thomas C. Schmidt > >> =B0 Hamburg University of Applied Sciences = Berliner > Tor > >> 7 =B0 > >> =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > >> Germany =B0 > >> =B0 http://www.haw-hamburg.de/inet Fon: +49-40- > 42875- > >> 8452 =B0 > >> =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40- > 42875- > >> 8409 =B0 > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob >=20 > -- >=20 > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner = Tor > 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, > Germany =B0 > =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875- > 8452 =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875- > 8409 =B0 From lmcm@tid.es Mon Dec 26 14:07:46 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 BE2C321F8C55 for ; Mon, 26 Dec 2011 14:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3LfJvrlCSFgV for ; Mon, 26 Dec 2011 14:07:46 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8878421F8C45 for ; Mon, 26 Dec 2011 14:07:45 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWU002RS04V6G@tid.hi.inet> for multimob@ietf.org; Mon, 26 Dec 2011 23:07:44 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 63.6D.02643.F20F8FE4; Mon, 26 Dec 2011 23:07:43 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LWU002RN04V6G@tid.hi.inet> for multimob@ietf.org; Mon, 26 Dec 2011 23:07:43 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 26 Dec 2011 23:07:43 +0100 Date: Mon, 26 Dec 2011 23:07:39 +0100 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <4EF50A73.6030602@informatik.haw-hamburg.de> To: "Thomas C. Schmidt" , "pierrick.seite@orange.com" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: es-ES Content-transfer-encoding: base64 Accept-Language: es-ES, en-US Thread-topic: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt Thread-index: AczByCCwjjuuIr+rRauV6dxex/m5LgCTIhPA acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-fc-4ef8f02fef72 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA02SW0gUURzGObOzw7jsxNnV3T1egpqSpPCKqIFE4oMptARBQWY2ttPOwF5k ZhXtaQ0zshDzsthaKbYgaihWmksatYSVoqsPFVRoFwNveHsIU9BmdvDy9vH/fefj+3P+pErf qo4ieYeLFRyMjSY0uKbQnByfuLJuTpqdSc9oWq3BT4MzPt8/7By4pMm0sDa+lBUST13VcJ6x oLq4LqbszftpzA1eRFeDMBLBVLR2Z1ytaCOamOohqoGG1MN+gBru9RMy0MNNgCaX0hRQAVDz x0FcBjiMRR1fAiFNwGTk9deFksLhWbQ18C00D4Mn0cLtRkzWEbAUBf70hOYqeAJ5ttpUsqZg Lno3OkwoWofW66ckDyl5jqGGBrtiN6GHG/fVij6MPG1uIGsAD6KO4ChQ4s2o6ukHQtEpaHP1 J6Z4YtB2+xCuLAmRbzCoUrQBzf3eUit7NeKob66SqAUm774a3r0a3n01vPtqtAK8ExjFIoG3 ci47w9usSSkJHJ/AO1jXM6B8ET8A2v1HAwCSgNZStWPrZr2aKRXL7QEQSWK0gepYkkYHipyW co4RuUKhxMaKAYBIFR1Bmd9KjLIw5TdYwbmDYkiSRlTzsoR0Amtly67zNukqdjBGhsnPtdJz g+yhxGLGLvJWhY+AWLJl5PkY0OMOp4ONMlHxsgnKJq7EsZszD0xS4XCqSqZa6ex2E+alcEwK v3IkFO5i9lCUGzz41ZXXGf2KzFls1VmZjMnX3drIqZeV4/44wX/tPBN+uetHb9/jiVn8M/1k JTfve/WFWY+u8W8qzMrfdt7aWE4bSe/NeTRxsd7gbtrGhlumhQXx7mRNgTGzjY4cXi0YnNN5 KrPzsTgjWuxnPvmy13xfs4KLFUOHbppnrBYvjYsck3xcJYjMf3sD5AkzAwAA References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> <4EE662FA.2070608@venaas.com> <20111214.145230.267424073.asaeda@sfc.wide.ad.jp> <4EF231CE.909@venaas.com> <4EF24CF1.8020201@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> <4EF34592.6030901@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB247@ftrdmel0.rd.francetelecom.fr> <4EF50A73.6030602@informatik.haw-hamburg.de> Cc: "multimob@ietf.org" Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 26 Dec 2011 22:07:46 -0000 SGkgYWxsLA0KDQpTb21lIGNvbW1lbnRzIGJlbG93IChvbiBsYXN0IFRob21hcycgbWFpbCkgdGhp bmtpbmcgb24gUElNIHNvbHV0aW9uIG9uIE1BRywgYW5kIGZvY3VzaW5nIG9uICBkcmFmdC16dW5p Z2EtbXVsdGltb2ItcG1pcHY2LXJvcHQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNClVzaW5nIGEgcGFydGljdWxhciBMTUEgZm9yIHVwc3RyZWFtIChpbmRlcGVu ZGVudCBvZiB0aGUgTU4pIGlzIGluIHRoZSBhcmVhIG9mICJtaXhlZCB1c2UtY2FzZXMiLCBhbmQg SSBndWVzcyB0aGF0J3Mgd2hhdCBTdGlnIGFza2VkIGFib3V0Lg0KDQpbTHVpcz4+XSBUaGlzIGlz IHRoZSByb2xlIHBsYXllZCBieSBlaXRoZXIgdGhlIE1UTUEgb3IgdGhlIEgtTE1BIGluIGRyYWZ0 LXp1bmlnYS1tdWx0aW1vYi1wbWlwdjYtcm9wdA0KDQpXaHkgc2hvdWxkIGEgcGFydGljdWxhciBM TUEgKHBvc3NpYmx5IGZyb20gYSBkaWZmZXJlbnQgcHJvdmlkZXIpIHNlcnZlIE1OcyB0aGF0IGFy ZSBpbiBubyByZWxhdGlvbiB0byBpdD8NCg0KW0x1aXM+Pl0gSWYgdGhlcmUgaXMgYSBjZXJ0YWlu IGNvbW1vbiBjb250ZW50IChjcmVhdGVkIGJ5IGEgY2VydGFpbiBjb250ZW50IG9yaWdpbmF0b3Is IGFuZCBkaXN0cmlidXRlZCBieSB1c2luZyB0aGUgc2FtZSBJUCBkZXN0aW5hdGlvbiBhZGRyZXNz KSBzdWJzY3JpYmVkIGJ5IGRpZmZlcmVudCBNTnMgYXNzb2NpYXRlZCB3aXRoIGRpc3RpbmN0IExN QXMsIGl0IG1ha2VzIHNlbnNlIHRvIGRpc3RyaWJ1dGUgb25seSBvbmNlIGZvciBhbGwgdGhvc2Ug TU5zIGluZGVwZW5kZW50bHkgb2YgdGhlIExNQSB3aGljaCB0aGV5IGFyZSBhc3NvY2lhdGVkIHRv LCBpbnN0ZWFkIG9mIGRvaW5nIGl0IGluIHBhcmFsbGVsIG11bHRpcGxlIHRpbWVzLiBTdWNoIHVu aXF1ZSBkaXN0cmlidXRpb24gc2hvdWxkIHVzZSBhbiBlbnRpdHkgY29tbW9uIHRvIGFsbCBvZiB0 aGVtLCB0aGUgc28gY2FsbGVkIE1UTUEgKG9yIHRoZSBILUxNQSkuDQoNCldoYXQgaXMgYSByZWFz b25hYmxlIHJ1bGUgdG8gc2VsZWN0IExNQXMgYWNjb3JkaW5nIHRvIG11bHRpY2FzdCBvcmlnaW5h dG9ycz8NCg0KW0x1aXM+Pl0gSWYgdGhlIG11bHRpY2FzdCBvcmlnaW5hdG9ycyAoSSBndWVzcyB5 b3UgbWVhbiBtdWx0aWNhc3Qgc291cmNlcykgYXJlIGhvbWVkIGluIGRpZmZlcmVudCBuZXR3b3Jr cywgd2UgY291bGQgdGhpbmsgaW4gYW4gc2NlbmFyaW8gd2hlcmUgZGlmZmVyZW50IE1UTUFzIChv ciBILUxNQXMpIGV4aXN0cywgb25lIHBlciBtdWx0aWNhc3Qgc291cmNlIGhvbWUsIGluIHN1Y2gg YSB3YXkgdGhhdCB0aGUgTU5zIGRlbWFuZGluZyB0byBiZSBzZXJ2ZWQgYnkgYSBjZXJ0YWluIG11 bHRpY2FzdCBzb3VyY2UgYXJlIHBvaW50ZWQgdG93YXJkcyB0aGUgdHVubmVsIGNvbm5lY3Rpbmcg dG8gdGhlIGNvcnJlc3BvbmRpbmcgTVRNQSAoZS5nLiwgYnkgdGhlIHVzZSBvZiBzdGF0aWMgbXVs dGljYXN0IHJvdXRlIGNvbmZpZ3VyYXRpb24pLg0KDQpXaGF0IGhhcHBlbnMsIGlmIHVuaWNhc3Qg aGFuZG92ZXIgbWFuYWdlbWVudCBhY3R1YWxseSB0ZXJtaW5hdGVzIHRoZSB0dW5uZWwtcmVsYXRp b25zaGlwIHRvIHRoaXMgTE1BLCB3aGlsZSBvdGhlciAodW5yZWxhdGVkKSBtb2JpbGUgcmVjZWl2 ZXJzIHBlcnNpc3Q/DQoNCltMdWlzPj5dIFRoZSBNVE1BIHR1bm5lbCBpcyBzZXQgdXAgLyB0ZWFy IGRvd24gZm9yIG11bHRpY2FzdCB0cmFmZmljLiBIb3dldmVyLCB0aGUgY2FzZSB5b3UgbWVudGlv biBpcyBhcHBsaWNhYmxlIHRvIHRoZSBILUxNQSBjYXNlLiBEdWUgdGhhdCB0aGUgdHVubmVsIGlz IHVzZWQgZm9yIGJvdGggdW5pY2FzdCBhbmQgbXVsdGljYXN0LCB0aGUgdHVubmVsIGxpZmV0aW1l IHNob3VsZCBiZSBjb25kaXRpb25lZCBieSB0aGUgZXhpc3RlbmNlIG9mIHVuaWNhc3QgYW5kIG11 bHRpY2FzdCB1c2Vycywgc28gdGhpcyBpc3N1ZSBoYXMgdG8gYmUgY29uc2lkZXJlZCBkZWZpbml0 ZWx5Lg0KDQpUaG9zZSBxdWVzdGlvbnMgc2VlbSBkaWZmaWN1bHQgdG8gYW5zd2VyIHRvIG1lIC4u LiBhbmQgdGhhdCdzIHRoZSBiYWNrZ3JvdW5kIGZvciBhc2tpbmcgYWJvdXQgcmVhc29uYWJsZSBp ZGVhcyBvciBjb25jZXB0cyBvZiAibWl4ZWQgcG9saWNpZXMiIC4uLiBjdXJyZW50bHksIEkgZG9u J3Qgc2VlIGFueS4NCg0KW0x1aXM+Pl0gSSBob3BlIHRoaXMgY291bGQgYmUgY29uc2lkZXJlZCBh IHJlYXNvbmFibGUgaW5wdXQgZm9yIHlvdS4NClRoYW5rcywgYmVzdCByZWdhcmRzLA0KDQpMdWlz DQoNCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0 YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2Vw Y2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFi YWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVz c2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0 ZXJtcyBzZXQgb3V0IGF0Lg0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVy LmFzcHgNCg== From sarikaya2012@gmail.com Mon Dec 26 20:26:18 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 4D2A721F8AF5 for ; Mon, 26 Dec 2011 20:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxNfPZdU04m4 for ; Mon, 26 Dec 2011 20:26:17 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3D1921F8AF2 for ; Mon, 26 Dec 2011 20:26:17 -0800 (PST) Received: by yenm7 with SMTP id m7so7621325yen.31 for ; Mon, 26 Dec 2011 20:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=QN5nCtIqEFCFMRBoMMdsR1HzCXuHks4vPGR52cRgf1U=; b=soLJ5jWeD79OdrJ0ihd84cirM6Bo0GiIqc4zQZJbPYlKYhsvS3acbqjblfC98iWzmp 5bFyO+yUlYv1hSrSfV/GnPJqNQ+j/ngeYJu2xhbtCIR8yAwzHwRYh8bEGnj5P00/oMy6 HdkqLJZjodYvVTRrqOuCUX8LJWJuH1ZW8ewCc= MIME-Version: 1.0 Received: by 10.236.200.164 with SMTP id z24mr35169123yhn.127.1324959977384; Mon, 26 Dec 2011 20:26:17 -0800 (PST) Received: by 10.236.125.201 with HTTP; Mon, 26 Dec 2011 20:26:17 -0800 (PST) Date: Mon, 26 Dec 2011 22:26:17 -0600 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [multimob] PIM at MAG vs multicast service X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 04:26:18 -0000 Hi all, I have been reading the thread on WG adoption call on draft-zuniga-multimob-pmipv6-ropt unfortunately the discussions are no longer on draft-zuniga-multimob-pmipv6-ropt which is on providing multicast service and are very confusing to follow basically because somehow the discussions have been diverted to another draft (draft-asaeda-multimob-pmip6-extension-07) which is (among other things) on PIM at MAG. I suggest that we resolve the issue at hand, i.e.the adoption call first. Afterwards I suggest that the authors of draft-asaeda-multimob-pmip6-extension-07 issue another draft and clearly explain PIM at MAG idea and present it in the next meeting. This should enable us to see if PIM at MAG is a routing solution to the tunnel convergence problem. The use of terms like local routing is becoming a big source of confusion in the mails and in the drafts. Please note that in Netext localized routing is used to mean MAG to MAG routing instead of the regular MAG to LMA routing as in draft-ietf-netext-pmip-lr. Staying away from such terms is a way of avoiding confusion because maybe we don't need to use this term in the first place. Hope this helps. Regards, Behcet From prvs=3355f55e5=schmidt@informatik.haw-hamburg.de Tue Dec 27 03:11:39 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 0C64A21F84A9 for ; Tue, 27 Dec 2011 03:11:39 -0800 (PST) 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 SkGJ6OLVgN9q for ; Tue, 27 Dec 2011 03:11:38 -0800 (PST) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id DCF1521F84A5 for ; Tue, 27 Dec 2011 03:11:37 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 27 Dec 2011 12:11:36 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 31823102BD24; Tue, 27 Dec 2011 12:11:36 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09438-04; Tue, 27 Dec 2011 12:11:35 +0100 (CET) Received: from [192.168.178.36] (g231104193.adsl.alicedsl.de [92.231.104.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 4F5C7102C0EF; Tue, 27 Dec 2011 12:11:35 +0100 (CET) Message-ID: <4EF9A7EA.6060107@informatik.haw-hamburg.de> Date: Tue, 27 Dec 2011 12:11:38 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: LUIS MIGUEL CONTRERAS MURILLO References: <20111212.152122.122235254.asaeda@sfc.wide.ad.jp> <4EE662FA.2070608@venaas.com> <20111214.145230.267424073.asaeda@sfc.wide.ad.jp> <4EF231CE.909@venaas.com> <4EF24CF1.8020201@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB116@ftrdmel0.rd.francetelecom.fr> <4EF34592.6030901@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462021AB247@ftrdmel0.rd.francetelecom.fr> <4EF50A73.6030602@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: "multimob@ietf.org" Subject: Re: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt 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, 27 Dec 2011 11:11:39 -0000 Hello Luis, On 26.12.2011 23:07, LUIS MIGUEL CONTRERAS MURILLO wrote: > > Some comments below (on last Thomas' mail) thinking on PIM solution on MAG, and focusing on draft-zuniga-multimob-pmipv6-ropt. > ---------------------------------------- > > Using a particular LMA for upstream (independent of the MN) is in the area of "mixed use-cases", and I guess that's what Stig asked about. > > [Luis>>] This is the role played by either the MTMA or the H-LMA in draft-zuniga-multimob-pmipv6-ropt > I'm not sure about this, it rather seems that the term "*-LMA" is confusing here (as discussed earlier). The LMA is a PMIP unicast entity that provides home agent services (including handover management) for its associated MNs. Your solution is a tunnel-endpoint that serves multicast streams, sometimes referred to as "head-end". Just to be clear: I'm not objecting the solution, but just question the name for the tunnel endpoint. > Why should a particular LMA (possibly from a different provider) serve MNs that are in no relation to it? > > [Luis>>] If there is a certain common content (created by a certain content originator, and distributed by using the same IP destination address) subscribed by different MNs associated with distinct LMAs, it makes sense to distribute only once for all those MNs independently of the LMA which they are associated to, instead of doing it in parallel multiple times. Such unique distribution should use an entity common to all of them, the so called MTMA (or the H-LMA). > The previous discussion was referring to the business model: If the multicast head-end were an LMA for some MN from provider X, it would be indeed questionable why this LMA should serve other MNs from provider Y that have no association with it. However, since I understand your head-end not to act as an LMA, this argument does not apply. The head-end could be provided by someone (a local operator, some dedicated multicast service provider, ...) independent of the home association of MNs. Anyhow, I guess Behcet is right: in the previous discussion, we have been mixing considerations of two drafts by accident. The majority of the exchanged arguments do not apply to draft-zuniga-multimob-pmipv6-ropt (except for avoiding the pitfalls in deploying PIM as mentioned above). So we should keep things separate. Best wishes, 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 prvs=3376ce49e=schmidt@informatik.haw-hamburg.de Thu Dec 29 12:23:26 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 C639821F8AF0 for ; Thu, 29 Dec 2011 12:23:26 -0800 (PST) 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 Y1hFyVx1Jkbw for ; Thu, 29 Dec 2011 12:23:26 -0800 (PST) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0521F8AE9 for ; Thu, 29 Dec 2011 12:23:24 -0800 (PST) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 29 Dec 2011 21:23:23 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id BE397104CDF4; Thu, 29 Dec 2011 21:23:23 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32372-05; Thu, 29 Dec 2011 21:23:23 +0100 (CET) Received: from [192.168.178.36] (g231111188.adsl.alicedsl.de [92.231.111.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id E4324104CDE8; Thu, 29 Dec 2011 21:23:22 +0100 (CET) Message-ID: <4EFCCC40.7040303@informatik.haw-hamburg.de> Date: Thu, 29 Dec 2011 21:23:28 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Rahman, Akbar" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] WG adoption call ondraft-schmidt-multimob-pmipv6-source-00 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, 29 Dec 2011 20:23:26 -0000 Hi Akbar, sorry for answering late - please see inline. On 11.12.2011 21:35, Rahman, Akbar wrote: > Hi Bechet/Thomas, > > > I support adopting draft-schmidt-multimob-pmipv6-source-00 as a WG draft. > > I also have the following comments which I think can be addressed in the next update once it becomes a WG draft: > > > 1) Editorial - 2nd paragraph of section 1 (Introduction) > - From: "... on the price of possibly ..." > - To: "... at the price of possibly ..." > Thanks - we'll correct. > 2) Section 3 (Base Solution for Source Mobility: Overview), 2nd paragraph > - Is it really a "downstream" link in this perspective or an "upstream" link? Anyways, I know in cellular the direction from the MN to the network is referred to as the "uplink". In the sentence under question, the perspective is from the MAG ("Multicast packets will arrive at the currently active MAG via one of its downstream local (wireless) links.") Being the MAG and following the Internet routing hierarchy, the wireless links towards MNs are downstream, while the tunnels to LMAs go up the routing hierarchy and therefore are coined upstream. > > - Also in the next paragraph (3rd paragraph), you refer to "upstream" ... Maybe this points to the need to really clearly define upstream/downstream directions in this I-D. > This follows the same picture - terminology is also consistent with the MLD/IGMP proxy notion. But we can add a remark in Section 2 on up-/downstream directions. > > 3) Figure 1 > - The bottom half of the Figure containing the "Multicast Senders and Listeners" is very busy and hard to decipher. I suggest cleaning up this part of the figure as it took me a few reads of the associated text to understand it. > O.K. - we can try to make this easier. > > 4) Section 3 > - There is a reference of an MN "using its source address with Home Network Prefix (HNP)". Can you explain to me how this works for a 3GPP cellular network? My understanding in 3GPP is that the GGSN assigns a dynamic IP address which is seen by anyone communicating with the MN in the Internet. So is this GGSN assigned address the HNP you are referring to (i.e. the GGSN address would be the multicast source address)? Or is this GGSN address different from the PMIP HNP you are referring to? > Well, this is somehow a confusing question. 3GPP does not use PMIPv6 and I guess you refer to IPv4. Anyhow, the MN uses the (permanent) source address (with HNP) that is assigned to it. The point here is that no special address selection mechanism is applied here. This would be the same in 3GPP, while the 3GPP MBMS works differently. Thanks again! We are currently working on an update of the draft and will include your comments. Best wishes, Thomas > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Monday, December 05, 2011 5:02 PM > To: multimob@ietf.org > Subject: [multimob] WG adoption call ondraft-schmidt-multimob-pmipv6-source-00 > > Hello all, > There was consensus on the source mobility solution draft in Taipei. > This mail is to confirm the consensus. > > > This document can be found at: > http://tools.ietf.org/id/draft-schmidt-multimob-pmipv6-source-00.txt > > This mail starts a WG adoption call on this draft. > > The intended status for this document is proposed standard. > If adopted, the draft will be named: > > draft-ietf-multimob-pmipv6-source-mobility. > > Please your comments by December 12, 2011. > > > Chairs > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- 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 °