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

[Behcet Sarikaya <[e-mail]>]

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 <
[e-mail]> wrote:

> #19: Issue in using BID from RFC 5648
>
>
> Comment (by [e-mail]):
>
>  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:  [e-mail]           |       Owner:  [e-mail]
>      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/>
>
>