RE: [nemo] About Test Specification in IPv6 Ready Logo

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> Mon, 27 November 2006 12:30 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gofca-0008RY-Hx; Mon, 27 Nov 2006 07:30:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GofcZ-0008Pm-G8 for nemo@ietf.org; Mon, 27 Nov 2006 07:30:03 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GofcW-0004OA-N9 for nemo@ietf.org; Mon, 27 Nov 2006 07:30:03 -0500
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2006 13:29:58 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kARCTvc2004922; Mon, 27 Nov 2006 13:29:57 +0100
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kARCTuwv002116; Mon, 27 Nov 2006 13:29:56 +0100 (MET)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 13:29:55 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nemo] About Test Specification in IPv6 Ready Logo
Date: Mon, 27 Nov 2006 13:29:50 +0100
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC031ABD8B@xmb-ams-337.emea.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nemo] About Test Specification in IPv6 Ready Logo
Thread-Index: AccSHFWzluY5jIsRRYG4UQ4pnofz3gAAHuFA
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "K.Kawaguchi" <kawaguti@ysknet.co.jp>, keiichi@iijlab.net, nemo@ietf.org
X-OriginalArrivalTime: 27 Nov 2006 12:29:55.0723 (UTC) FILETIME=[BEC535B0:01C7121F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6725; t=1164630597; x=1165494597; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20<pthubert@cisco.com> |Subject:=20RE=3A=20[nemo]=20About=20Test=20Specification=20in=20IPv6=20R eady=20Logo |Sender:=20; bh=rITzlUgRUrQp3sOrwCKlS8i/vIYRIofsE9gdDWdj37g=; b=WZVUCCrjqi6aWYo3BsfYIwQW3B7HHE2Xl366m53j5ATTw0FRfj8gZ9HoZVE5WGI/gTsvYLmn GrD1NNED7mgFvacfUfa6b1Jzeu3cu5HtNSGMcaqd4Tkcu35zp+7vK52x;
Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221
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

>> 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.

>
>
>>
>> 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.

>
>>
>>
>> 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?

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
>>
>>