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

Peter McCann <> Wed, 21 November 2012 04:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5ED7421F86C4 for <>; Tue, 20 Nov 2012 20:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.555
X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QqaEqhpw15HP for <>; Tue, 20 Nov 2012 20:56:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0DE8121F8692 for <>; Tue, 20 Nov 2012 20:55:53 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id ALT35801; Wed, 21 Nov 2012 04:55:52 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 04:55:22 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 04:55:50 +0000
Received: from ([]) by ([]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 20:55:43 -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//ejdQABOHHoAABSeKoA==
Date: Wed, 21 Nov 2012 04:55:43 +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: Wed, 21 Nov 2012 04:56:02 -0000

Hi, Jouni,

jouni korhonen wrote:
> Pete,
> On Nov 20, 2012, at 11:46 PM, Peter McCann wrote:
>> 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?
> No. Also DHCP applies. If your assumption about MN/MR not being able
> to figure out when to confirm its address/prefix, then whole RFC5213
> DHCP- based address assignment would be broken.

I guess if you sent a DHCP Renew every time you detected a link flap
(handover to new MAG) that would do the trick.  It seems somewhat
expensive, though.

>>> 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.
> You were talking about the change of LMA.. which would per current
> specs mean end of PMIP session. Now if PMIP session ends the MN/MR
> won't  be let hanging around in L2 either, right? So the MN/MR would
> definitely know that it got kicked away. Think e.g. about cellular
> case. The lost of session means the link is plain gone.

It's perfectly conceivable to have an L2 handover to a new MAG in a 
new PMIP domain.  I don't see why the L2 should be modified to know
about the topology of which MAGs can reach which LMAs.

>>> 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 L2.
> It is way different than an inter-MAG handover. See above.

Why would the L2 know about the MAG-to-LMA topology?
>>> 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 RA.
> DNA.

Ok, but if all the MAGs are using the same link-local address, NUD
would come back saying the router is still reachable, right?  Would
the MN/MR invalidate or try to reconfirm the old information in this

>>> 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.
> I disagree. You would know it at your L2. And even if you wouldn't
> have such L2, your MAG or latest LMA should send you a destination
> unreachable ICMP telling the packets (having src out of delegated
> prefix) won't get delivered. If not.. then the deployment is broken
> and we cannot fix that part with a spec.

ICMP would only be sent if traffic is being generated.  I am more worried
about a state where the MN thinks its prefix is still good, but packets
aren't being delivered and it could be an indeterminate amount of time
before the situation is recognized/corrected.


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