[netext] draft-netext-pmipv6-flowmob

[Behcet Sarikaya <[e-mail]>]

Hi Carlos,

As per issues I placed in the issue tracker, your replies and as per Berlin
discussions, I would to clarify the issues as follows:

About BID: In RFC 5648, Each BID is generated and
      managed by a mobile node.
      In Section 5.1, it says A mobile node assigns a BID to each care-of
address when it wants to
   register them simultaneously with its home address.
   That means BID being 16 bits long is basically a short name for each
care-of address.

      In draft-netext-pmipv6-flowmob, you defined BID to be 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.
   As such, your BID is very different than RFC 5648. Simple protocol
engineering requires giving it a different name. Maybe pBID but even pBID
is not appropriate because your BID is not proxy version of rfc5648's BID.

About how to route a given flow: I don't understand why you are so much
worried about it. From RFC6089, table of flow binding entries should be
used to route the flows.
Your protocol should describe what you have in each flow binding entry,
(including MN interface care-of address) and how you manage these flow
binding entries.

I am unable to see these things in draft-netext-pmipv6-flowmob and I think
that's why you seem to be so much concerned about how to route a given flow.

About marking the interfaces: In RFC5648, Home Link and Visited Link are
very clearly distinguished. Home link is well defined in MIPv6. So other
links are visited links.

In RFC 5213, for each interface a different binding cache is created. Each
interface is a different mobility session. That effectively means each
interface is a different MN.

But in draft-netext-pmipv6-flowmob, you want to integrate binding cache
entries for the same MN into one so as not to create a separate mobility
session for each.


In that case, you need to mark these binding cache entries properly. One
suggestion is to mark the first one as Home Link and all others Visited
link and let each MAG know the marking by LMA.
Each MAG should keep HNPs assigned to its interface as well as to the home
link interface.
This enables MN to always use  source address(es) assigned to the home link
and thus MAGs can properly route these packets upwards. Downward routing is
as I mentioned above, based on flow mobility binding cache.

Regards,

Behcet