Subject: [DMM] review of draft-bernardos-dmm-distributed-anchoring-00

From: [email-masked]
Date: Tue, 13 Mar 2012 14:43:23 +0800

Hi Carlos

I have reviewed your draft, and I have two questions to your draft as 
following:

First, let's consider this scenario. Initially, MN is attached to D-GW1 
and has a session#1 (anchored at D-GW1). When moving to D-GW2, MN starts 
another session#2 (session#1 keeps on going). As per your draft, D-GW2 
should simulate mndgw1 and mndgw2 and establish a tunnel with D-GW1 for 
this MN. MN continues to move to D-GW3. Then D-GW3 should simulate mndgw1, 
mndgw2 and mndgw3 and maintains two forwarding tunnels between itself and 
D-GW1, D-GW2 for the MN. And MN could continue to move again and 
again..... 
PMIP requires only one MAG and only one PMIP tunnel for one MN. But it 
seems that, your draft requires, for one MN, multiple MAGs (i.e. those 
mndgw1, mndgw2 and mndgw3) and multiple tunnels for one MN. If MN keeps on 
moving, the situation will become worse. I mean, maybe dozens of MAGs and 
tunnels are needed for this MN. In this case, performance of your D-GW 
will be a big issue. Of course, you can limited the HNPes one MN can 
maintain (e.g. 3 HNPes per MN, then only 3 D-GWs could be involved at 
most), but to me, it is very hard to determine the threshold to satisfy 
every single MN.  Otherwise, network should have a mechanism for 
terminating IP addresses to release some D-GWs. But how to determine an IP 
address (HNP) is not used by a MN is also a challenge.

Second, in figure 2 of your draft, D-GW2 simulates two logic GWs (i.e. 
mn1dgw1 and mn1dgw2), and MN is attached to both two logic GWs. Does this 
indicate MN should maintain tow separated logic link with mn1dgw1 and 
mn1dgw2 respectively? If it does, then how can you ensure that MN will 
establish an additional logic link with mn1dgw2 when MN moves from D-GW1 
to D-GW2?

What do you think?

BR
Luowen

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 16 Mar 2012 09:49:44 +0100

Hi Luowen,

First of all, apologies for my late reply.

Please, see inline below.

> I have reviewed your draft, and I have two questions to your draft as

Thanks for reading it.
> 
> First, let's consider this scenario. Initially, MN is attached to
> D-GW1 and has a session#1 (anchored at D-GW1). When moving to D-GW2,
> MN starts another session#2 (session#1 keeps on going). As per your
> draft, D-GW2 should simulate mndgw1 and mndgw2 and establish a tunnel
> with D-GW1 for this MN. MN continues to move to D-GW3. Then D-GW3
> should simulate mndgw1, mndgw2 and mndgw3 and maintains two forwarding
> tunnels between itself and D-GW1, D-GW2 for the MN. And MN could
> continue to move again and again..... 
> mndgw1, mndgw2 and mndgw3) and multiple tunnels for one MN. If MN

The solution requires multiple logical interfaces to be created on the
D-GW, but the tunnels between them could be re-used.

>  keeps on moving, the situation will become worse. I mean, maybe
> dozens of MAGs and tunnels are needed for this MN. In this case,
> performance of your D-GW will be a big issue. Of course, you can

Creation and maintenance of logical interfaces is a very low resource
consuming task. If per-MN-per-anchor tunnel creation is a problem, they
can be shared among several MNs.

Besides, in realistic deployments, the chances that an MN has active
anchored prefixes in more than 2-3 D-GWs will be very low. Most likely,
address continuity will be only provided for one prefix anchored at a
different D-GW.

>  limited the HNPes one MN can maintain (e.g. 3 HNPes per MN, then only
> 3 D-GWs could be involved at most), but to me, it is very hard to
> determine the threshold to satisfy every single MN.  Otherwise,
> network should have a mechanism for terminating IP addresses to
> release some D-GWs. But how to determine an IP address (HNP) is not
> used by a MN is also a challenge. 

There are several mechanisms that can be used to determine that an IP
address is no longer active. Some of them involve active participation
from the MN itself (which is the entity that actually knows it).
> mn1dgw1 and mn1dgw2), and MN is attached to both two logic GWs. Does
> this indicate MN should maintain tow separated logic link with mn1dgw1
> and mn1dgw2 respectively? If it does, then how can you ensure that MN
> will establish an additional logic link with mn1dgw2 when MN moves
> from D-GW1 to D-GW2? 

