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

Peter McCann <> Tue, 20 November 2012 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0578421F87EA for <>; Tue, 20 Nov 2012 13:46:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JDqkneSrhc7x for <>; Tue, 20 Nov 2012 13:46:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7EBA821F87DC for <>; Tue, 20 Nov 2012 13:46:39 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id AMZ34732; Tue, 20 Nov 2012 21:46:38 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 21:46:10 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 21:46:37 +0000
Received: from ([]) by ([]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 13:46:32 -0800
From: Peter McCann <>
To: jouni korhonen <>
Thread-Topic: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
Thread-Index: AQHNxz3DQQQBC3W/sU+JRgVtIyAvCpfy7olggAC+hYD//3xY0IAAjCcA//97uoCAAJVJgP//ejdQ
Date: Tue, 20 Nov 2012 21:46:31 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "" <>, Basavaraj Patil <>, "" <>
Subject: Re: [netext] Chair review of I-D: draft-ietf-netext-pd-pmip (05)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Nov 2012 21:46:41 -0000

Hi, Jouni,

jouni korhonen wrote:
> Pete,
> On Nov 20, 2012, at 11:02 PM, Peter McCann wrote:
>> 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.
> If the PMIP session goes down and the LMA changes then the HNP also
> changes. For the MR that is an indication that something happened on
> the link -> confirm. 

The only way to communicate the new HNP is with an RA, correct?

> If that is not a good enough indication I would
> assume the MR gets link up/down even since the end of PMIP session
> would also mean the MAG kicks the MR out of the L2 session.

I don't see why this handover should be any different at L2 from
the handovers within a single PMIP domain.  I think the MN would
get link down/up (or not) in both cases, and would not be able to
distinguish the end of the session on this basis.

> If the link is some wireless technology e.g. a cellular link, then a
> PMIP session change would equal more drastic stuff on the MAG facing
> interface/link. The MR would definitely know the link changed or
> something happened to it -> confirm.

It is an inter-MAG handover like any other.  Indistinguishable at

> To be sure the MR sees the change of link, each PMIP session could
> have their unique MAG link-local (possible by specs but a hack in a
> way, thus not elaborated in this I-D).

Even so the receipt of a new RA from a new link-local address would
not invalidate the old information received from the old MAG.  This
is not a trigger that deprecates the old prefix.  An MN conforming
to 4861 would not necessarily take any action upon receiving the new

> Even RFC3315 is rather vague how the client figures out the link
> changed. It is just assumed it somehow gets some indication something
> happened.

I don't think we can assume that inter-MAG handoffs involving a change
of LMA are at all distinguishable at the link layer from inter-MAG
handoffs that do not involve a change of LMA.


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