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

Carlos Jesús Bernardos Cano <> Fri, 30 August 2013 03:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F38D221E804C for <>; Thu, 29 Aug 2013 20:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e3cg3Pe3mX1S for <>; Thu, 29 Aug 2013 20:08:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8F4C321E804B for <>; Thu, 29 Aug 2013 20:08:57 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id DA942CB2093; Fri, 30 Aug 2013 05:08:55 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [] (unknown []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 44CD2C35382; Fri, 30 Aug 2013 05:08:55 +0200 (CEST)
Message-ID: <>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <>
Date: Fri, 30 Aug 2013 05:08:50 +0200
In-Reply-To: <>
References: <>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-
Cc: "" <>
Subject: Re: [netext] draft-netext-pmipv6-flowmob
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Aug 2013 03:09:05 -0000

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


> Regards,
> Behcet