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

jouni korhonen <> Mon, 26 November 2012 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFAEE21F8558 for <>; Mon, 26 Nov 2012 04:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8EPVw1seoLXb for <>; Mon, 26 Nov 2012 04:48:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1A7F921F8550 for <>; Mon, 26 Nov 2012 04:48:45 -0800 (PST)
Received: by with SMTP id hm6so2770016wib.13 for <>; Mon, 26 Nov 2012 04:48:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=im/KymC0ujNr9poVYbemYhLokTesMIx8TPvMOUSWEkk=; b=hb2L7VVsQMrz4RS3ygqLz0LFIxaNOxFHRuuZVuKUGEHqAjjpwz47RYhz8L+iCj5xM6 3g4o+JjN6s4q0jxlkBFuFbEgBhRBeJinlxgLqv+zpQQnMGY7Jpn6x6FxpF3GO9X9jBQ9 EFb9RdmQRohuBbTFfOMySIU3OvCmpFZnYN07ULhDIsaZmRnPr5sSC4z447GTpDLpuD5q 3AfT5hsu0UVZuk8Mkv1AKCjVgvdSvtQhuoQhQ8pMndNCHp0cKelygctEedQvchvsPx5s aeLllrO/x46eURuRgdWprvLYPb6V3jnOG7SYErMR0Rgt4Xl26R9Oxddr0OEYAkfMYTAq qmUw==
Received: by with SMTP id s12mr17391720wiv.12.1353934125133; Mon, 26 Nov 2012 04:48:45 -0800 (PST)
Received: from [] ([]) by with ESMTPS id i6sm20971681wix.5.2012. (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 04:48:44 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <>
In-Reply-To: <>
Date: Mon, 26 Nov 2012 14:48:39 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Peter McCann <>
X-Mailer: Apple Mail (2.1085)
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: Mon, 26 Nov 2012 12:48:55 -0000


On Nov 26, 2012, at 10:57 AM, Peter McCann wrote:

> Hi, Jouni,
> jouni korhonen wrote:
>> Pete,
>> I hope we start getting closer to convergence.. this thread is getting
>> longish..
> Yes and sorry about the delay responding.  We had the Thanksgiving 
> holiday here in the US and I was out of touch.
>> On Nov 21, 2012, at 6:34 PM, Peter McCann wrote:
>>> Hi, Jouni,
>>> jouni korhonen wrote:
>>>>> 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.
>>>> It is what RFC3315 says.. client sends a confirm request.
>>> Right, I am just pointing out that the link may flap even when the same
>>> LMA is reachable.  Seems like overhead.  You seem to be requiring that
>>> the link doesn't flap when the PMIP session continues after a MAG to
>>> MAG handover under the same LMA.
>> I would say it it does not flap. The MR (at will) will still see it as a
>> change of access point or something equivalent at the L2. If that event
>> then gets delivered to the IP level somehow is out of my control. I have
>> no control how the DHCPv6-PD client gets implemented in the MR or
>> whether the network driver delivers proper events to upper layers.
>> This is getting to the original reason why we wrote the draft. Depending
>> on how the MR figures out "whether the link changed" it may or may not
>> bother sending the Confirm Request. And if it does not, then the MAG
>> does not know about the delegated prefixes -> forwarding fails. On the
>> network side I cannot really trust the MR DHCPv6-PD client to do the
>> right thing all the time.
> Ok, so can we summarize the recommendation for PMIP deployments:
> (1) When handing off between two MAGs under the same LMA, the change of
> link SHOULD NOT be propagated to the IP stack (the link flap should
> not be visible to IP).

Should not is OKish. Cannot guarantee that though.

> (2) When handing off between two MAGs where the second MAG cannot or
> does not connect back to the previous LMA, the change of link MUST be
> propagated up the IP stack.


> I think that (1) is a SHOULD NOT because violation of this SHOULD NOT
> only leads to some extra traffic on the link from re-confirmation.  In
> contrast, (2) is a MUST because the absence of a link down/up event
> could lead to a hung session where the MN thinks it has a routable
> prefix but actually does not.
> Have either of these two requirements been codified in 5213 or 
> elsewhere?

RFC5213 is prepared to handle 1) independent whether the event is
sent or not, ref the DNA text and link-local address MO.

