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

jouni korhonen <jouni.nospam@gmail.com> Mon, 26 November 2012 12:48 UTC

Return-Path: <jouni.nospam@gmail.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 AFAEE21F8558 for <netext@ietfa.amsl.com>; Mon, 26 Nov 2012 04:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EPVw1seoLXb for <netext@ietfa.amsl.com>; Mon, 26 Nov 2012 04:48:55 -0800 (PST)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7F921F8550 for <netext@ietf.org>; Mon, 26 Nov 2012 04:48:45 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id hm6so2770016wib.13 for <netext@ietf.org>; Mon, 26 Nov 2012 04:48:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.180.74.108 with SMTP id s12mr17391720wiv.12.1353934125133; Mon, 26 Nov 2012 04:48:45 -0800 (PST)
Received: from [10.255.129.45] ([194.251.119.201]) by mx.google.com with ESMTPS id i6sm20971681wix.5.2012.11.26.04.48.42 (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 <jouni.nospam@gmail.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E65D8B@dfweml512-mbb.china.huawei.com>
Date: Mon, 26 Nov 2012 14:48:39 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <60EF112E-92B4-45D2-90F3-AD64173E4BD4@gmail.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> <5963DDF1F751474D8DEEFDCDBEE43AE716E5890E@dfweml512-mbx.china.huawei.com> <4B2145DF-3D42-4EE4-A1F7-E3622F2A74D8@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E58955@dfweml512-mbx.china.huawei.com> <F43FD8B7-01A9-4C88-B02B-B4219E36F129@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E58A92@dfweml512-mbx.china.huawei.com> <EC12BECA-F369-404A-BDE3-AA518F9DF85A@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E58BDE@dfweml512-mbx.china.huawei.com> <88BBDF91-7A51-427A-BD3C-897B79C17781@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E65D8B@dfweml512-mbb.china.huawei.com>
To: Peter McCann <Peter.McCann@huawei.com>
X-Mailer: Apple Mail (2.1085)
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: Mon, 26 Nov 2012 12:48:55 -0000

Pete,


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.

Yep.

> 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