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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Fri, 30 August 2013 03:09 UTC

Return-Path: <cjbc@it.uc3m.es>
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 F38D221E804C for <netext@ietfa.amsl.com>; Thu, 29 Aug 2013 20:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3cg3Pe3mX1S for <netext@ietfa.amsl.com>; Thu, 29 Aug 2013 20:08:58 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C321E804B for <netext@ietf.org>; Thu, 29 Aug 2013 20:08:57 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DA942CB2093; Fri, 30 Aug 2013 05:08:55 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [163.117.203.89] (unknown [163.117.203.89]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 44CD2C35382; Fri, 30 Aug 2013 05:08:55 +0200 (CEST)
Message-ID: <1377832130.4300.0.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: sarikaya@ieee.org
Date: Fri, 30 Aug 2013 05:08:50 +0200
In-Reply-To: <CAC8QAcfxhKfTQGqX+f=UOAPBrE05VrsxkXo0AD=3NUOSpCe+Sw@mail.gmail.com>
References: <CAC8QAcfxhKfTQGqX+f=UOAPBrE05VrsxkXo0AD=3NUOSpCe+Sw@mail.gmail.com>
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-7.1.0.1224-7.0.0.1014-20114.004
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: cjbc@it.uc3m.es
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 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.

Thanks,

Carlos
> 
> Regards,
> 
> 
> Behcet
>