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

[Carlos Jesús Bernardos Cano <[e-mail]>]

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