>>>> The LMA-LMA hanover, as per current RFC5213, would be visible as a
>>>> link flap or L2 session termination whatever. At least on those L2
>>>> technologies that I am aware of.
>>> In my view, a MAG to MAG handover under the same LMA is equally likely
>>> to lead to a link flap.  Which really does no harm, it only leads to
>>> extra DHCP or RS/RA reconfirmation traffic in this case.
>> LMA-LMA handover based on the existing specs means the end of PMIP
>> session, which on the point-to-point link technologies I am aware of
>> also results in the termination of the L2 session. We have not defined
>> how renumbering would work in this case. In certain L2 technologies
>> renumbering is not even supported (ref 3GPP).
> Are you aware of a deployment of PMIP over the 3GPP PDP context link?
> I am not.  The existing GPRS model is that the GGSN or PGW is the first

I am. This is not an academic exercise.

> hop router, and traffic is always tunneled directly back to that router.
> In contrast, PMIP has the MAG as the first hop router.  This is a 
> fundamental difference that IMHO makes it more likely to see a link
> flap on a MAG to MAG handover, even when the same LMA is reachable from
> both.

If the LMA stays the same, the link does not flap. One might receive
an event that the access point (or equivalent) changed. This again
depends on the client side implementation.

> I think you agree with me that a change of MAG that results in a change
> of LMA should always result in a link down/up event that is visible to
> the IP stack.

I repeat what I said earlier. If the LMA changes the L2 session goes down,
prefixes may change etc. It is a bit more than just link up/down because
it also involves setting up a new PMIP session & L2 session. (on L2
technologies I am concerned with).

>>> Yes, that might help, but it seems to run counter to the recommendation
>>> in RFC 6543.  Also, I am not so sure that it will be possible to
>>> define
>> I know and again back to the context of my assertion:
>> "..(possible by specs but a hack in a way, thus not elaborated in this
>> I-D)."
>> And that "specs" dates to original RC5213 which would allow us this.
>> Even when using RFC6543 I can turn it off by configuration.
> Agreed, it's possible.
>>> clean boundaries a priori where different link local addresses would
>>> be assigned.  There may be some overlap in the LMA coverage areas
>>> (although
>> Assuming RFC6543 is not used and we do assign different link-locals,
>> then it is up to the LMA decide when to use which link-local. Two
>> examples: each LMA has its own or each PMIP session gets its own
>> "unique" link-local. Both cases have possibility of address collisions
>> but are quite unlikely. I do not really care about coverage areas rather
>> the case when something happened on the emulated home link and for that
>> case the two examples would be sufficient. Note that I am not prompting
>> such "solution".
> Did you mean to say "up to the MAG"?  I am not sure I like the idea of
> the LMA controlling the MAG's link-local address.

No.. or lets say my wording was imprecise. Whether this feature is enabled
depends on the MAG configuration. If MAG allows the LMA to generate the
link-local, then LMA does it and MAG uses that address. In that case the
LMA decides when to use which link-local address.

>>> You may be running a server on the MN which is waiting for inbound
>>> connections.  The peer correspondent nodes would send traffic to the
>>> old prefix, and there would be no indication to the MN that the old
>>> prefix isn't valid anymore.
>> As said we cannot heal all networking issues by specifications if people
>> do not implement them properly. If your delegated prefix is gone from
>> the network point of view and your MR sits there doing nothing while it
>> should based on e.g. RFC3315, tough luck.
> If the link down/up event has been hidden from the IP stack, then sitting
> there doing nothing is exactly what an RFC3315 compliant implementation
> would do.  Hence my use of MUST in (2) above.

Sure. Never claimed it to be different. But as said, I cannot control the
client side implementation. That is the point.

- Jouni

> -Pete