[netext] draft-netext-pmipv6-flowmob

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 23 August 2013 21:31 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 15BCA11E8149 for <netext@ietfa.amsl.com>; Fri, 23 Aug 2013 14:31:32 -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=[AWL=0.000, 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 kzgwiAJg-KHT for <netext@ietfa.amsl.com>; Fri, 23 Aug 2013 14:31:31 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E7D9511E810A for <netext@ietf.org>; Fri, 23 Aug 2013 14:31:30 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ev20so885915lab.36 for <netext@ietf.org>; Fri, 23 Aug 2013 14:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=W6g98P/U7wP9IHIvFn0h8UM1RVM0a2FkmQkzth5grhc=; b=Tuuw3ZSXRaXgnJ0nTyJqvlnJE7trTeNmFndtyeDzH0qYOOjFe4u6OvT8tMkX63FBQ8 UGNdWWJrPToNCuHJ9/y7VMAWm92L8jYzCz6XuQEYxhXqbXZvJSKSd42VZYOSFlfaZh7B JMuoRQQ1RxBobEE+fRk5R7NwJslM0541FGqgg7T0hBpu1AoBbxgAOhQU95JB72A+qs2c emUc5tEY3Pzf22GlwT92QAf7cMZ8WVBwXVb5bTVArG5G2n0EjKSiALGDse5J5AdcQGpo UPmW0MR07p056PPfH/8LhRcxtSfS5KgWG1hk/tJ3dCyO3+7r0IDBhz6bLhZbtBMK4Fo/ OANg==
MIME-Version: 1.0
X-Received: by 10.112.9.195 with SMTP id c3mr663000lbb.33.1377293489666; Fri, 23 Aug 2013 14:31:29 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Fri, 23 Aug 2013 14:31:29 -0700 (PDT)
Date: Fri, 23 Aug 2013 16:31:29 -0500
Message-ID: <CAC8QAcfxhKfTQGqX+f=UOAPBrE05VrsxkXo0AD=3NUOSpCe+Sw@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: "Carlos J. Bernardos" <cjbc@it.uc3m.es>, "netext@ietf.org" <netext@ietf.org>
Content-Type: multipart/alternative; boundary=001a1135e1f634019504e4a421ed
Subject: [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, 23 Aug 2013 21:31:32 -0000

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.

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


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.

Regards,

Behcet