Subject: [netext] draft-netext-pmipv6-flowmob

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 23 Aug 2013 16:31:29 -0500

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 29 Aug 2013 11:09:59 -0500

Hi Carlos,

Please see inline.

Regards,

Behcet

On Wed, Aug 28, 2013 at 7:11 PM, Carlos Jesús Bernardos Cano <
[email-masked]> wrote:

> Hi Behcet,
>
> On Fri, 2013-08-23 at 16:31 -0500, Behcet Sarikaya wrote:
> > 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:
> >
> >       In Section 5.1, it says A mobile node assigns a BID to each
> > care-of address when it wants to
> >    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
> > 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.
>
> The BID is just a binding identifier, and this is its purpose on the
> draft, to identify a binding. The intention is to avoid introducing new
> conceptual structures if possible, re-using some already defined for
> client-based flow mobility.
>
>
Here two points:
First naming, remember what RFC 5213 defined:

A Binding Update message that is sent by a mobile access gateway to a
   local mobility anchor is referred to as the "Proxy Binding Update"
   message.

 In a similar spirit maybe you should call it pBID.

Second the use of this identifier. In RFC 6089, flow binding cache is also
kept in MN and it is the MN that needs the BID. Why should LMA need it?
Does MAG need it? It does not have many Proxy-CoAs?

>
> > 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 don't understand what you mean by "MN interface care-of address". I'll
> revise the text to ensure it is clear how the flow entries (the FMC)
> managed by the LMA is used.
>

It means Proxy-CoA. But you are not addressing my main comment here, why?

> >
> > 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.
>
> Not really, the idea is to be able to identify bindings (and therefore
> the use of the BID).
>

Here is one major problem we had in defining flow mobility protocol for
PMIPv6. In mext, the problem has been divided into two issues, mcoa and
flow mobility. In Netext, we failed to do this even though the same problem
exists in PMIP.

> >
> >
> > 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.
> >
> I don't see the need to mark the BCEs.
>
>
Again you are staying away from the real problem with arguments like the
above.

> In any case, I'm about to submit a revision that addresses some of the
> issues raised by Pierrick. I'm still working on other changes, such as
> the use of the update-notifications, as well as trying to simplify the
> document as much as possible. I hope that this will also address some of
> your concerns. So please, wait to -08 (will be out in the next couple of
> weeks) and check if you are happier with that version.
>
>
I am responsible to be after the issues I raised.

Thanks,
> Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 30 Aug 2013 05:08:50 +0200

(resending, as I think this e-mail didn't make due to the problems with
mailman on the IETF servers)

Hi Behcet,

Thanks,

Carlos

---

From: "Rajeev Koodli (rkoodli)" <[email-masked]>
Date: Fri, 30 Aug 2013 04:58:07 +0000

Hi Carlos,

I have just a related comment (chair hat off):

>weeks) and check if you are happier with that version.

I heard during the ID update at the Berlin meeting about the use of Update
Notification ID, in place of FMI/FMA? If that's the proposal, I am not for
it. Specifically, I do not want to overload the Update Notification (RFC
to be) with the semantics here. And, we should stick to the messages we
intended for the purpose and be self-contained.

Thanks.

-Rajeev

>
>Thanks,
>
>Carlos
>> 
>> Regards,
>> 
>> 
>> Behcet
>> 
>
>
>
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 30 Aug 2013 11:34:39 -0500

Hi Carlos, all,

I would like to summarize all the comments (mostly mine) in one mail and
put it here and hopefully offer a way out :-)

Here is the main problem in draft-netext-pmipv6-flowmob:

It attempts to do three things, LMA-based flow mobility, MAG-based flow
mobility and Multiple Proxy Care-of Address Registration extension in one
document and unfortunately can not deliver on any of these three. Each of
these is big issue and possibly subject of separate documents. Solutions on
each need consensus in the group.

Also, in draft-netext-pmipv6-flowmob there is too much emphasis on
the prefix assignment and not enough emphasis on the real protocol
issues. I am not convinced that playing with the way PMIPv6 assigns
HNPs is the solution to flow mobility.

Also, in draft-netext-pmipv6-flowmob there is too much emphasis on some
itsy bitsy optimizations like adopting BID from RFC 5648 and use it for LMA
which would probably lead sub-microsecond gains in LMA processing. It also
gets into naming issues that I mentioned in my previous mail.

Instead, draft-netext-pmipv6-flowmob could develop solution for one issue
instead of three, LMA-initiated flow mobility protocol using FMI/FMA and
add Multiple Proxy Care-of Address Registration to it because both are
needed.

draft-netext-pmipv6-flowmob could consider bringing back the Action field
in Flow Identification Mobility Option from draft-ietf-mext-flow-binding-09
of RFC 6089 and use it in the protocol because in PMIPv6 actions other than
forward are needed.

This will allow building the list of flow binding entries for MN which will
be used for routing.

draft-netext-pmipv6-flowmob could consider separating the solutions in two
different sections and also seek consensus on each from the WG.

Regards,

Behcet