Re: [netext] draft-netext-pmipv6-flowmob

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 30 August 2013 16:34 UTC

Return-Path: <sarikaya2012@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 35ADE21E805F for <netext@ietfa.amsl.com>; Fri, 30 Aug 2013 09:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YfH4eIUvAfr for <netext@ietfa.amsl.com>; Fri, 30 Aug 2013 09:34:41 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6417321F9E63 for <netext@ietf.org>; Fri, 30 Aug 2013 09:34:40 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id er20so1725692lab.35 for <netext@ietf.org>; Fri, 30 Aug 2013 09:34:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7W3eTYeL5fQK+wd2bod48DfeUI2g3XHyFL6DPiULTQI=; b=D9LKAsOPRp/sMKyX55Q5c0bri0XPIlFT5eXv72zHibEiqK2s74Dd3aAv7bvEa50T+f G/Ft6eUjzqR/Grh9fLu4HVmeOvsO3id/ytRB9aG+74yDdDkCARanPcdjiCPj2xPZi3+G +d1FD9sGIiXXxStb2TOcQ7pJkiPhwV9rd93eRCFfddTGZHOtKmJYhA4l+cJHiTfUy4Tw 541VeDEKc2nJI3QVm1APYH9Xnwj03+NPwmNti5Dqd12P82RGHjpDUidwpYx/Witxtaiq hFi8GBE+1VxcXYfDyS/LH2/1Us6c4eaQlSqloRjuEcAdX5V6+Le3+sWKfxMeloR7KoHH 66QA==
MIME-Version: 1.0
X-Received: by 10.152.27.202 with SMTP id v10mr1986949lag.43.1377880479262; Fri, 30 Aug 2013 09:34:39 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Fri, 30 Aug 2013 09:34:39 -0700 (PDT)
In-Reply-To: <1377832130.4300.0.camel@acorde.it.uc3m.es>
References: <CAC8QAcfxhKfTQGqX+f=UOAPBrE05VrsxkXo0AD=3NUOSpCe+Sw@mail.gmail.com> <1377832130.4300.0.camel@acorde.it.uc3m.es>
Date: Fri, 30 Aug 2013 11:34:39 -0500
Message-ID: <CAC8QAcdQ55h3vMOJr--HhFyA=YjO+gf9GBmQBHUpnNQFKxWfWg@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: "Carlos J. Bernardos" <cjbc@it.uc3m.es>
Content-Type: multipart/alternative; boundary=089e0160a432826d4904e52ccc35
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] draft-netext-pmipv6-flowmob
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
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: Fri, 30 Aug 2013 16:34:42 -0000

Hi Carlos, all,

I would like to summarize all the comments (mostly mine) in one mail and
put it here and hopefully offer a way out :-)

Here is the main problem in draft-netext-pmipv6-flowmob:

It attempts to do three things, LMA-based flow mobility, MAG-based flow
mobility and Multiple Proxy Care-of Address Registration extension in one
document and unfortunately can not deliver on any of these three. Each of
these is big issue and possibly subject of separate documents. Solutions on
each need consensus in the group.

Also, in draft-netext-pmipv6-flowmob there is too much emphasis on
the prefix assignment and not enough emphasis on the real protocol
issues. I am not convinced that playing with the way PMIPv6 assigns
HNPs is the solution to flow mobility.

Also, in draft-netext-pmipv6-flowmob there is too much emphasis on some
itsy bitsy optimizations like adopting BID from RFC 5648 and use it for LMA
which would probably lead sub-microsecond gains in LMA processing. It also
gets into naming issues that I mentioned in my previous mail.

Instead, draft-netext-pmipv6-flowmob could develop solution for one issue
instead of three, LMA-initiated flow mobility protocol using FMI/FMA and
add Multiple Proxy Care-of Address Registration to it because both are
needed.

draft-netext-pmipv6-flowmob could consider bringing back the Action field
in Flow Identification Mobility Option from draft-ietf-mext-flow-binding-09
of RFC 6089 and use it in the protocol because in PMIPv6 actions other than
forward are needed.