No, no logical links are required. From the point of view of the MN, it
is just as it is attached to a link where two routers are also attached.
When MN move to D-GW3, it is as a new router got attached to the link
(no configuration step required by the MN).

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano  http://www.netcom.it.uc3m.es/
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Mar 2012 11:06:13 -0500

Hi Carlos,

You say in various places in your draft that your protocol is PMIPv6-based.
I wonder how it could be?

Please see below.

> address continuity will be only provided for one prefix anchored at a

RFC 5213 in Section 7.1 says:
Once the address configuration is complete, the mobile node can
   continue to use this address configuration as long as it is attached
   to the network that is in the scope of that Proxy Mobile IPv6 domain.

I wonder if MN moved out of PMIPv6 domain in your case?

> (no configuration step required by the MN).

Regards,

Behcet

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 18 Mar 2012 20:59:09 +0100

Hi Behcet,

> I wonder how it could be?

More accurately, we could say that the solution is network-based. PMIPv6
is just one network-based protocol and the solution is specified in the
draft for PMIPv6. Not sure what your doubt comes from...

> Please see below.

Please see my comment inline below.

> I wonder if MN moved out of PMIPv6 domain in your case?

No, it has not. One of the common assumptions for DMM is that the MN
does not need address continuity for the whole duration the MN is
attached to the domain. The idea is to enforce new communications to
make use of the address anchored closer to where the MN is attached to,
and to deprecate addresses anchored elsewhere (so they are not needed
once active communications using them are done).

Thanks,

Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 19 Mar 2012 11:13:17 -0500

Hi Carlos,

> draft for PMIPv6. Not sure what your doubt comes from...

If it is network based then I don't understand why MN has a lot to do
in your protocol as Wen has pointed out?

> once active communications using them are done).

I guess what you understand from DMM is to put LMA functionality into
MAG and lump the two together into one. That's why MN needs to get an
address in the new MAG/LMA. And all other requirements coming out of
this huge change in PMIPv6.

However, if you look into IETF work, in such cases MN needs to use
MIPv6 as in http://tools.ietf.org/html/draft-ietf-netlmm-mip-interactions-07

Regards,

Behcet

---

From: [email-masked]
Date: Tue, 20 Mar 2012 14:33:27 +0800

Hi Carlos:

Thank you for your reply.

And please see further comments inline.

BR

Luowen

Carlos Jesús Bernardos Cano <[email-masked]> 
2012/03/16 16:49
请答复 给
[email-masked]

收件人
[email-masked]
抄送
"[email-masked]" <[email-masked]>
主题
Re: [DMM] review of draft-bernardos-dmm-distributed-anchoring-00

Hi Luowen,

Thanks for reading it.

****************
[LW] Yes, you can share the tunnel among those MNs.
[LW] But for every single mobile node, serving D-GW needs to maintain 
mobility context in granularity of HNP for this mobile node which means 
you need more space to strore the binding information. Besides, all those 
anchor D-GWs of this mobile need maintain mobility context each. One issue 
of centralized mobility management is known as "Wasting resources to 
support mobile nodes not needing mobility" (
http://tools.ietf.org/html/draft-chan-dmm-requirements-00, section 4.5). 
This view concerns too many mobility context need maintenance may cause 
resources waste. And as per my understanding, your draft may have some 
contradiction with respect to this view.
[LW] Btw, in your demo at IETF83, how many those logical interfaces will 
you show to us? 
****************

*************
[LW] Yes, if most of applications are short lived, your assumption may be 
ture (i.e. no more than 2-3 D-GW). 
[LW] But long lived applications (e.g. video streaming, online gaming, 
voip, ...) should also be considered. In this case, there should be more 
D-GWs are invloved. And you know LTE has already prepared for those long 
lived even "always on" applications, e.g. an LTE-UE will get its HNP/IP 
when its default bearer is established during its intial entry, and this 
HNP/IP will keep alive always as long as this UE stays in LTE network.  My 
point is, we had better not always build some solution based on the 
assumption that the applications are short lived.
****************

*************
[LW] Yes, we need to specify this mechanism. To me, just cut off the IP 
address based on a timer in the GW may not be gentle enough.
*************

