Re: [netext] #19: Issue in using BID from RFC 5648

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Thu, 11 July 2013 15:00 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 737D311E81DA for <netext@ietfa.amsl.com>; Thu, 11 Jul 2013 08:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level:
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.150, 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 YTQojv0mmoh6 for <netext@ietfa.amsl.com>; Thu, 11 Jul 2013 08:00:08 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF8D11E810D for <netext@ietf.org>; Thu, 11 Jul 2013 08:00:05 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 061F5CB7CA3; Thu, 11 Jul 2013 17:00:04 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [10.3.251.252] (interdigital.vlan431.asr1.yyz1.gblx.net [208.49.79.242]) (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 51670CC5DA2; Thu, 11 Jul 2013 17:00:03 +0200 (CEST)
Message-ID: <1373554800.4395.58.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: sarikaya@ieee.org
Date: Thu, 11 Jul 2013 17:00:00 +0200
In-Reply-To: <CAC8QAcdUP3q=aHb1WrYRs5FZDuD5nsDu9y_coignbzah5DN3_Q@mail.gmail.com>
References: <058.bcc117d55633f322db3cf82014276600@trac.tools.ietf.org> <073.4df49e3187f1b4826e6f9f79caf5f521@trac.tools.ietf.org> <CAC8QAcdUP3q=aHb1WrYRs5FZDuD5nsDu9y_coignbzah5DN3_Q@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-20008.007
Cc: netext@ietf.org, netext issue tracker <trac+netext@grenache.tools.ietf.org>
Subject: Re: [netext] #19: Issue in using BID from RFC 5648
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: Thu, 11 Jul 2013 15:00:15 -0000

Hi Behcet,

Resuming the discussion on this. Hopefully we would be able to progress
on this in Berlin. See inline below...

On Mon, 2013-02-25 at 12:15 -0600, Behcet Sarikaya wrote:
> Hi Carlos,
> 
> I don't understand why LMA would need the BID?
> As I mentioned, the problem is MAGs who only see one interface.
> 
> Another important point you keep missing is that in RFC5648, there is
> a clear distinction between the home interface and the visited
> interfaces. 

Can you point me in the spec where that clear distinction is made? I
cannot find any protocol field about it.
> 
> When PMIPv6 deviates from RFC 5213 model for the interfaces and start
> to treat the different interfaces from the same MN in an integrated
> fashion PMIPv6 also has to do the same.
> 
> That's why you need interface marking. By using interface marking MAG
> gets to know about multiple interfaces and LMA can differentiate
> between the two type of interface registrations.
> 
> BID is superfluous  in that there is already flow id in 6089.
> 
I disagree. The BID is a local identifier, 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.

Thanks,

Carlos
> 
> Regards,
> 
> Behcet
> 
> On Sun, Feb 24, 2013 at 12:54 PM, netext issue tracker <trac
> +netext@grenache.tools.ietf.org> wrote:
>         #19: Issue in using BID from RFC 5648
>         
>         
>         
>         Comment (by cjbc@it.uc3m.es):
>         
>          Hi,
>         
>          Apologies for the late reply.
>         
>          Let me explain the background of this solution design
>         decision. The idea
>          is to avoid defining as many new stuff as possible. It is
>         true that the
>          BID, as defined in RFC 5648, is registered by the MN, but
>         here we are just
>          trying to re-use the signaling, though obviusly the context
>         is a bit
>          different. Here is what -05 says about it:
>         
>             "This specification re-uses the extensions defined in
>         [RFC5648] to
>             manage multiple registrations, but in the context of Proxy
>         Mobile
>             IPv6.  The binding cache is therefore extended to include
>         more than
>             one proxy care-of addresses and to associate each of them
>         with a
>             binding identifier (BID).  Note that the BID is a local
>         identifier,
>             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."
>         
>          Also note that this BID in the BC of the LMA is used in
>         conjunction with
>          the flow mobility cache, which basically re-uses the
>         extensions defined in
>          RFC6089, which is about flow mobility (in the context of
>         MIPv6).
>          Therefore, I see that RFC5648 + RFC6089 are about flow
>         mobility.
>         
>         --
>         ----------------------------------------+--------------------------------
>          Reporter:  sarikaya@ieee.org           |       Owner:
>          sarikaya@ieee.org
>              Type:  defect                      |      Status:  new
>          Priority:  major                       |   Milestone:
>          milestone1
>         Component:  pmipv6-flowmob              |     Version:  2.0
>         
>          Severity:  Active WG Document          |  Resolution:
>          Keywords:  BID, PMIPv6, flow mobility  |
>         
>         ----------------------------------------+--------------------------------
>         
>         Ticket URL:
>         <http://trac.tools.ietf.org/wg/netext/trac/ticket/19#comment:1>
>         netext <http://tools.ietf.org/netext/>
>         
>