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

Behcet Sarikaya <sarikaya2012@gmail.com> Mon, 25 February 2013 18:15 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 BFA6E21E8064 for <netext@ietfa.amsl.com>; Mon, 25 Feb 2013 10:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.586
X-Spam-Level:
X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIWPA5LcWmAA for <netext@ietfa.amsl.com>; Mon, 25 Feb 2013 10:15:20 -0800 (PST)
Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8734D21E8039 for <netext@ietf.org>; Mon, 25 Feb 2013 10:15:19 -0800 (PST)
Received: by mail-lb0-f173.google.com with SMTP id gf7so2431703lbb.4 for <netext@ietf.org>; Mon, 25 Feb 2013 10:15:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qjJw1EQJR/tYl8CYJ4CgV4raizz2PHBq+peNrOtSdKk=; b=R3eEoGxxKSRXvGdbU/bsBJIZAof41y5ntApVATF46IpZ9fXsArzjAvxPnnoNeIvDIm ZEKIY+6ek1QRGpThHNta2x89HcyrOGtajih5/zdzw70D/l/4zG9BEWCgHclv7GgRAr9J WgGCw8qFcrb1Zz44XGUjNvaQAoPOGgdas7YrfAcRSUGgL37oEynVWw58SMEwz7XAfUVP qwzQFOWpYJ82hbzNiZZzNz2Qod2hxG1A6MV64AEZy4PZSgo+WssVdeKKdfbQ0IbbsjPF tBpfpO0D1CE2s48HRj2iUGtuToZkJv4eFq0zEIfyddXZdUfy+Yxox9hUYctpwhi9ph/E FJuQ==
MIME-Version: 1.0
X-Received: by 10.112.28.102 with SMTP id a6mr4711932lbh.109.1361816118383; Mon, 25 Feb 2013 10:15:18 -0800 (PST)
Received: by 10.114.28.168 with HTTP; Mon, 25 Feb 2013 10:15:18 -0800 (PST)
In-Reply-To: <073.4df49e3187f1b4826e6f9f79caf5f521@trac.tools.ietf.org>
References: <058.bcc117d55633f322db3cf82014276600@trac.tools.ietf.org> <073.4df49e3187f1b4826e6f9f79caf5f521@trac.tools.ietf.org>
Date: Mon, 25 Feb 2013 12:15:18 -0600
Message-ID: <CAC8QAcdUP3q=aHb1WrYRs5FZDuD5nsDu9y_coignbzah5DN3_Q@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: netext issue tracker <trac+netext@grenache.tools.ietf.org>
Content-Type: multipart/alternative; boundary=f46d040168b3fc54ad04d69085ca
Cc: netext@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: 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: Mon, 25 Feb 2013 18:15:20 -0000

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.

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.


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