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

From: "netext issue tracker" <[email-masked]>
Date: Sun, 24 Feb 2013 18:54:20 -0000

#19: Issue in using BID from RFC 5648

Comment (by [email-masked]):

 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:  [email-masked]           |       Owner:  [email-masked]
     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/>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Feb 2013 12:15:18 -0600

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 <
[email-masked]> wrote:

> Ticket URL: <http://trac.tools.ietf.org/wg/netext/trac/ticket/19#comment:1
> >