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

jouni korhonen <jouni.nospam@gmail.com> Tue, 27 November 2012 09:00 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 1FB0421F850A; Tue, 27 Nov 2012 01:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qaE5a3gpgJr8; Tue, 27 Nov 2012 01:00:31 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E68D21F84F9; Tue, 27 Nov 2012 01:00:24 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so10089020lbk.31 for <multiple recipients>; Tue, 27 Nov 2012 01:00:23 -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=9AfpLNb2iPclqYRuDAWlOi7Lx55BMJ+cv2TIpdnDmVY=; b=z9MWheK+KZpYTXj8lowEveSdzgGnvtO3K86SWzz64TnsncnUbqNPM/olnttzUtgSmP p6ZCsFYbtGDbrM/SN5SvNSQrgfVtLbxnq/H+udlXj/hwUADgp4flBCSlwLOgn5CGfa9s fPHw3VDleauA3QgMJ5Y9x0ehkQrBePOWsvBnosI8al8R8D8C7ZXFSAxBDWq3QUSZlXFh dkYyEdAtnMdG9/muRgeRjfOV65IpcWd5lTyOlL+oRO15sQvJ47Sg5w8CKl2VtGGH8ZpN wqigVJ8APB/d90/ccpFS/CiejNh1x3OjMhj/x8ApdxgTEjgQfDJmWOwajkpykwnruuXF hKew==
Received: by 10.152.104.50 with SMTP id gb18mr14161359lab.9.1354006823128; Tue, 27 Nov 2012 01:00:23 -0800 (PST)
Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id p9sm6684670lbc.3.2012.11.27.01.00.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 01:00:19 -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: <5963DDF1F751474D8DEEFDCDBEE43AE716E66E4E@dfweml512-mbb.china.huawei.com>
Date: Tue, 27 Nov 2012 11:00:16 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <6362111E-CF9B-4E1A-AE02-A3296AD7D238@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> <60EF112E-92B4-45D2-90F3-AD64173E4BD4@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E66E4E@dfweml 512-mbb.china.huawei.com>
To: Peter McCann <Peter.McCann@huawei.com>
X-Mailer: Apple Mail (2.1085)
Cc: "netext@ietf.org" <netext@ietf.org>, "dmm@ietf.org" <dmm@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, 27 Nov 2012 09:00:32 -0000

Pete,

On Nov 26, 2012, at 5:54 PM, Peter McCann wrote:

[budget cut scale removal of text]

>>> 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. 
> 
> I don't see how you can make a blanket statement like this for all
> link layers that might be used for PMIP.  In particular, it seems
> to require a knowledge, at the L2, of whether the current MAG can
> see the same LMA.  This knowledge needs to be propagated across the
> link to the client, and used to determine whether the link down/up
> event propagates through the IP stack.  Perhaps your particular 
> implementation experience involved carrying such a signal but I
> cannot imagine that it holds true for every L2, especially if they
> were not designed with PMIP in mind.

I am just reflecting the nature of existing point-to-point L2 
technologies. They tend to be session oriented, ref PPP and 3GPP
stuff. Even when a WLAN type of technology is twisted to resemble
point-to-point (and with authentication) you can make it session
aware.. with limitations. And if the whole user session is between
UE and the LMA, then any leg losing the session usually torn down
the whole pipe including your L2.

I am curious to learn what point-to-point L2 technologies you have
in mind? Something already on the field or on the drawing board?


[smaller cost cut scale removal of text]

>> 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).
> 
> You seem to be implying that the L2 technology has a notion of a PMIP
> session.  The layered protocol model would seem to discourage this,
> and I can imagine that many link layers are designed without PMIP
> in mind.

I do not have a PMIP aware L2 in mind. See above. Just a point-to-point L2
that has a notion of session itself i.e. one has to explicitly set it up and
it can be disconnected at will by either end.

[snip]

>>>> 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.
> 
> It would still require coordination between the old LMA and the new
> LMA, precisely in those situations where no such coordination is possible
> (the PMIP domains are distinct and unconnected).

It is just a matter of will. OUIs are invented and EUI-64 is big hefty
number. Collision would be less probable than me winning in lottery.
However, this would probably be a task to some other SDO to arrange
than IETF.

[oh-snap]

>>> 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.
> 
> But you seem to be making assumptions about the L2 implementation 
> and that, in particular, it knows when a PMIP session is disconnected.

See my earlier notes on L2 sessions.

> I am sorry to be making a big deal about these issues.  I am raising
> them because I think it will be important to get these details right
> when it comes to the DMM solution.  There, I think we will have some

Figured that ;) 

> set of prefixes assigned to the MN at any given time, and some arbitrary
> subset will need to be deprecated and/or torn down proactively upon 
> each handover (change of MAG if a PMIP-style solution is used to 
> re-route the packets).  However, we can discuss more details on the
> DMM list if you prefer (and this may get us a bit into DMM solution
> space.  But, I am trying to think ahead).

Yep, I am familiar with this specific problem space. See e.g.
http://tools.ietf.org/html/draft-korhonen-dmm-local-prefix-00
for one solution approach. This, however, assumes the MN always
has at least on LMA that remains the same as long as the MN is
within the PMIP domain. But that was enough DMM for my needs ;)

Thinking ahead is more than welcome!

- Jouni




> 
> -Pete
> 
> 
>>>