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

"netext issue tracker" <> Sun, 24 February 2013 18:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B93B21F908B for <>; Sun, 24 Feb 2013 10:54:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0IeTPPWHI+W0 for <>; Sun, 24 Feb 2013 10:54:25 -0800 (PST)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 3E7E021F9086 for <>; Sun, 24 Feb 2013 10:54:24 -0800 (PST)
Received: from localhost ([]:56436 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1U9giK-0005wM-H8; Sun, 24 Feb 2013 19:54:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "netext issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: netext
Date: Sun, 24 Feb 2013 18:54:20 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 19
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [netext] #19: Issue in using BID from RFC 5648
X-Mailman-Version: 2.1.12
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: Sun, 24 Feb 2013 18:54:26 -0000

#19: Issue in using BID from RFC 5648

Comment (by


 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:           |       Owner:
     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: <>
netext <>