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

Behcet Sarikaya <sarikaya2012@gmail.com> Thu, 29 August 2013 16:10 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 4C84621F933B for <netext@ietfa.amsl.com>; Thu, 29 Aug 2013 09:10:13 -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 Qpd85RB8IMR8 for <netext@ietfa.amsl.com>; Thu, 29 Aug 2013 09:10:11 -0700 (PDT)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id D82C421F908F for <netext@ietf.org>; Thu, 29 Aug 2013 09:10:03 -0700 (PDT)
Received: by mail-lb0-f178.google.com with SMTP id z5so877333lbh.23 for <netext@ietf.org>; Thu, 29 Aug 2013 09:10:00 -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=RkccIIztlm9qq6EL+ieTJ4yGFxa5+1hBf2bpRpXPXJU=; b=lYIdgs+DD/BD8waaHaFbx2jauP/hu7Jhhx0rXNB1rTq2z9NQ8V3CM3owv14Ins6NCK ASSIuInnFK6SD31wVQ39b0DF4tFLHWFVDxRuWcXLvrAsSuzYktvIJWyhgbXfToijsFxm V+Y8K+v+HEjdnk3vSz01fgXF+9bxZJw4spwfIpYn0Qcc4DY5sqg2aarPlGrzRrih1UWG 5oZPXmSERxYvPMAvjtTXxj0PHF9cbxWC/GYC4Htfx31QrVzpAEbJm8cWj/vLbFUa1Hlu /YxEFhJ8q6zkUGSV/yhiG3f5OghpLB/WMOHDejDekRd7F5XWTyG3gCodW5cNgtS3LDiP /TAg==
MIME-Version: 1.0
X-Received: by 10.112.77.134 with SMTP id s6mr2266770lbw.38.1377792599880; Thu, 29 Aug 2013 09:09:59 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Thu, 29 Aug 2013 09:09:59 -0700 (PDT)
In-Reply-To: <1377735094.4512.11.camel@acorde.it.uc3m.es>
References: <CAC8QAcfxhKfTQGqX+f=UOAPBrE05VrsxkXo0AD=3NUOSpCe+Sw@mail.gmail.com> <1377735094.4512.11.camel@acorde.it.uc3m.es>
Date: Thu, 29 Aug 2013 11:09:59 -0500
Message-ID: <CAC8QAceZQr58ia9jkEgLWQSJv6uaMPzvJcC9hYXxKcHbZ_LE5g@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: "Carlos J. Bernardos" <cjbc@it.uc3m.es>
Content-Type: multipart/alternative; boundary=001a11c3dfba7d797904e51856cc
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: Thu, 29 Aug 2013 16:10:14 -0000

Hi Carlos,

Please see inline.

Regards,

Behcet

On Wed, Aug 28, 2013 at 7:11 PM, Carlos Jesús Bernardos Cano <
cjbc@it.uc3m.es> wrote:

> 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.
>
>
Here two points:
First naming, remember what RFC 5213 defined:

A Binding Update message that is sent by a mobile access gateway to a
   local mobility anchor is referred to as the "Proxy Binding Update"
   message.

 In a similar spirit maybe you should call it pBID.

Second the use of this identifier. In RFC 6089, flow binding cache is also
kept in MN and it is the MN that needs the BID. Why should LMA need it?
Does MAG need it? It does not have many Proxy-CoAs?


>
> > 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.
>

It means Proxy-CoA. But you are not addressing my main comment here, why?


> >
> > 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).
>

Here is one major problem we had in defining flow mobility protocol for
PMIPv6. In mext, the problem has been divided into two issues, mcoa and
flow mobility. In Netext, we failed to do this even though the same problem
exists in PMIP.




> >
> >
> > 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.
>
>
Again you are staying away from the real problem with arguments like the
above.


> 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.
>
>
I am responsible to be after the issues I raised.

Thanks,
>
> Carlos
> >
> > Regards,
> >
> >
> > Behcet
> >
>
>
>