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

Alexandru Petrescu <alexandru.petrescu@motorola.com> Fri, 10 February 2006 17:36 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 1F7cCH-0003pM-R7; Fri, 10 Feb 2006 12:36:41 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7cCE-0003p3-3J for nemo@megatron.ietf.org; Fri, 10 Feb 2006 12:36:40 -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 MAA11171 for <nemo@ietf.org>; Fri, 10 Feb 2006 12:34:44 -0500 (EST)
Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7cP4-0001VF-Ph for nemo@ietf.org; Fri, 10 Feb 2006 12:49:57 -0500
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1AHotw0003475; Fri, 10 Feb 2006 10:50:55 -0700 (MST)
Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k1AHoViX029893; Fri, 10 Feb 2006 11:50:31 -0600 (CST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A0246865980; Fri, 10 Feb 2006 18:36:06 +0100 (CET)
Message-ID: <43ECCF05.70404@motorola.com>
Date: Fri, 10 Feb 2006 18:36:05 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Pascal Thubert \\(pthubert\\)" <pthubert@cisco.com>
Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05
References: <7892795E1A87F04CADFCCF41FADD00FC01CDCC3B@xmb-ams-337.emea.cisco.com>
In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01CDCC3B@xmb-ams-337.emea.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: 7bit
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

Pascal Thubert \(pthubert\) wrote:
>>>> This above paragraph makes no particular sense at all, since a
>>>> HA doing proxy ND for a LFN node which is below MR will
>>>> intercept packets from all the neighbours of HA addressed to
>>>> LFN, even though it is the MR who should intercept or receive
>>>> those packets.
>>>> 
>>>> There can be no "proxy ND" for an LFN on HA's link as long as
>>>> the normal ND of same LFN is not happening on the home link.
>>> 
>>> [Pascal] Please read again. The "Nodes on the registered
>>> prefixes" means nodes  (eg. LFNs) attached to MRs that are away
>>> from home. Thus MRs can not intercept the packets to the LFN over
>>> the Home Link.
>> 
>> For some reason "intercept" was perceived by you as something where
>> MR must do proxy ND in order to receive.  I didn't mean so, sorry.
>> I
> meant
>> MR should "receive" (or "intercept") packets for LFNs when away
>> from home.  This happens by MR receiving packets tunnelled by HA.
>> The HA
> has
>> "intercepted" those packets for LFNs by doing proxy ND for MR's
>> Home Address exclusively, and not by doing proxy ND for any LFN
>> address.  It makes no sense for HA to do proxy ND for LFN address.
>> 
>> Again, HA doing proxy ND for LFNs is something topologically
>> invalid. Proxy ND of a host should be done on a link where the real
>> ND for that host is topologically valid.
> 
> [Pascal] Are we off-sync? This chapter talks about the aggregated
> mode, so the whole /48 is topologically correct on the Home Link.
> That's section 6 of: 
> http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod
>  els-xx.txt

Thanks for pointing me to the section 6 about the aggregated mode.  The
entire section of aggregated mode makes no sense in implementation and
it is not recommended for implementation.

One thing that is not mentioned in the draft is that it's impossible for
MR to become a "bridge" and at the same time forbid the LFNs to receive
RAs from the AR, thus LFNs to configure themselves CoAs.

The entire configuration where MR is a bridge is entirely out of scope
for implementations of RFC3963 MR.

> The /48 is what the HA advertises in RA's on the Home Link. All nodes
> on the link think that the whole /48 is on that link. So they will
> have a connected route to the /48 over the home link, and lookup any
> node in the /48 at ND level.

Ok.

> But in fact, (some of) the /48 space is partionned into MNPs affected
> to MRs. Thus the problem. Note: Personally, I do not favor the
> aggregated model, I prefer the extended. We discussed that long ago,
> remember?

Yes I remember.  Who favors the Aggregated Model?  Who recommends the
Aggregated Model?  We would expect it to be the draft authors.  You
don't seem so.  Does Ryuji?  Does Vijay?

>> 
>> Moreover, there are potentially 2^64 LFNs behind an MR with MNP
>> /64.
> HA
>> has no means to know which of those are active.  So will it send
>> 2^64 periodic NAs as part of its proxy ND for LFNs?
> 
> [Pascal] No, it will answer to NS coming from the Home Link for any 
> address that matches a registered MNP, and then pass the packets over
>  the tunnel.

NS is addressed to a multicast group.  In order for HA to receive that
NS it should MLD JOIN it first, otherwise it doesn't receive it.  HA
would need to send as many MLD JOINs as there are potential LFNs behind
MR.  That's large, right?

>> Pascal:
>>> Thus, on the Home Link, the Home Agent must intercept all the
>>> packets for ALL the Mobile Network Nodes on the registered
>>> prefixes - that is for ALL nodes attached to Mobile Routers that
>>> are away from Home. This should be a layer 2 operation, rather
>>> than layer 3.  The Home agent might, for example,  perform some
>>> form of ND proxying for all addresses in all registered Mobile
>>> Network Prefixes.  The Home Agent must also protect the MNP space
>>> from autoconfiguration by uncontrolled visitors at Neighbor
>>> Discovery level.
>> 
>> Is there a known implementation where the HA intercepts all the
>> packets for ALL the Mobile Network Nodes by doing proxy ND for
>> their addresses?
>> 
>> Does anyone plan to write such an implementation?
>> 
> [Pascal] Dunno. Don't ask me if I like it... But something like that
> has to be done if MNs or hosts connect to the home link... Part of
> the price to pay to support aggregated mode.

I am not sure the aggregated mode is needed in order to allow the MNNs
to connect to MR's home link.  It is sufficient to have an HA on the
_MNN_ home link and when MNN connects to MR's home link it would send BU
to its own HA.

Alex