RE: [nemo] RE: draft-ietf-nemo-home-network-models-05

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> Wed, 15 February 2006 08:53 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9IPv-0006W2-Ib; Wed, 15 Feb 2006 03:53:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9IPt-0006Vx-Cn for nemo@megatron.ietf.org; Wed, 15 Feb 2006 03:53:41 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21157 for <nemo@ietf.org>; Wed, 15 Feb 2006 03:51:53 -0500 (EST)
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Idr-0000r6-NW for nemo@ietf.org; Wed, 15 Feb 2006 04:08:09 -0500
Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2006 09:53:30 +0100
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1F8rB5w013335; Wed, 15 Feb 2006 09:53:27 +0100 (MET)
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Feb 2006 09:53:19 +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] RE: draft-ietf-nemo-home-network-models-05
Date: Wed, 15 Feb 2006 09:53:14 +0100
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01D29986@xmb-ams-337.emea.cisco.com>
Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05
Thread-Index: AcYv+/HAKE1aH4taSSyuhNC9/w6PRgAuVNsQACcTWeAABgrM8AAFYPigACMiEyA=
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Mattias Pettersson L (LD/EAB)" <mattias.l.pettersson@ericsson.com>, Alexandru Petrescu <alexandru.petrescu@motorola.com>
X-OriginalArrivalTime: 15 Feb 2006 08:53:19.0227 (UTC) FILETIME=[44868CB0:01C6320D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: quoted-printable
Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman <MRW@devicescape.com>, vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp
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>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org


>-----Original Message-----
>From: Mattias Pettersson L (LD/EAB)
[mailto:mattias.l.pettersson@ericsson.com]
>Sent: Tuesday, February 14, 2006 5:09 PM
>To: Pascal Thubert (pthubert); Alexandru Petrescu
>Cc: nemo@ietf.org; tj@kniveton.com; Margaret Wasserman;
vijay.devarapalli@nokia.com;
>ryuji@sfc.wide.ad.jp; ernst@sfc.wide.ad.jp
>Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05
>
>Hi Pascal,
>
>> Yes, the idea is that the prefix is generally shorter than /64.
>>
>> We had long discussions in this ML about autoconfigs with
>> shorter prefixes (Alex?). But yes, NEMO should work in theory
>> with a shorter prefix assigned to the Home Link. Note that
>> NEMO does not require autoconf operations; and last that I
>> know, a Cisco router will not auto-configure an address on a
>> prefix that is shorter than 64.
>
>I'm not sure that ND will work for anything but /64. Maybe the
intention
>was so, but as you say, not all implementations support different
prefix
>lengths.
>
>Still you will need the address resolution parts of ND, even though the
>HA and MRs doesn't autoconfigure addresses on the home link.

[Pascal] That should work. Do you know of an implementation that would
not operate NS/NA correctly on a non /64 network? 

I agree with you that HA and MRs doesn't autoconfigure addresses on the
home link, it's good that you point it out.


>The big issue is the ambiguity of which link/subnet a specific address
>belongs to. For instance, given a packet destined to a specific MNN,
>does the HA know if it should route (via an MR) or send directly to the
>MNN (by using ND address resolution to get the MAC address)?
>
[Pascal] Well, the HA is a still a router. 

For addresses that are part of an MNP, the HA should have an MNP route
via the MR, and route accordingly via the MR, whether it is Home or not.


The longest match in the routing table will be the connected route to
the aggregated home network only for addresses that:
- are not in an MNP => then look up at ND level is what you want to do
- are in an MNP of a MR that is away from home and not registered =>
then ND lookup is still OK and it will fail, that's fine

Again, I do not like it, but it works...

>ND proxy/MLSR according to Thaler extends a /64 subnet across multiple
>links. But the suggested behaviour here is different.
>
[Pascal] Nope. It's the same thing: HA is doing proxy for individual
/64s that are identified as such because they are associated with a MR
binding.


Pascal