Re: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)

Peter McCann <Peter.McCann@huawei.com> Tue, 20 November 2012 21:04 UTC

Return-Path: <Peter.McCann@huawei.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E77D21F84FC for <netext@ietfa.amsl.com>; Tue, 20 Nov 2012 13:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.542
X-Spam-Level:
X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv6Vs0iHKKg1 for <netext@ietfa.amsl.com>; Tue, 20 Nov 2012 13:04:12 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D02F21F84E6 for <netext@ietf.org>; Tue, 20 Nov 2012 13:04:11 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALT12845; Tue, 20 Nov 2012 21:02:37 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 21:02:07 +0000
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 21:02:36 +0000
Received: from dfweml512-mbx.china.huawei.com ([169.254.1.159]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 13:02:32 -0800
From: Peter McCann <Peter.McCann@huawei.com>
To: jouni korhonen <jouni.nospam@gmail.com>
Thread-Topic: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
Thread-Index: AQHNxz3DQQQBC3W/sU+JRgVtIyAvCpfy7olggAC+hYD//3xY0IAAjCcA//97uoA=
Date: Tue, 20 Nov 2012 21:02:31 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E5890E@dfweml512-mbx.china.huawei.com>
References: <CAA5F1T1D0q-kN8r9H5PaDAXhqFozZ11FnEQ_4ce3XisFbJT+XQ@mail.gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E587E9@dfweml512-mbx.china.huawei.com> <9892BC94-F495-405F-93E9-90A33DAF8C96@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E588CF@dfweml512-mbx.china.huawei.com> <DF31E9C5-2730-4078-95EA-A2A88A4A0CA5@gmail.com>
In-Reply-To: <DF31E9C5-2730-4078-95EA-A2A88A4A0CA5@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.125.187]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "netext@ietf.org" <netext@ietf.org>, Basavaraj Patil <bpatil1@gmail.com>, "draft-ietf-netext-pd-pmip@tools.ietf.org" <draft-ietf-netext-pd-pmip@tools.ietf.org>
Subject: Re: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2012 21:04:13 -0000

Hi, Jouni,

jouni korhonen wrote:
> 
> Pete,
> 
> On Nov 20, 2012, at 10:18 PM, Peter McCann wrote:
> 
>> Hi, Jouni,
>> 
>> What if the new MAG cannot connect back to the old LMA?  How does
>> the MR find out that its delegated prefix is no longer routable?
> 
> In that case your PMIP session goes down.. and the MR sees it as a
> change of the link. In that case MR does what any DHCP client is
> supposed to do i.e. verify whether its prefixes are still valid on the
> new link using a confirm/reply exchange.

How exactly does the MR detect that the PMIP session has gone down?
The MR sees a MAG with the same globally reserved link-layer and
link-local address.  Is it looking for a Router Advertisement with
a new link prefix?  RFC 4861 specifies that subsequent Router 
Advertisements do not invalidate previously received information.

Besides, as we have noted, the RAs have nothing to do with the
delegated prefix so it seems wrong to use them to control the
validity of the delegated prefix.

-Pete

> 
> - JOuni
> 
>> 
>> -Pete
>> 
>> 
>> jouni korhonen wrote:
>>> 
>>> Pete,
>>> 
>>> On Nov 20, 2012, at 6:50 PM, Peter McCann wrote:
>>> 
>>>> Basavaraj Patil wrote:
>>>>> 
>>>>> 5. How does the MAG know that it needs to allow forwarding of
>>>>> packets via the PMIP6 tunnel for packets with SRC address that
>>>>> are derived from the delegated prefixes? Its not clear if there
>>>>> is added functionality needed at the MAG to accomplish this.
>>>> 
>>>> I think there are potentially some deeper issues here.
>>>> 
>>>> The MN sees the original MAG as its "delegating router".  When the
>>>> MN changes to a new MAG, there is no good way to tell that the
>>>> delegated prefixes are still routable to the link.  The delegating
>>> 
>>> This is what the I-D is about.. That's we got the new signaling in
>>> place and the handover case described in Section 3.4.3.
>>> 
>>>> router has become unreachable.  The new router may send an RA that
>>>> advertises the original link prefix, and so the MN can tell that its
>>>> SLAAC unicast addresses are still valid on the link.  However,
>>> 
>>> When the MR (i.e. in RFC5213 terminology the MN) does a handover, the
>>> prefix used between the MR-MAG stays the same as usually provided by
>>> PMIP6. Section 3.4.3 the describes what the MAG has to do in order to
>>> know the existing delegated prefixes and set the forwarding state.
>>> 
>>>> RFC 3633 says that the delegated prefix is NOT advertised on the
>>>> link between the delegating router and the requesting router.
>>> 
>>> And they are not. The delegated prefixes are used on the downstream
>>> interfaces of the MR, not on the MR-MAG link. If the prefix used on
>>> the MR-MAG link is part of the delegated prefix, then the MR has to
>>> use RFC6603.
>>> 
>>>> Therefore, there is no way for the MR to determine whether it can
>>>> still use the delegated prefixes, other than perhaps re-running
>>>> DHCPv6-PD on the new link.
>>> 
>>> From MR point of view nothing changed. So what is the issue?
>>> 
>>> - Jouni
>>> 
>>> 
>>>> 
>>>> -Pete
>>>> 
>>>> 
>>>> _______________________________________________
>>>> netext mailing list
>>>> netext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netext
>> 
>> 
>>