Re: [nemo] About Test Specification in IPv6 Ready Logo
"K.Kawaguchi" <kawaguti@ysknet.co.jp> Tue, 28 November 2006 02:17 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosXF-0004er-AZ; Mon, 27 Nov 2006 21:17:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosXE-0004em-0d for nemo@ietf.org; Mon, 27 Nov 2006 21:17:24 -0500
Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GosXD-0003tB-0z for nemo@ietf.org; Mon, 27 Nov 2006 21:17:23 -0500
Received: (qmail 30073 invoked from network); 28 Nov 2006 11:17:10 +0900
Received: from (HELO MIP6-236) (@) by with SMTP; 28 Nov 2006 11:17:10 +0900
To: pthubert@cisco.com, keiichi@iijlab.net, nemo@ietf.org
Subject: Re: [nemo] About Test Specification in IPv6 Ready Logo
From: "K.Kawaguchi" <kawaguti@ysknet.co.jp>
References: <7892795E1A87F04CADFCCF41FADD00FC031ABD8B@xmb-ams-337.emea.cisco.com>
In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC031ABD8B@xmb-ams-337.emea.cisco.com>
Message-Id: <200611281117.EAG12997.VHBLUBJX@ysknet.co.jp>
X-Mailer: Winbiff [Version 2.43 PL1]
X-Accept-Language: ja,en
Date: Tue, 28 Nov 2006 11:17:10 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c
Cc:
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Errors-To: nemo-bounces@ietf.org
Hi, ""Pascal Thubert (pthubert)" <pthubert@cisco.com>" wrote: > >> Your example is an extended Home Network case, and you have used a > Home > >> Address from the prefix on the Home Link. In that case, the HA > expects > >> that the MR is at Home when there is not binding, and it will deliver > >> over the Home Link the packets routed via MR's HoA A:B:C:0::i. > > > >My example is an extended Home Network case. But, Home Address from > >Mobile Network Prefix (5.3 Home Address from MNP in > draft-ietf-nemo-home > >-network-models-06). > > [Pascal] OK. That was not obvious from the picture since you did not > provide the HoA :) > > As a reminder, we do not recommend the configuration that you are > proposing. > " > There are a number of issues with returning home when a mobile router > configures its home address from the MNP as described in Section 5.3. > Therefore we do not recommend this mechanism if the mobile routers > attach to the home network. > " > > If you still want to, you might for instance configure statically a > connected route to the Home aggregation via the Home Link. At this point > you are more or less back to the aggregated mode. But then again, why > would you do that? Extended mode is meant to take the Home address from > the /64 on the Home Link, thus my assumption on A:B:C:0::i. OK. I find this method (Extend mode and Home address from MNP) not having any advantage. > > > > > > >> > >> As Keiichi says there are 2 case. > >> > >> Implicit: > >> > >> HA knows A:B:C:i::/64 via A:B:C:0::i; if this is a static information > >> (static or automatic route) then the HA keeps that route regardless > of > >> whether the MR is bound. The HA can share that information with other > >> GWs on the Home Link using an IGP over the Home Link, but to keep it > >> simple just assume that the HA is also the default GW in the Home > Link. > >> > >> So if MR1 is at Home, the HA can still reach any LFN behind it > because > >> it has a static information for the route A:B:C:i::/64 via A:B:C:0::i > >> and it expects A:B:C:0::i over the Home Link. If another MR at home > >> needs to reach the LFN, packets will first reach the HA (default GW), > >> and the HA will issue an ICMP redirect. MRs could also expose their > >> prefix on the Home Link using RFC 4191 to save that flow. > >> > >> So MRs do not need to participate to the IGP on the Home Link, and > that > >> can be a benefit in a very large or very dynamic Home configuration > > > >I understand this case (thanks you). > > > >On the other hand, in the case Home Address from MNP. > >Does MR need to join in IGP after configuring the address at the home? > > [Pascal] As I said, you can use a static route to the Home aggregation > over the Home interface. One more static route... Obviously you could > mix and match static and dynamic routing, but if you are already using > static routes, I'd go for one more static. But then again, I would not > use HoA from MNP in extended mode if MRs need to go back home. I understand. > > > > >> > >> > >> Explicit: > >> > >> The route in the HA is associated to the binding. When the MR comes > back > >> Home, the route is lost and the MR needs to participate to whatever > IGP > >> is run at Home. The choice of the IGP is a configuration issue, it > can > >> be any of the usual suspects (OSPF, RIP, EIGRP, ISIS, you name it). > It > >> could even be a MANET :) The choice of the IGP and how you deploy it > >> will impact the capability for your Home Network to handle/survive a > >> more or less high rate of changes (routers in/out) > >> > >> What NEMO adds: NEMO requires that the MR presents itself as a router > >> and participates to the IGP only if it is at Home. So either you have > a > >> dedicated interface for going Home or you have some dynamics in the > >> behavior of the roaming interface(s) that can reach Home to switch > >> between at-Home and Roaming profiles. > > > >Ok, I understand. > >This is the same also in the case from MNP, isn't it? > > [Pascal] Yes... if I understand you well. More words to make sure: > > The MR at Home autoconfigures a Link Local Address for the Home Link, > and exposes the MNP route with the IGP using that LLA. This happens > regardless of whether the HoA was derived from the prefix on the Home > Link or from the MNP. In all cases, the HA obtains a route towards the > MNP via the MR LLA. > > Makes sense? OK, I understand. Hearty thanks for your e-mails. Best regards --- Kiyoaki KAWAGUCHI > > Pascal > > > > >Best regards > >--- > >Kiyoaki KAWAGUCHI > > > > > > > >> > >> It can be expected that routing within a nested NEMO (MANEMO) will > >> somewhat alleviate that restriction. > >> > >> Pascal > >> > >> >-----Original Message----- > >> >From: K.Kawaguchi [mailto:kawaguti@ysknet.co.jp] > >> >Sent: Monday, November 27, 2006 2:49 AM > >> >To: keiichi@iijlab.net; nemo@ietf.org > >> >Subject: Re: [nemo] About Test Specification in IPv6 Ready Logo > >> > > >> >Hi, > >> > > >> >"Keiichi SHIMA <keiichi@iijlab.net>" wrote: > >> >> On 2006/11/25, at 13:29, Keiichi SHIMA wrote: > >> >> > >> >> >>> So, even in > >> >> >>> the case 2, we can put a routing entry for the mobile network > >> prefix > >> >> >>> by not using any routing protocol. > >> >> >> > >> >> >> Please teach the method of not using routing protocol. > >> >> >> Is there draft or RFC ? > >> >> > > >> >> > Since a mobile node knows its mobile network prefix, it can > install > >> >> > a routing entry for it after it receives a binding ack message. > >> >> > The home agent of the mobile node will know the mobile network > >> >> > prefix stored in a binding update message from the mobile node, > it > >> >> > can also install a routing entry when it receives the binding > >> >> > update message. > >> >> > >> >> Some more minor additional notes... > >> >> > >> >> The above example is for the explicit mode. And if we use > implicit > >> >> mode, then these two entities already know what to do when > >> >> registration completes. So either using a dynamic routing or not > is > >> >> just a configuration issue for route management and it has nothing > to > >> >> do with the network model. > >> >> > >> >> # if I'm not missing something. > >> > > >> >I still have my uncertain point. > >> >Please look at the following figures. > >> > > >> > | > >> > HA1 > >> > | > >> > -----+-----+-----+-----+----- Home Link: A:B:C:0::/64 > >> > | | | > >> > | | | MR1-egress > >> > H R(MR) MR1 > >> > | | MR1-ingress (Home Address) > >> > | > >> > -+----- Mobile Network: A:B:C:i::/64 > >> > > >> > > >> >I agree as you say, HA and MR can install own routing table entry by > >> >binding message. However, how do you tell it to other nodes on home > >> >network? > >> >How do you do when MR1 moves from the home link and the binding > message > >> >is completed? Also, how do you do when MR1 returns to the home link? > >> > > >> > > >> >Best regards > >> >--- > >> >Kiyoaki KAWAGUCHI > >> > >> > >
- [nemo] About Test Specification in IPv6 Ready Logo K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Greg Woodhouse
- Re: [nemo] About Test Specification in IPv6 Ready… Thierry Ernst
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Vijay Devarapalli
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Keiichi SHIMA
- Re: [nemo] About Test Specification in IPv6 Ready… Thierry Ernst
- Re: [nemo] About Test Specification in IPv6 Ready… Vijay Devarapalli
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… T.J. Kniveton
- Re: [nemo] About Test Specification in IPv6 Ready… RYUJI WAKIKAWA
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Romain KUNTZ
- Re: [nemo] About Test Specification in IPv6 Ready… Sri Gundavelli
- Re: [nemo] About Test Specification in IPv6 Ready… Romain KUNTZ
- Re: [nemo] About Test Specification in IPv6 Ready… Sri Gundavelli
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- RE: [nemo] About Test Specification in IPv6 Ready… Pascal Thubert (pthubert)
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Keiichi SHIMA
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Keiichi SHIMA
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Keiichi SHIMA
- Re: [nemo] About Test Specification in IPv6 Ready… Keiichi SHIMA
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- RE: [nemo] About Test Specification in IPv6 Ready… Pascal Thubert (pthubert)
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- RE: [nemo] About Test Specification in IPv6 Ready… Pascal Thubert (pthubert)
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu
- RE: [nemo] About Test Specification in IPv6 Ready… Pascal Thubert (pthubert)
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… Keiichi SHIMA
- Re: [nemo] About Test Specification in IPv6 Ready… Keiichi SHIMA
- Re: [nemo] About Test Specification in IPv6 Ready… K.Kawaguchi
- Re: [nemo] About Test Specification in IPv6 Ready… RYUJI WAKIKAWA
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu
- Re: [nemo] About Test Specification in IPv6 Ready… RYUJI WAKIKAWA
- Re: [nemo] About Test Specification in IPv6 Ready… Alexandru Petrescu