*************
[LW] Well, another question: when MN attaches to D-GW2, D-GW2 will 
simulate mn1dgw1, mn1dgw2 and send a RA to MN, does this RA contain both 
prefixes which are are used when MN anchored in D-GW1 and prefixes which 
belong to D-GW2's management ?
*************

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Mar 2012 00:11:48 +0100

Hi Behcet,

> in your protocol as Wen has pointed out?

AS stated in the draft, the solution is completely network-nased. The MN
is a legacy IPv6 node, has nothing to do in our protocol.

> MIPv6 as in http://tools.ietf.org/html/draft-ietf-netlmm-mip-interactions-07

I think I'm not following your rationale to jump from our draft to the
MN needing to use MIPv6.

Thanks,

Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 22 Mar 2012 11:50:12 -0500

Hi Carlos,

> I think I'm not following your rationale to jump from our draft to the

In your new draft draft-bernardos-dmm-distributed-anchoring-00, you
already admit that D-GW is a MAG and LMA combined. Actually it is also
very much like HA in draft-sarikaya-dmm-dmipv6-00.

Because of the MN in Fig.1 configures PrefA (this one is normal PMIPv6) and

 then again configures PrefB (and keeps using PrefA) which is where
the trick is.

PMIPv6 is network-based and this is achieved with having two distinct
entities of MAG and LMA. Then you don't need much from MN in such an
architecture with such assumptions.

However if you change these basic assumptions and have D-GW and make
it a single entity mobility protocol then you can not claim it is
network-based any more because it simply is not.

I think that there are similar concerns on draft-seite-dmm-dma-00 and
draft-liebsch-mext-dmm-nat-phl (I have not checked this one yet).

What is interesting is that with D-GW becoming like HA, all these
protocols become very similar to the distributed MIPv6 protocol.

Regards,

Behcet

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 22 Mar 2012 15:21:28 -0400

Hi Behcet,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Behcet Sarikaya
> Sent: Thursday, March 22, 2012 12:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [DMM] review of draft-bernardos-dmm-distributed-anchoring-
> 00
> 
> Hi Carlos,
> 

[JCZ] Agree

> network-based any more because it simply is not.

[JCZ] I think that Carlos refers to the fact that the changes are on the network side and we have not introduced any MN functionality. Hence, this is a network-based approach.

> protocols become very similar to the distributed MIPv6 protocol.

[JCZ] Again, we are not introducing MN changes in the draft, so I don't think it maps to a client-MIP approach.

Regards,

Juan-Carlos

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 22 Mar 2012 14:39:27 -0500

Hi JC,

>> architecture with such assumptions.

So you agree with this but ..

> [JCZ] Again, we are not introducing MN changes in the draft, so I don't think it maps to a client-MIP approach.

I challenge you to remove all MN related text (I think Wen pointed out
almost all of them) from the draft and say that considerations in
Section 7 of RFC 5213 apply.

How about that?

Behcet

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 22 Mar 2012 15:57:42 -0400

Hi Behcet,

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Thursday, March 22, 2012 3:39 PM
> To: Zuniga, Juan Carlos
> Cc: [email-masked]; [email-masked]
> >> Because of the MN in Fig.1 configures PrefA (this one is normal
> PMIPv6)
> >> and
> >>
> > [JCZ] I think that Carlos refers to the fact that the changes are on
> the network side and we have not introduced any MN functionality.
> Hence, this is a network-based approach.
> >
> > [JCZ] Again, we are not introducing MN changes in the draft, so I
> don't think it maps to a client-MIP approach.
> >
> 

[JCZ] RFC 5213 does have non-normative MN-related text in multiple sections (beyond section 7), which is needed to understand the PMIPv6 concept. The same applies to our draft, which builds on top of RFC 5213 and the NETEXT extensions. I believe it would be redundant to repeat the same considerations.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 22 Mar 2012 15:15:14 -0500

Hi JC,

> [JCZ] RFC 5213 does have non-normative MN-related text in multiple sections (beyond section 7),

Yes, like section 6.2, 6.5, 6.6, 6.13 and 8.6.

> which is needed to understand the PMIPv6 concept. The same applies to our draft, which builds on top of RFC 5213 and the NETEXT extensions. I believe it would be redundant to repeat the same considerations.
>

I am OK if you can say that say that considerations in Section 7, 6.2,
6.5, 6.6, 6.13 and 8.6.of RFC 5213 apply.

That would settle things. For example you are gonna have to remove

configures Pref B and others.

Regards,

Behcet