This will allow building the list of flow binding entries for MN which will
be used for routing.

draft-netext-pmipv6-flowmob could consider separating the solutions in two
different sections and also seek consensus on each from the WG.

Regards,

Behcet


On Thu, Aug 29, 2013 at 10:08 PM, Carlos Jesús Bernardos Cano <
cjbc@it.uc3m.es> wrote:

> (resending, as I think this e-mail didn't make due to the problems with
> mailman on the IETF servers)
>
> Hi Behcet,
>
> On Fri, 2013-08-23 at 16:31 -0500, Behcet Sarikaya wrote:
> > Hi Carlos,
> >
> >
> > As per issues I placed in the issue tracker, your replies and as per
> > Berlin discussions, I would to clarify the issues as follows:
> >
> > About BID: In RFC 5648, Each BID is generated and
> >       managed by a mobile node.
> >       In Section 5.1, it says A mobile node assigns a BID to each
> > care-of address when it wants to
> >    register them simultaneously with its home address.
> >    That means BID being 16 bits long is basically a short name for
> > each care-of address.
> >
> >       In draft-netext-pmipv6-flowmob, you defined BID to be assigned
> > and used by the local mobility anchor to identify which
> >    entry of the flow mobility cache is used to decide how to route a
> >    given flow.
> >    As such, your BID is very different than RFC 5648. Simple protocol
> > engineering requires giving it a different name. Maybe pBID but even
> > pBID is not appropriate because your BID is not proxy version of
> > rfc5648's BID.
>
> The BID is just a binding identifier, and this is its purpose on the
> draft, to identify a binding. The intention is to avoid introducing new
> conceptual structures if possible, re-using some already defined for
> client-based flow mobility.
>
> >
> > About how to route a given flow: I don't understand why you are so
> > much worried about it. From RFC6089, table of flow binding entries
> > should be used to route the flows.
> > Your protocol should describe what you have in each flow binding
> > entry, (including MN interface care-of address) and how you manage
> > these flow binding entries.
>
> I don't understand what you mean by "MN interface care-of address". I'll
> revise the text to ensure it is clear how the flow entries (the FMC)
> managed by the LMA is used.
> >
> > I am unable to see these things in draft-netext-pmipv6-flowmob and I
> > think that's why you seem to be so much concerned about how to route a
> > given flow.
> >
> > About marking the interfaces: In RFC5648, Home Link and Visited Link
> > are very clearly distinguished. Home link is well defined in MIPv6. So
> > other links are visited links.
> >
> > In RFC 5213, for each interface a different binding cache is created.
> > Each interface is a different mobility session. That effectively means
> > each interface is a different MN.
> >
> > But in draft-netext-pmipv6-flowmob, you want to integrate binding
> > cache entries for the same MN into one so as not to create a separate
> > mobility session for each.
>
> Not really, the idea is to be able to identify bindings (and therefore
> the use of the BID).
> >
> >
> > In that case, you need to mark these binding cache entries properly.
> > One suggestion is to mark the first one as Home Link and all others
> > Visited link and let each MAG know the marking by LMA.
> > Each MAG should keep HNPs assigned to its interface as well as to the
> > home link interface.
> > This enables MN to always use  source address(es) assigned to the home
> > link and thus MAGs can properly route these packets upwards. Downward
> > routing is as I mentioned above, based on flow mobility binding cache.
> >
> I don't see the need to mark the BCEs.
>
> In any case, I'm about to submit a revision that addresses some of the
> issues raised by Pierrick. I'm still working on other changes, such as
> the use of the update-notifications, as well as trying to simplify the
> document as much as possible. I hope that this will also address some of
> your concerns. So please, wait to -08 (will be out in the next couple of
> weeks) and check if you are happier with that version.
>
> Thanks,
>
> Carlos
> >
> > Regards,
> >
> >
> > Behcet
> >
>
>
>
>