Subject: Re: [Mipshop] Adoption of draft-liebsch-netlmm-transient-bce-pmipv6 asa WG document

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 8 Oct 2008 13:44:41 -0400

Hello,

I haven't see any response on this. The consensus call is expiring on
Oct 10th. Please respond if you have an opinion on this. Personally, I
would like to see a little bit more support for this document.

Vijay

[email-masked] wrote:
> Hello,
> 
> At the MIPSHOP WG meeting at the last IETF, there was
> sufficient support to adopt
> draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as a WG document. We
> would like to confirm that consensus on the mailing list. You can
> find the latest document at
>
http://www.ietf.org/internet-drafts/draft-liebsch-netlmm-transient-bce-p
mipv6-01.txt 
> 
> Please respond by October 10, if you support or do not
> support adopting
> the document as a WG document. If you have already expressed your
> opinion in the WG meeting, there is no need to send an email on this.
> 
> The intended status for this document is Experimental.
> 
> Vijay
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 10 Oct 2008 16:53:41 +0900

Hi Vijay,

Some of issues discussed in this document can be solved by  
implementations.
For instance, the uplink issue (section 3.2.2) and others are also  
happened to Mobile IPv6 operation.
We had same problem, but we can use implementation trick to solve the  
issue (delaying the BC removal, etc).
It looks too complicated to solve such  transient issue.

In addition, this document deals with one part of multihoming support  
for PMIP (i.e. The use of multihoming to improve the inter-tech HO.)
If we will extend PMIP to support multihoming, I would like to discuss  
this document at the same time of multihoming discussion.

regards,
ryuji

On 2008/09/25, at 3:55, Vijay Devarapalli wrote:

> Hello,
>
> At the MIPSHOP WG meeting at the last IETF, there was sufficient  
> support
> to adopt
> would like to confirm that consensus on the mailing list. You can find
> the latest document at
> Please respond by October 10, if you support or do not support  
> adopting

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 10 Oct 2008 12:09:17 +0200

Hi Ryuji,

please see below for a short comment from my side about your concerns.

> It looks too complicated to solve such  transient issue.
Some of this you can do with implementation, but since signaling 
extensions makes sense to
allow control of the other components of the transient state extension, 
you can bind these things
(the uplink issue you referred to) to the signaling and to associated 
states as well, which is
more efficient than relying only on static delay, timers, etc.

> this document at the same time of multihoming discussion.
If you see this under the huge umbrella of multihoming, I will not 
object, even though this is a very specific
case. We usually do not have multiple binding cache entries here, but 
the transient state is related to the
same PMIP session, hence the same BCE. This particular BCE has a second 
forwarding entry during the
transient phase but defined forwarding characteristics. The protocol 
extension solves a particular problem
and associated use cases with low complexity. To do multihoming, you 
need much more, possibly also
something to specify routing policies. But it's ok to discuss 
multihoming aspects in the context of transient
BCEs. Thanks for your feedback.

marco

>> At the MIPSHOP WG meeting at the last IETF, there was sufficient support
>> to adopt
>> Please respond by October 10, if you support or do not support adopting

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 10 Oct 2008 10:45:58 -0500

Hi Vijay,

The I-D does show that a transient BCE can be useful in certain scenarios.
However I am wondering if the use-cases illustrated in the I-D can also be
dealt with by supporting MCoA for PMIP6 or by having simultaneous binding
type of support. 
Packet loss itself can be mitigated by buffering as an example. As the
intertechnology HO as well as optimizations for HO between MAGs (intratech)
is developed it may be the case that other approaches are utilized as well.
Hence the actual solution for how to reduce latency or limit packet losses
may be a part of the handover optimization solution. Transient BCEs is one
possible solution component of the optimized inter-intra/tech HO across
MAGs. 

Having this work developed further in MIPSHOP via the experimental route is
a good thing.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 10 Oct 2008 11:13:17 -0700

Hi Raj,

> dealt with by supporting MCoA for PMIP6 or by having simultaneous binding

Not clear how. The transient BCE solution addresses scenarios where the 
MN is attached via only one interface at a time.

> Having this work developed further in MIPSHOP via the experimental route is

Right. Note that the intended status for this document is Experimental 
for now.

Vijay

---

From: Wang Yungui <[email-masked]>
Date: Mon, 13 Oct 2008 15:17:14 +0800

Hello Marco

In section 3 (issues related), the basis assumption is,
none of communication lies between pMAG and nMAG. Correct?
(Otherwise, the uplink traffic may be forwarded to LMA
via pMAG, and downlink traffic to MN via nMAG in their
respective cases.)

On the other side, in section 4 (solution involved), the
basis assumption is: context transfer needed between pMAG
and nMAG.Correct?
(Otherwise, how does the nMAG get the special MN's
information(LMA, HNP, etc.)?)

Thus, could above two assumptions work well?

If I has missing something, please correct me. Thanks!

B.R.
Yungui

---

From: "BLUME, Oliver" <[email-masked]>
Date: Mon, 13 Oct 2008 13:01:30 +0200

Hello Yungui,

As Marco has not yet answered please allow me to provide a first comment on your question. Please see inline.

>-----Ursprüngliche Nachricht-----
>Von: [email-masked] 
>[mailto:[email-masked]] Im Auftrag von Wang Yungui
>Gesendet: Montag, 13. Oktober 2008 09:17
>An: Marco Liebsch
>Cc: [email-masked]
>Betreff: Re: [Mipshop] Adoption of 
>draft-liebsch-netlmm-transient-bce-pmipv6 as a WG document
>
>Hello Marco
>
>In section 3 (issues related), the basis assumption is, none 
>of communication lies between pMAG and nMAG. Correct?
>(Otherwise, the uplink traffic may be forwarded to LMA via 
>pMAG, and downlink traffic to MN via nMAG in their respective cases.)

[Oliver] Correct, there is no communication between nMAG and pMAG. It is solely the nMAG to handle the transient binding option in PBU with LMA.

>On the other side, in section 4 (solution involved), the basis 
>assumption is: context transfer needed between pMAG and nMAG.Correct?

[Oliver] Well, there is no context transfer between the two MAGs.  But one of the use cases (use case 1 with a single radio handover) asumes there is a context transfer available below MAGs (as specified for some radio technologies). Forwarding mechanisms and context transfer are handled between the involved assess networks but not on IP level. The mechanisms itself are out of scope of the I-D.

>If I has missing something, please correct me. Thanks!

Hope the explanation above shows that there is no involvement of the pMAG functionality as defined in PMIP RFC 5213. The nMAG way nMAG learns about LMA are the same as in PMIP without tBCE. But in addition to the HI indication the nMAG uses transient binding option to trigger an optimised handover with transient binding of both pCoA and nCoA to the same BCE. So there is no contradiction in the assumption.

Regards,

Oliver

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Oct 2008 13:39:46 +0200

Hi Yungui,

let me just add my 2 cents to the feedback Oliver provided already.
Your understanding, that there is no communication netween pMAG and
nMAG, is correct.
So far, section 4 sais only that context transfer 'may' be used to 
provide the
handover target MAG with further information, such as the assigned LMA. 
But this
is not specific to the tBCE mechanism, this is what base PMIPv6 needs as 
well
in case of a handover. If it's not CT, it must be something else to 
provide info
about the assigned LMA to the nMAG, for example a AAA lookup.

Best regards,
marco

---

From: "BLUME, Oliver" <[email-masked]>
Date: Mon, 13 Oct 2008 13:43:35 +0200

Hi Vijay and Raj,

Thanks for supporting tBCE for the experimental route. Actually, the draft handles handover use cases both with a single and with two simultaneously active interfaces.

Regarding Raj's remark, I do not quite see, how multiple CoA or simultaneous bindings can support the uses cases without the transient binding mechanism. Multiple CoA in the sense of multihoming will not provide handover of the application session. It is required to couple both bindings (transiently during the handover) to one mobility session. If this is what you refer to as MCoA or simultaneous binding this is exactly the tBCE mechanism but not possible in PMIP as of RFC 5213.

Some of this may be possible to handle implementation specifically. But as Marco mentioned in this discussion on October 10th,  the use cases on the one hand need information only available at the nMAG and on the other hand involves state at the LMA. This requires specification of signalling, which is solved in the tBCE I-D by some minor additions (transient binding option) to the PBU signalling. 

Oliver

>[mailto:[email-masked]] Im Auftrag von Vijay Devarapalli
>Gesendet: Freitag, 10. Oktober 2008 20:13
>An: Basavaraj Patil
>Cc: [email-masked]
>draft-liebsch-netlmm-transient-bce-pmipv6 asa WG document
>
>Hi Raj,
>
>Basavaraj Patil wrote:
>> Hi Vijay,
>> 
>> However I am wondering if the use-cases illustrated in the I-D can 
>> also be dealt with by supporting MCoA for PMIP6 or by having 
>> simultaneous binding type of support.
>
>Not clear how. The transient BCE solution addresses scenarios 
>where the MN is attached via only one interface at a time.
>
>> intertechnology HO as well as optimizations for HO between MAGs 
>> (intratech) is developed it may be the case that other 
>approaches are utilized as well.
>> Hence the actual solution for how to reduce latency or limit packet 
>> losses may be a part of the handover optimization solution. 
>Transient 
>> BCEs is one possible solution component of the optimized 
>> inter-intra/tech HO across MAGs.
>> 
>> Having this work developed further in MIPSHOP via the experimental 
>> route is a good thing.
>
>Right. Note that the intended status for this document is 
>Experimental for now.
>
>Vijay
>
>> 
>> -Raj
>> 
>>> Oct 10th. Please respond if you have an opinion on this. 
>Personally, 
>>> I would like to see a little bit more support for this document.
>>>
>>> Vijay
>>>
>>>> support to adopt 
>draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as 
>>>> a WG document. We would like to confirm that consensus on the 
>>>> mailing list. You can find the latest document at
>>>>
>>> 
>>>> adopting the document as a WG document. If you have already 
>>>> expressed your opinion in the WG meeting, there is no need to send 
>>>> an email on this.
>>>>

---

From: Wang Yungui <[email-masked]>
Date: Tue, 14 Oct 2008 17:24:44 +0800

Hi Marco and Oliver

Thanks for your clarification.

I mainly focus on the section 4.1 solution (figure 3 and 
related
description). Because it is not described how the nMAG gets
the same LMA as the pMAG, so I think the context transfer
between pMAG and nMAG may be implicitly included.
Of course, AAA lookup may be OK too.

Regarding of use case 1 and relavent solution, I am 
wondering
if it is used. In general, L2 handover happens before (or in
parallel) L3 handover if 'make-before-break' is supported in 
a
particular access network.
On the contrary, nMAG should avoid to create transient BCE
on LMA in this case, I think. You know, when the MN switches
to new radio, there may be some downlink traffic packets are
not completely delivered to the MN by the pMAG. Due to no
forwarding mechanism between pMAG and nMAG as the draft
described, then the pMAG has to foward those left packets to
nMAG via LMA.

B.R.
Yungui

----- Original Message ----- 
From: "Marco Liebsch" <[email-masked]>
To: "Wang Yungui" <[email-masked]>
Cc: "BLUME, Oliver" <[email-masked]>; 
<[email-masked]>
Sent: Monday, October 13, 2008 7:39 PM
Subject: Re: AW: [Mipshop] Adoption of 
draft-liebsch-netlmm-transient-bce-pmipv6 as a WG document

> So far, section 4 sais only that context transfer 'may' be 
> used to provide the
> handover target MAG with further information, such as the 
> assigned LMA. But this
> is not specific to the tBCE mechanism, this is what base 
> PMIPv6 needs as well
> in case of a handover. If it's not CT, it must be 
> something else to provide info
>> As Marco has not yet answered please allow me to provide 
>> a first comment on your question. Please see inline.
>>
>>
>>
>> [Oliver] Correct, there is no communication between nMAG 
>> and pMAG. It is solely the nMAG to handle the transient 
>> binding option in PBU with LMA.
>>
>>
>>> basis assumption is: context transfer needed between 
>>> pMAG and nMAG.Correct?
>>>
>>
>> [Oliver] Well, there is no context transfer between the 
>> two MAGs.  But one of the use cases (use case 1 with a 
>> single radio handover) asumes there is a context transfer 
>> available below MAGs (as specified for some radio 
>> technologies). Forwarding mechanisms and context transfer 
>> are handled between the involved assess networks but not 
>> on IP level. The mechanisms itself are out of scope of 
>> the I-D.
>>
>>
>> Hope the explanation above shows that there is no 
>> involvement of the pMAG functionality as defined in PMIP 
>> RFC 5213. The nMAG way nMAG learns about LMA are the same 
>> as in PMIP without tBCE. But in addition to the HI 
>> indication the nMAG uses transient binding option to 
>> trigger an optimised handover with transient binding of 
>> both pCoA and nCoA to the same BCE. So there is no 
>> contradiction in the assumption.
>>
>> Regards,
>>
>> Oliver
>>
>>
>>
>>
>>
>>> B.R.
>>> Yungui
>>>
>>>
>>>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 14 Oct 2008 13:47:32 -0400

Hello,

The consensus call has concluded. There is consensus on adopting
draft-liebsch-netlmm-transient-bce-pmipv6 as a MIPSHOP WG document.
There were a few comments raised during the WG last call on the
applicability of the transient BCE mechanism. Perhaps further
clarification in the document on the scenarios where this mechanism is
useful would help. 

Authors, please submit the document as a WG document -
draft-ietf-netlmm-transient-bce-pmipv6. Note that this will be an
Experimental document. 

Vijay

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: Wednesday, September 24, 2008 11:55 AM
> To: [email-masked]
> Subject: [Mipshop] Adoption of

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 15 Oct 2008 14:12:01 +0900

Hi Marco,

I'm fine with adopting this as an experimental work, but let me reply  
to your comments.

On 2008/10/10, at 19:09, Marco Liebsch wrote:

>> We had same problem, but we can use implementation trick to solve  
>> the issue (delaying the BC removal, etc).
> allow control of the other components of the transient state  
> extension, you can bind these things
> (the uplink issue you referred to) to the signaling and to  
> associated states as well, which is

It depends on how long the transient BCE will stay alive. If it lives  
only small time (a few msec), signaling might not be useful.

>>
>> In addition, this document deals with one part of multihoming  
>> support for PMIP (i.e. The use of multihoming to improve the inter- 
>> tech HO.)
>> If we will extend PMIP to support multihoming, I would like to  
>> discuss this document at the same time of multihoming discussion.
> case. We usually do not have multiple binding cache entries here,  
> but the transient state is related to the
> same PMIP session, hence the same BCE. This particular BCE has a  
> second forwarding entry during the

Ok. thanks for clarification.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 15 Oct 2008 14:12:35 +0900

Hi Vijay,

On 2008/10/11, at 3:13, Vijay Devarapalli wrote:

>> also be
> Not clear how. The transient BCE solution addresses scenarios where  
> the MN is attached via only one interface at a time.

How can you let this protocol work only with single interface scenario.
You can not stop someone run this protocol for multiple IFs scenario,  
too.

>> (intratech)
>> losses
>> MAGs. Having this work developed further in MIPSHOP via the  
>> experimental route is
>> a good thing.
>

OK, experimental is fine.

ryuji

>>> Personally, I

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 15 Oct 2008 14:23:03 +0900

Hi Oliver,

On 2008/10/13, at 20:43, BLUME, Oliver wrote:

>
> Hi Vijay and Raj,
>
> Thanks for supporting tBCE for the experimental route. Actually, the  
> draft handles handover use cases both with a single and with two  
> simultaneously active interfaces.

ok, this is not what Vijay(WG chair) mentioned.

> Regarding Raj's remark, I do not quite see, how multiple CoA or  
> simultaneous bindings can support the uses cases without the  
> transient binding mechanism. Multiple CoA in the sense of  
> multihoming will not provide handover of the application session. It  
> is required to couple both bindings (transiently during the  
> handover) to one mobility session. If this is what you refer to as  
> MCoA or simultaneous binding this is exactly the tBCE mechanism but  
> not possible in PMIP as of RFC 5213.

HO for application session?
You can bind one session with multiple bindings, right?
THe make-before-break HO is good example of what multiple bindings can  
be applied.

> Some of this may be possible to handle implementation specifically.  
> But as Marco mentioned in this discussion on October 10th,  the use  
> cases on the one hand need information only available at the nMAG  
> and on the other hand involves state at the LMA. This requires  
> specification of signalling, which is solved in the tBCE I-D by some  
> minor additions (transient binding option) to the PBU signalling.

What is the definition of HO optimization in this doc?
If the optimization is about no-packet-loss HO, we have Fast Mobile IP  
(yokota-san's work for PMIP).

The mechanism of tBCE is clear, but IMO some problems can be solved in  
the implementation space.
I think adding such short-time-lived states on LMA/MAG might be  
complex for this HO optimization.

ryuji

---

From: "BLUME, Oliver" <[email-masked]>
Date: Wed, 15 Oct 2008 12:21:47 +0200

Hi Ryuji,

The difference between a make-before-break-handover and tBCE is in the LMA. You are right that there are two CoAs in the mobile node during a CMIP MBB-Handover, but the HA only holds a binding for a single one of the CoAs at any time. For PMIP the CoAs are located at two MAGs, but we aim for a solution without signalling between the MAGs (as opposed to PFMIP, which solves the case where context transfer is possible). So with tBCE the MBB handover for PMIP is coordinated by having a double forwarding entry for one mobility session in the LMA. Signalling between nMAG and LMA is required to trigger the change of forwarding characteristic in the LMA independently from the time of setup of the second forwarding entry. This cannot be done implementation specifically in the LMA.

Thanks,

Oliver

>Von: Ryuji Wakikawa [mailto:[email-masked]] 
>Gesendet: Mittwoch, 15. Oktober 2008 07:23
>An: BLUME, Oliver
>Cc: Vijay Devarapalli; Basavaraj Patil; [email-masked]
>transient 
>> binding mechanism. Multiple CoA in the sense of multihoming will not 
>> provide handover of the application session. It is required 
>to couple 
>> both bindings (transiently during the
>THe make-before-break HO is good example of what multiple 
>bindings can be applied.
>
>> cases on the one hand need information only available at the 
>nMAG and 
>> on the other hand involves state at the LMA. This requires 
>If the optimization is about no-packet-loss HO, we have Fast 
>Mobile IP (yokota-san's work for PMIP).
>
>The mechanism of tBCE is clear, but IMO some problems can be 
>solved in the implementation space.
>I think adding such short-time-lived states on LMA/MAG might 
>be complex for this HO optimization.
>
>ryuji
>
>
>
>
>
>>
>>
>> Oliver
>>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 15 Oct 2008 15:03:24 +0200

Hi Ryuji,

please find my answer in-line.

> only small time (a few msec), signaling might not be useful.
I don't think the lifetime should be statically pre-configured, as it 
will differ from use case to use case.
If we have an inter-technology HO case, where the target access needs to 
set up a radio bearer or
the associated mobile interface needs to perform address 
auto-configuration, we talk about
other dimensions than a msec.
What's the problem with signaling?
The tBCE approach does not introduce new signaling. The new option uses 
existing PMIPv6 signaling
(PBU/PBA) as vehicle. The new option allows configuration of the 
transient phase to suit the selected
use case.
But if you mean the second PBU/PBA handshake to change the transient 
binding state into a
normal (active) binding, this is useful to consider explicit control 
when the transient state is left.
But this is optional and used only if it's useful,e.g. when the handover 
target MAG gets an indication
that the radio bearer setup or the address configuration at the mobile's 
handover target interface has
been completed. Other activating mechanisms may suit as well.

>>> support for PMIP (i.e. The use of multihoming to improve the 
>>> inter-tech HO.)

Thanks,
marco

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 15 Oct 2008 15:24:33 +0200

Hi Yungui,

> Of course, AAA lookup may be OK too.
Why should a different LMA be assigned for the MN's attachment to the nMAG?
It's still the same MN with the same MNID, right? It's only a different 
interface and
possibly different ATT. To allow session continuity, the MN should 
remain anchored
at the same LMA. And notification about the assigned LMA is not a tBCE 
specific
issue, but needed for base PMIPv6 handover as well.

> described, then the pMAG has to foward those left packets to
I think you refer to the single radio HO case and use case 1. Here,
tBCE is beneficial in case there is forwarding from the previous
radio access network to the target radio access network. The use case
in the tBCE draft refers to existing radio access specific handover and
forwarding schemes. This is not forwarding between MAGs, but forwarding
from entities below MAGs. To benefit from these mechanisms, you must
ensure that the LMA keeps forwarding towards the previous access for
some time, which is what tBCE for this use case does.

If there is no forwarding below MAGs, you can use the FPMIPv6 mechanisms
from draft-yokota to establish a tunnel between pMAG and nMAG to improve
single radio handover.

marco

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 15 Oct 2008 16:33:31 +0200

Hi Vijay,

we want to go through the discussion now and hope that we receive more 
comments.
We will submit the WG document before the 00-draft deadline, taking the 
result of
the comments and discussion as well as the intended status of the 
document into account.

Thanks,
marco

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 15 Oct 2008 16:02:17 -0400

Hi,

> complex for this HO optimization.

[RKo:>] I agree with Ryuji.
We had similar issue discussed in MobOpts few years ago for MIP. There was a short draft with title "keep BCE for a little longer" or something like that. You could solve it as an implementation-specific technique. The need for a protocol is not clear.

Regards,

-Rajeev

---

From: Wang Yungui <[email-masked]>
Date: Thu, 16 Oct 2008 09:14:49 +0800

Hi Marco

>> Regarding of use case 1 and relavent solution, I am wondering
>> parallel) L3 handover if 'make-before-break' is supported in a 

Yes, I referred to the single radio HO case and use case 1.
If there is the forwarding either below or between
MAGs as you said, then the issue(described in section 3.1)
is not existed. It seems you have come into a loop.

B.R.
Yungui

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 15 Oct 2008 22:28:26 -0500

Hi Yungui,

> wondering if it 
> >> is used. In general, L2 handover happens before (or in
> on LMA in 
> >> this case, I think. You know, when the MN switches to new radio, 
> >> there may be some downlink traffic packets are not completely 
> >> delivered to the MN by the pMAG. Due to no forwarding mechanism 
> >> between pMAG and nMAG as the draft described, then the pMAG has to 
> >> foward those left packets to nMAG via LMA.
> >>
> > tBCE is beneficial in case there is forwarding from the 
> previous radio 
> > access network to the target radio access network. The use 
> case in the 
> > tBCE draft refers to existing radio access specific handover and 
> > forwarding schemes. This is not forwarding between MAGs, but 
> > forwarding from entities below MAGs. To benefit from these 
> mechanisms, 
> > you must ensure that the LMA keeps forwarding towards the previous 
> > access for some time, which is what tBCE for this use case does.
> >
> > If there is no forwarding below MAGs, you can use the FPMIPv6 
> > mechanisms from draft-yokota to establish a tunnel between pMAG and 
> > nMAG to improve single radio handover.
> >
> > marco
> >
> 
> If there is the forwarding either below or between MAGs as 
> you said, then the issue(described in section 3.1) is not 
> existed. It seems you have come into a loop.

[Ahmad]
Sorry for jumping in here, BUT What do you mean that this issue does not
exist? And you seem to be in a loop?

Please elaborate and explain what is the confusion here.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 15 Oct 2008 23:28:53 -0500

Hello Ryuji,
Sorry for responding a little late:) but let me add to the discussion
you had with Oliver and Marco. please see some comments inline.

Regards,
Ahmad

> Subject: Re: [Mipshop] Adoption of 

[Ahmad]
As probably has been pointed out by Oliver and Marco, the answer here is
sure, you can design some implementation to hopefully capture a solution
for this issue; however, it will be beneficial for us on this mailing
list to examine such implementation in order to evaluate if it really
works or NOT. Please explain what you have in mind.

In the meantime, I fundamentally disagree with handling such issue using
some arbitrary mechanism or solution other than SECURE control
signaling. This is clearly a change that impacts the mobile node BCE at
the LMA which was NOT created in random BUT via a secure PMIPv6
signaling and MUST continue to be maintained via PMIPv6 protocol
specification as captured in RFC5213 or a new enhancement to such
signaling.

Having said all of the above, please remember to make sure that your
implementation "tweak" or "kluge" :) is inline with the above assumption
which is applicable to any protocol.

> For instance, the uplink issue (section 3.2.2) and others are 
> also happened to Mobile IPv6 operation.
[Ahmad]
TRUE.

Also, similar issue has been identified in the case of MIPv4 too and
there is a work in progress to address that at MIP4. But what is the
point you are trying to make here?

> We had same problem, but we can use implementation trick to 
> solve the issue (delaying the BC removal, etc).

[Ahmad]
Hmmmmm... Interesting approach. 
I may rephrase this as follows "yes we have a problem but what about
adopting a kluge to solve it"!
Also, delaying the removal of which BC? Could you please explain a
little more. 

Thanks as always!

> It looks too complicated to solve such transient issue.
[Ahmad]
Why? 
Is there any defect in the proposed solution? If there is one, please
help us identify it to fix it. 
Thanks again.

> inter-tech HO.) If we will extend PMIP to support 
> multihoming, I would like to discuss this document at the 
> same time of multihoming discussion.

[Ahmad]
Sure, it may be perceived as having a flavor of multihoming, but it
seems that you agree that multihoming needs to be addressed via a
protocol signaling mechanism while at the same time for this "special
case of multihoming" you suggest using some implementation tricks!:)

> draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as a 
> > WG document. We would like to confirm that consensus on the mailing 
> > list. You can find the latest document at 
> > 
> expressed 
> > your opinion in the WG meeting, there is no need to send an 
> email on 
> > this.
> >

---

From: Wang Yungui <[email-masked]>
Date: Thu, 16 Oct 2008 14:55:31 +0800

Hello Ahmad

If the issue in section 3 exists, a potential assumption
is necessary that "no forwarding either below or between
MAGs". However, as Marco described in the below mail(and
other place), there is forwarding below/between MAGs (be
used in the solution, e.g. to solve my mentioned problem).
Therefore, I think it likes a loop. Please correct me if
it is wrong. Thanks.

B.R.
Yungui

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Wang Yungui" <[email-masked]>; "Marco Liebsch"
<[email-masked]>
Cc: "Marco Liebsch" <[email-masked]>; "BLUME, Oliver"
<[email-masked]>; <[email-masked]>
Sent: Thursday, October 16, 2008 11:28 AM
Subject: RE: [Mipshop] Adoption of
draft-liebsch-netlmm-transient-bce-pmipv6 as a WG document

Hi Yungui,

> existed. It seems you have come into a loop.

[Ahmad]
Sorry for jumping in here, BUT What do you mean that this issue does
not
exist? And you seem to be in a loop?

Regards,
Ahmad

---

From: "BLUME, Oliver" <[email-masked]>
Date: Thu, 16 Oct 2008 12:51:33 +0200

Hi Yungui,

Obviously we have a loop in the discusssion, let's not argue who's loop it is but cut it loose :-)

Here is my shot at the loop:

1) For *single* interface handover the previous radio link is broken when setting up connectivity to the new access network.
2) There may be packets on the way from LMA to pMAG and the MN (being unaware of PMIP) may send uplink packets to nMAG before it received PBAck
3) Without optimisation both packets will be lost
4) For an optimisation either we need forwarding/tunneling between the access networks or between the MAGs. 

So the issue exists. Now, tBCE proposes a solution where nMAG signals transient binding option within the PMIP BU to LMA. All packets according to (2) can be succesfully transmitted. pMAG does not even need to support tBCE enhancement of PMIP.

5) use case 1 of tBCE assumes there is  a mechanism for forwarding between access networks *on L2* (but no IP tunnel between MAGs). In some access technologies this mechanisms exists and standardisation bodies want to reuse this.
6) PFMIP is an orthogonal solution with signalling on *IP layer* between MAGs. It requires an IP tunnel.

4) Furthermore, after PBAck sent by LMA some packets may still be on the way from pMAG to LMA
5) These packets might be handled by an implementation specific tweak, but I'd prefer to have them handled by the same optimisation as the packets named in (2), i.e. a transient binding of the pCoA.

Hope this clearifies what assumption use case 1 of tBCE (single interface handover) is built on.
Note that for the dual radio handover there is no need for forwarding/tunneling! But signalling is required to coordinate the switching of the path. tBCE (use case 2) provides the mechanism to switch uplink and downlink path seperately.

Oliver

>Von: Wang Yungui [mailto:[email-masked]] 
>Gesendet: Donnerstag, 16. Oktober 2008 08:56
>An: Ahmad Muhanna; Marco Liebsch
>Cc: Marco Liebsch; BLUME, Oliver; [email-masked]
>If the issue in section 3 exists, a potential assumption is 
>necessary that "no forwarding either below or between MAGs". 
>However, as Marco described in the below mail(and other 
>place), there is forwarding below/between MAGs (be used in the 
>solution, e.g. to solve my mentioned problem).
>Therefore, I think it likes a loop. Please correct me if it is 
>wrong. Thanks.
>
>B.R.
>Yungui
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 16 Oct 2008 07:07:29 -0500

Hello Yungui,

I hope that Oliver detailed email close the loop and answer your
concern.

Regards,
Ahmad

> From: Wang Yungui [mailto:[email-masked]] 
> Sent: Thursday, October 16, 2008 1:56 AM
> To: Muhanna, Ahmad (RICH1:2H10); Marco Liebsch
> place), there is forwarding below/between MAGs (be used in 
> the solution, e.g. to solve my mentioned problem).
> Therefore, I think it likes a loop. Please correct me if it 
> is wrong. Thanks.
> 
> B.R.
> Yungui
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 20 Oct 2008 18:38:18 +0900

Hello Ahmad,

Sorry for responding late...

At Wed, 15 Oct 2008 23:28:53 -0500,
 > works or NOT. Please explain what you have in mind.

Do you want me to implement it and evaluate it?
I no longer work for University and don't have any students to ask;-<

The idea is very simple, before removing a (proxy) binding, LMA just
hold it with certain pre-configured time.

 > specification as captured in RFC5213 or a new enhancement to such

Well, I agree the SECURE part.
I believe static configuration is most secured way in most of  
scenarios;-)

 > point you are trying to make here?

OK. I wonder why nobody raise this issue at MIP6.
Maybe no operators yet? :-)

 > Also, delaying the removal of which BC? Could you please explain a

- receiving deregistration BU
- the target BCE marked as old/dead/whatever-BCE
- receiving registration BU
- creating a new BCE
- removing old-BCE after certain time

We can implement this in similar way of tBCE with no signaling.
tBCE only carries the lifetime, it's to be expected.

 > help us identify it to fix it.

Maybe my question is do you really need dynamic lifetime assignment
(from MAG?) on this? How much different lifetime (10msec, 1sec,
10sec?) do you expect to configure at MAG depending on access media or
what metrics?!

 > case of multihoming" you suggest using some implementation tricks!:)

If this is "special case" of multihoming, why do we need to have this
item now?

Multihoming related part in tBCE is the case of inter-tech HO scenario
(MBB). Other parts are just how to treat data from oMAG in such short
minutes...

Is MBB the scope of this work -> chairs?

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 20 Oct 2008 18:38:21 +0900

Hi Oliver,

sorry for my delay.

At Wed, 15 Oct 2008 12:21:47 +0200,
BLUME, Oliver wrote:
 >
 > Hi Ryuji,
 >
 > The difference between a make-before-break-handover and tBCE is in
 > the LMA. You are right that there are two CoAs in the mobile node
 > during a CMIP MBB-Handover, but the HA only holds a binding for a
 > single one of the CoAs at any time.

We have MCoA as an extension to hold multiple CoAs.

 > For PMIP the CoAs are located at
 > two MAGs, but we aim for a solution without signalling between the
 > MAGs (as opposed to PFMIP, which solves the case where context
 > transfer is possible). So with tBCE the MBB handover for PMIP is
 > coordinated by having a double forwarding entry for one mobility
 > session in the LMA.

double forwarding entry means double proxy bindings, right?
This seems multihoming case.

 > Signalling between nMAG and LMA is required to
 > trigger the change of forwarding characteristic in the LMA
 > independently from the time of setup of the second forwarding
 > entry. This cannot be done implementation specifically in the LMA.

Yes, for MBB case.

However my understanding was that MBB is out of scope in this document
as Vijay (Chair) mentioned. (only dealing with single IF?)
In other scenarios, LMA need to determine just whether it accepts the
packets from oMAG.

thanks
ryuji

 > >>> Not clear how. The transient BCE solution addresses scenarios  
where
 > >>>>>> At the MIPSHOP WG meeting at the last IETF, there was  
sufficient
 > >http://www.ietf.org/internet-drafts/draft-liebsch-netlmm-transient- 
bc
 > >>>>> e-p

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 20 Oct 2008 18:38:24 +0900

Hello Marco,

At Wed, 15 Oct 2008 15:03:24 +0200,
 > >>> For instance, the uplink issue (section 3.2.2) and others are  
also
 > >> (the uplink issue you referred to) to the signaling and to  
associated
 > other dimensions than a msec.

Do you introduce this lifetime for MAKE-BEFORE-BREAK HO scenario?

For other scenarios (intra-tech HO), how much different lifetime do
you expect in your mind?  This is about LMA-MAG operation (operator's
internal matter).  I think the operator can easily tune the parameters
by itself.

 > What's the problem with signaling?

I am not arguing only the signaling overhead.
tBCE introduces a new states newly managed by LMA.

regards,
ryuji

---

From: "BLUME, Oliver" <[email-masked]>
Date: Mon, 20 Oct 2008 12:18:01 +0200

Hi Ryuji,

Thanks for coming back with these issues. The discussion on the mailing list has had a lot of attention to the single IF use case , but let's not forget the dual IF case. IMO intertech HO will be dual IF in most cases and MBB is the propper way to handle this. But without further optimisation PMIP does not support MBB . tBCE is proposing a simple solution.

See more comments inline.

Regards,
Oliver

>Gesendet: Montag, 20. Oktober 2008 11:38
>An: BLUME, Oliver
>Betreff: Re: AW: [Mipshop] Adoption of 
> > The difference between a make-before-break-handover and 
>tBCE is in  > the LMA. You are right that there are two CoAs 
>in the mobile node  > during a CMIP MBB-Handover, but the HA 
>only holds a binding for a  > single one of the CoAs at any time.
>

See below

> > two MAGs, but we aim for a solution without signalling 
>between the  > MAGs (as opposed to PFMIP, which solves the 
>case where context  > transfer is possible). So with tBCE the 
>MBB handover for PMIP is  > coordinated by having a double 
>forwarding entry for one mobility  > session in the LMA.
>

Not really.  It is not a double entry but the entries are managed together with forwarding rules that adapt to the progress of the handover. The transient mechanism takes care of this binding cache management.

>
> > Signalling between nMAG and LMA is required to  > trigger 
>the change of forwarding characteristic in the LMA  > 
>However my understanding was that MBB is out of scope in this 
>document as Vijay (Chair) mentioned. (only dealing with single 
>IF?) 

No, not at all. You probably recall that the draft was composed of three individual drafts, coming up with more or less the same approach. Two of these were aiming at the MBB for dual IF. This is reflected in the use cases in the tBCE draft, all of them rely on the same signalling and states.
IMO MBB is a strong motivation for tBCE and not well supported by any other PMIP approach yet.

>In other scenarios, LMA need to determine just whether it 
>accepts the packets from oMAG.

> > >Von: Ryuji Wakikawa [mailto:[email-masked]]  > 
>>Gesendet: Mittwoch, 15. Oktober 2008 07:23  > >An: BLUME, 
>Oliver  > >Cc: Vijay Devarapalli; Basavaraj Patil; 
>[email-masked]  > >Betreff: Re: [Mipshop] Adoption of  > 
>>draft-liebsch-netlmm-transient-bce-pmipv6 asa WG document  > 
>>  > >Hi Oliver,  > >  > >On 2008/10/13, at 20:43, BLUME, Oliver wrote:
> > >
> > >>
> > >> Hi Vijay and Raj,
> > >>
> > >> Thanks for supporting tBCE for the experimental route. 
>Actually, the  > >> draft handles handover use cases both with 
>a single and with two  > >> simultaneously active interfaces.
> > >
> > >> Regarding Raj's remark, I do not quite see, how multiple 
>CoA or  > >> simultaneous bindings can support the uses cases 
>without the  > >transient  > >> binding mechanism. Multiple 
>CoA in the sense of multihoming will not  > >> provide 
>handover of the application session. It is required  > >to 
>couple  > >> both bindings (transiently during the  > >> 
>handover) to one mobility session. If this is what you refer 
>to as  > >> MCoA or simultaneous binding this is exactly the 
>tBCE mechanism but  > >> not possible in PMIP as of RFC 5213.
> > >
> > >> But as Marco mentioned in this discussion on October 
>10th,  the use  > >> cases on the one hand need information 
>only available at the  > >nMAG and  > >> on the other hand 
>involves state at the LMA. This requires  > >> specification 
>of signalling, which is solved in the tBCE I-D by some  > >> 
> > >If the optimization is about no-packet-loss HO, we have 
>Fast  > >Mobile IP (yokota-san's work for PMIP).
> > >
> > >The mechanism of tBCE is clear, but IMO some problems can 
>be  > >solved in the implementation space.
> > >I think adding such short-time-lived states on LMA/MAG 
>might  > >be complex for this HO optimization.
> > >
> > >ryuji
> > >
> > >
> > >
> > >
> > >
> > >>
> > >>
> > >> Oliver
> > >>
> > >>> -----Ursprüngliche Nachricht-----  > >>> Von: 
>[email-masked]  > >>> 
>[mailto:[email-masked]] Im Auftrag von Vijay 
>Devarapalli  > >>> Gesendet: Freitag, 10. Oktober 2008 20:13  
>> >>> An: Basavaraj Patil  > >>> Cc: [email-masked]  > >>> 
>Betreff: Re: [Mipshop] Adoption of  > >>> 
>draft-liebsch-netlmm-transient-bce-pmipv6 asa WG document  > 
>>>>  > >>> Hi Raj,  > >>>  > >>> Basavaraj Patil wrote:
> > >>>> Hi Vijay,
> > >>>>
> > >>>> The I-D does show that a transient BCE can be useful 
>in  > >>> certain scenarios.
> > >>>> However I am wondering if the use-cases illustrated in 
>the I-D can  > >>>> also be dealt with by supporting MCoA for 
>PMIP6 or by having  > >>>> simultaneous binding type of support.
> > >>>
> > >>> Not clear how. The transient BCE solution addresses 
>scenarios where  > >>> the MN is attached via only one 
>interface at a time.
> > >>>
> > >>>> Packet loss itself can be mitigated by buffering as an 
> > >>> example. As the  > >>>> intertechnology HO as well as 
>optimizations for HO between MAGs  > >>>> (intratech) is 
>developed it may be the case that other  > >>> approaches are 
>utilized as well.
> > >>>> Hence the actual solution for how to reduce latency or 
> > >limit packet  > >>>> losses may be a part of the handover 
>optimization solution.
> > >>> Transient
> > >>>> BCEs is one possible solution component of the 
>optimized  > >>>> inter-intra/tech HO across MAGs.
> > >>>>
> > >>>> Having this work developed further in MIPSHOP via the 
>experimental  > >>>> route is a good thing.
> > >>>
> > >>> Right. Note that the intended status for this document 
>is  > >>> Experimental for now.
> > >>>
> > >>> Vijay
> > >>>
> > >>>>
> > >>>> -Raj
> > >>>>
> > >>>>> I haven't see any response on this. The consensus 
>call is  > >>> expiring on  > >>>>> Oct 10th. Please respond 
>if you have an opinion on this.
> > >>> Personally,
> > >>>>>> At the MIPSHOP WG meeting at the last IETF, there 
>was sufficient  > >>>>>> support to adopt  > >>> 
>draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as  > >>>>>> 
>> >>>>>> mailing list. You can find the latest document at  > 
>>>>>>>  > >>>>>  > >>>  > 
> > >>>>>> Please respond by October 10, if you support or do 
>not support  > >>>>>> adopting the document as a WG document. 
>If you have already  > >>>>>> expressed your opinion in the WG 
>meeting, there is no  > >need to send  > >>>>>> an email on this.
> > >>>>>>

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 20 Oct 2008 15:35:47 +0200

Hi Ryuji,

> Do you introduce this lifetime for MAKE-BEFORE-BREAK HO scenario?
If you look at Fig. 5 of the draft, we propose the specification of one
default lifetime (ACTIVATIONDELAY), which is used for TIMEOUT_2 in
the diagram. This timer is solely for keeping the uplink characteristics of
the tBCE for some time after the activation of the transient state has been
initiated. We can do this as it does not hurt keeping this characteristic.
This is different for downlink, where the transient BCE lifetime needs
to be tuned to suit the handover. Hence, we propose to configure a lifetime
(TIMEOUT 1) during the transient registration. Transient state is left 
either
after expiration of this timer or by means of signaling. I don't think the
specification can give a pre-defined value for TIMEOUT_1, as it depends
on the technology.

> internal matter). I think the operator can easily tune the parameters
Sure, if this is predictable enough. But since the tBCE supports different
use cases, we need to specify a vehicle for parameter exchange. If these
parameters are pre-configured on the MAG, you need a protocol option to
notify the LMA about this parameter. This is what the TB option does.

> I am not arguing only the signaling overhead.
Well, if you think adding an option to a PBU message is overhead...

> tBCE introduces a new states newly managed by LMA.
Yes. But that does not change if you have pre-configured parameters, 
isn't it?
And you need a document where set up and maintenance of these states are
described. This is what the tBCE specification is about.

Thanks,
marco

---

From: "BLUME, Oliver" <[email-masked]>
Date: Mon, 20 Oct 2008 17:03:49 +0200

Hi Ryuji,

You were concerned about additional state in the LMA by tBCE .

This state is not adding much complexity, but it helps to perfom optimised handover. You will remember (as you were posting in that thread), that in netlmm this approach has also been considered in the following scenario: During handover between client based MIP and PMIP there is the issue how to handle the involved BCEs of HA and LMA. Netlmm discussed that it is problematic to overwrite the pCoA (e.g. race conditions may occur due to different time of flight). As a solution Genadi proposed a deprecate state that is very similar to the transient state in TBCE: http://www.ietf.org/mail-archive/web/netlmm/current/msg05277.html. I extracted the statement for convienience of people in MIPSHOP:

	> Genadi Velev, 1. Oktober 2008 19:34
	> An: Basavaraj Patil  Cc: Netlmm
	> Betreff: Re: [netlmm] PMIP6-MIP6 Interactions - Binding Cache EntryManagement - Please comment
	>
	> If I understand correctly, a single BCE means that e.g. the PMIPv6 
	> mobility signalling would overwrite the MIPv6 BCE and vice versa -- the
	> MIPv6 signalling overwrites the PMIPv6 BCE. Is my understanding correct?
	> If it is correct, the overwriting could cause a problem. For example 
	> having a MIPv6->PMIPv6 transition, the PMIPv6 PBU would update/overwrite
	> the MIPv6 BCE with the MAG's address. When a BU deregistration sent by 
	> the MN arrives at the HA, there is no BCE matching to the BU dereg, the 
	> BU dereg is silently discarded. The MN starts to send BU deregs 
	> periodically, which is not desired. Therefore I think e.g. an incoming 
	> PBU should set the MIPv6 BCE in deprecated/deactivated state, i.e. the 
	> data packets are forwarded according the PMIPv6 BCE and incoming BU dereg 
	> is processed by the MIPv6 BCE. 

The solution in tBCE is more explicit with secure signalling in option fields. But the baseline is that the gain in control of forwarding achieved by transient bindings during handover may well be worthwhile the additional complexity.

Oliver 

>[mailto:[email-masked]] Im Auftrag von Marco Liebsch
>Gesendet: Montag, 20. Oktober 2008 15:36
>An: Ryuji Wakikawa
>Cc: [email-masked]; Marco Liebsch
>> > > I'm fine with adopting this as an experimental work, but let me 
>> > > reply to your comments.
>> > >
>> > >> extensions makes sense to allow control of the other components 
>> > >> of the transient state extension, you can bind these 
>things (the 
>> > >> uplink issue you referred to) to the signaling and to
>> associated
>> > >> states as well, which is
>> > > It depends on how long the transient BCE will stay alive. If it 
>> > > lives only small time (a few msec), signaling might not 
>be useful.
>> > I don't think the lifetime should be statically pre-configured, as 
>> > it will differ from use case to use case.
>> > auto-configuration, we talk about other dimensions than a msec.
>>
>If you look at Fig. 5 of the draft, we propose the 
>specification of one default lifetime (ACTIVATIONDELAY), which 
>is used for TIMEOUT_2 in the diagram. This timer is solely for 
>keeping the uplink characteristics of the tBCE for some time 
>after the activation of the transient state has been 
>This is different for downlink, where the transient BCE 
>lifetime needs to be tuned to suit the handover. Hence, we 
>propose to configure a lifetime (TIMEOUT 1) during the 
>transient registration. Transient state is left either after 
>expiration of this timer or by means of signaling. I don't 
>think the specification can give a pre-defined value for 
>TIMEOUT_1, as it depends on the technology.
>
>
>>
>> > >>>> opinion in the WG meeting, there is no need to send 
>an email on 
>> this.
>> > >>>>

---

From: "BLUME, Oliver" <[email-masked]>
Date: Mon, 20 Oct 2008 18:29:31 +0200

Hi Ryuji,

>Maybe no operators yet? :-)
 
The issue only gets hot for PMIP. As long as the mobile terminal handles the signalling it can synchronise between the bindings. But once you delegate the signalling to (two different) MAGs we need the new functionality. Once operators start using PMIP they will ask for this optimisation ;-)

Oliver

>[mailto:[email-masked]] Im Auftrag von Ryuji Wakikawa
>An: Ahmad Muhanna
>draft-liebsch-netlmm-transient-bce-pmipv6as a WG document
>
>Hello Ahmad,
>
> > Sorry for responding a little late:) but let me add to the 
>discussion  > you had with Oliver and Marco. please see some 
>comments inline.
> >
> > Regards,
> > Ahmad
> >
> > > draft-liebsch-netlmm-transient-bce-pmipv6 as a WG 
>document  > >  > > Hi Vijay,  > >  > > Some of issues 
>discussed in this document can be solved by  > > implementations.
> >
> > [Ahmad]
> > As probably has been pointed out by Oliver and Marco, the 
>answer here is  > sure, you can design some implementation to 
>hopefully capture a solution  > for this issue; however, it 
>will be beneficial for us on this mailing  > list to examine 
>such implementation in order to evaluate if it really  > works 
>or NOT. Please explain what you have in mind.
>
>The idea is very simple, before removing a (proxy) binding, 
>LMA just hold it with certain pre-configured time.
>
> > In the meantime, I fundamentally disagree with handling 
>such issue using  > some arbitrary mechanism or solution other 
>than SECURE control  > signaling. This is clearly a change 
>that impacts the mobile node BCE at  > the LMA which was NOT 
>created in random BUT via a secure PMIPv6  > signaling and 
>MUST continue to be maintained via PMIPv6 protocol  > 
>specification as captured in RFC5213 or a new enhancement to 
>such  > signaling.
>
> > Having said all of the above, please remember to make sure 
>that your  > implementation "tweak" or "kluge" :) is inline 
>with the above assumption  > which is applicable to any protocol.
> >
> >
> > > For instance, the uplink issue (section 3.2.2) and others 
>are  > > also happened to Mobile IPv6 operation.
> > [Ahmad]
> > TRUE.
> >
> > Also, similar issue has been identified in the case of 
>MIPv4 too and  > there is a work in progress to address that 
>at MIP4. But what is the  > point you are trying to make here?
>
> > > We had same problem, but we can use implementation trick 
>to  > > solve the issue (delaying the BC removal, etc).
> >
> > [Ahmad]
> > I may rephrase this as follows "yes we have a problem but 
>what about  > adopting a kluge to solve it"!
> > Also, delaying the removal of which BC? Could you please 
>explain a  > little more.
> >
> > Thanks as always!
>
> > Is there any defect in the proposed solution? If there is 
>one, please  > help us identify it to fix it.
> > Thanks again.
>
>Maybe my question is do you really need dynamic lifetime 
>assignment (from MAG?) on this? How much different lifetime 
>(10msec, 1sec,
>10sec?) do you expect to configure at MAG depending on access 
>media or what metrics?!
>
>
> > > In addition, this document deals with one part of 
>multihoming  > > support for PMIP (i.e. The use of multihoming 
>to improve the  > > inter-tech HO.) If we will extend PMIP to 
>support  > > multihoming, I would like to discuss this 
>document at the  > > same time of multihoming discussion.
> >
> > [Ahmad]
> > Sure, it may be perceived as having a flavor of 
>multihoming, but it  > seems that you agree that multihoming 
>needs to be addressed via a  > protocol signaling mechanism 
>while at the same time for this "special  > case of 
>multihoming" you suggest using some implementation tricks!:)
>
>If this is "special case" of multihoming, why do we need to 
>have this item now?
>
>Multihoming related part in tBCE is the case of inter-tech HO 
>scenario (MBB). Other parts are just how to treat data from 
>oMAG in such short minutes...
>
>sufficient  > > > support to adopt  > > 
>draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as a  > > > 
>WG document. We would like to confirm that consensus on the 
>mailing  > > > list. You can find the latest document at  > > 
>>  > > 
>support  > > > adopting the document as a WG document. If you 
>have already  > > expressed  > > > your opinion in the WG 
>meeting, there is no need to send an  > > email on  > > > this.
> > > >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 20 Oct 2008 14:40:39 -0500

Hi Ryuji,
Please see inline.

Regards,
Ahmad

> such implementation in order to evaluate if it really  > 

[Ahmad]
I guess what you are suggesting here is an attempt to handle the case of
switching the IP tunnel from the pMAG to the nMAG while trying to
capture in-flight uplink traffic from the pMAG. Right?

Although this mechanism is NOT the best approach in my opinion, because
the statically pre-configured timer could sometime work and sometime
miss because of different delay in the network. However, do you think
that statically configured timer is very rigid or a little more
flexible. In other words, what happens if the timer expires and there is
still uplink traffic coming for the same session?

Is what you have in mind to remove the routing entry and start
discarding packets or dynamically extending the timer?

On the other hand, the case we are trying to address here is a little
different.
The LMA will receive uplink traffic from the nMAG before the LMA receive
any PMIPv6 signaling to switch the tunnel to the nMAG. Do you see the
difference? 

In other words, we need to allow traffic from a MAG that have not sent
secure PMIPv6 signaling to start with while in your case, you would like
to prolong the BCE to continue to point to the pMAG for a little longer.

> such issue using  > some arbitrary mechanism or solution 
> other than SECURE control  > signaling. This is clearly a 
> change that impacts the mobile node BCE at  > the LMA which 
> was NOT created in random BUT via a secure PMIPv6  > 
> signaling and MUST continue to be maintained via PMIPv6 
> protocol  > specification as captured in RFC5213 or a new 
> enhancement to such  > signaling.
> 

[Ahmad]
Please see comments above. In summary two points:
1. Statically configured timer does not guarantee always that it works
with all types of delay and possibly needs to be dynamically adjusted
based on traffic arrival.
2. The case we are talking about is a little different than the one you
referenced.

>  > > For instance, the uplink issue (section 3.2.2) and 
> others are  > > also happened to Mobile IPv6 operation.
>  > [Ahmad]
>  > TRUE.
>  >

[Ahmad]
No comments!

> tBCE only carries the lifetime, it's to be expected.

[Ahmad]
BTW: why you refer to the BCE update as delete then create. It could be
but in my mind for simplification it is just update:) Please see
comments above. But still I do not follow the steps you listed. Probably
using that in the context of nMAG and pMAG would be helpful. Because I
am not sure what the target BCE in the above means. Is it the BCE based
on a PMIPv6 signaling received from nMAG?

Also, tBCE define the allowed direction of traffic associated with the
transient state of the tBCE.

Best Regards,
Ahmad

> multihoming  > > support for PMIP (i.e. The use of 
> multihoming to improve the  > > inter-tech HO.) If we will 
> extend PMIP to support  > > multihoming, I would like to 
> discuss this document at the  > > same time of multihoming discussion.
>  >
>  > [Ahmad]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Oct 2008 13:48:38 +0900

Hi Marco,

Thanks for reply.

On 2008/10/20, at 22:35, Marco Liebsch wrote:

>> reply
>> solve
>> lives
> (TIMEOUT 1) during the transient registration. Transient state is  
> left either

How much tuning do you consider? I cannot imagine good example of  
these dynamic tuning.
Can you give me some example tuned value per technology?

> notify the LMA about this parameter. This is what the TB option does.

Without any extension, can't  LMA know what kind of HO MN is taking?
If LMA can learn the HO type, we don't need a protocol option to  
notify parameters...
We have handoff indicator option.

 > According to this specification, each BCE has a state associated,  
which can be either 'Active' or any of the specified transient states  
'Transient-L', 'Transient-LA' or 'Transient-A'.
If I look at Figure 5, this spec introduces certain complication to LMA.
regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Oct 2008 13:53:23 +0900

Hi Oliver,

Thanks for info.

So, do you plan to support PMIP-MIP interaction HO in this document,  
too?
I don't remember we have such consensus at NETLMM or MIPSHOP...

regards,
ryuji

On 2008/10/21, at 0:03, BLUME, Oliver wrote:

> This state is not adding much complexity, but it helps to perfom  
> optimised handover. You will remember (as you were posting in that  
> thread), that in netlmm this approach has also been considered in  
> the following scenario: During handover between client based MIP and  
> PMIP there is the issue how to handle the involved BCEs of HA and  
> LMA. Netlmm discussed that it is problematic to overwrite the pCoA  
> (e.g. race conditions may occur due to different time of flight). As  
> a solution Genadi proposed a deprecate state that is very similar to  
> the transient state in TBCE: http://www.ietf.org/mail-archive/web/netlmm/current/msg05277.html 
> . I extracted the statement for convienience of people in MIPSHOP:
>
> The solution in tBCE is more explicit with secure signalling in  
> option fields. But the baseline is that the gain in control of  
> forwarding achieved by transient bindings during handover may well  
> be worthwhile the additional complexity.
>
> Oliver
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Oct 2008 14:05:39 +0900

Hi Oliver,

On 2008/10/21, at 1:29, BLUME, Oliver wrote:

> The issue only gets hot for PMIP. As long as the mobile terminal  
> handles the signalling it can synchronise between the bindings. But  
> once you delegate the signalling to (two different) MAGs we need the  
> new functionality. Once operators start using PMIP they will ask for  
> this optimisation ;-)

You have to remember that MIP6 has FMIP to optimize HO.
IMO, MIPSHOP should consider the relationship between PFMIP and tBCE  
if both documents will be WG doc.

I'm also worry about the conflicts between tBCE and multihoming  
solutions.
There is no concrete multihoming solutions to PMIP yet.
My concern is that nobody can tell if there will be conflicts or not  
at this point.

regards,
ryuji

>> bce
>>>>> -p

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 21 Oct 2008 14:34:26 +0900

Hello Ahmad,

see my comments inline.

> still uplink traffic coming for the same session?

But the exactly same thing can be happened to tBCE...
MAG may send a missed tuned value....

> any PMIPv6 signaling to switch the tunnel to the nMAG. Do you see the

Ah, I was referring to the tunnel between pMAG and LMA.

> to prolong the BCE to continue to point to the pMAG for a little  

You need PBU and PBA before receiving uplink traffic, right?
I see PBU/PBA(transient) before the uplink setup in Figure 4.

If you have PBU-transient  before accepting the uplink traffic,
we don't need much modification.

Modifications to the LMA internal processing are enough in the document.

> based on traffic arrival.

OK. The difference is dynamic or constant value.
Dynamic value is useful in some case, but there is no grantee
that dynamic value covers all the case successfully.

Again, I don't see much need to have dynamic value for HO stuff.

> 2. The case we are talking about is a little different than the one  

see above comments.

> transient state of the tBCE.

I don't have any intention and time to write an ID for this even on  
ML...
I am not fully convinced the necessity of this document, but consensus  
call was ended.
I will stop noising here ;-) Thanks for discussion.

I would rather wait for MIPSHOP Chair's clarification about the scope  
of this document. (supporting MBB or not).

regards,
ryuji

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 21 Oct 2008 01:44:35 -0400

> You have to remember that MIP6 has FMIP to optimize HO.

[RKo:>] I don't see why we would be doing things all over.. May be I am missing something.

> if both documents will be WG doc.

[RKo:>] PFMIP is for providing handover solution for a) packet loss (both uplink and downlink), b) delay, and c) context transfer. It is meant for Standards Track, and is a dependency on Inter-HSGW handovers in eHRPD.

I don't know how you would compare it to tBCE.

> My concern is that nobody can tell if there will be conflicts or not

[RKo:>] I agree. Multihoming needs more thought as we discussed in NetExt, which would be a good place for further work.

-Rajeev

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 21 Oct 2008 10:23:57 +0200

Ryuji,

> Can you give me some example tuned value per technology?
We did some testing with inter-tech handover and set the timeout to 1000ms.
This was sufficient, but depends on the test-case. If the target 
technology needs to
perform DAD tests, the timeout should be set appropriately. But that's 
not too critical,
the timeout simply needs to be large enough as it represents a max. 
value for the transient
lifetime. More important is that the target MAG may get an indication 
about the availability of the
target interface (after configuration and bearer setup have completed) 
and signal the
status to the LMA to turn the transient binding into a normal binding. 
timeout 1 is just
a delimiter for the transient state.

> We have handoff indicator option.
Yes, the TB option does not take over the role of but complements the HI 
option to provide the
required parameters.

> If I look at Figure 5, this spec introduces certain complication to LMA.
Usually, if you want to improve a situation, you need to take into account
some effort. Implementing the transient state is simple compared to other
handover optimization techniques. We implemented this and can say that
the benefit is larger than the effort. We added the state chart as we 
thought it
clarifies about what's behind the transient state and to visualize 
simplicity
of the approach. And the chart is not complicated at all and shows a
walk through 1 or at most 2 clearly defined intermediate states between
two normal BC states. Do you think we can simplify this even more?

But to be honest, I did not get your point when you refer to the 
complexity of
the LMA. Do you propose to simplify the transient state chart even more?
Or do you think this is not needed at all? Just help me to understand and
allow me to take your comments into account.

Thanks,
marco

---

From: "BLUME, Oliver" <[email-masked]>
Date: Tue, 21 Oct 2008 11:29:02 +0200

Hi Ryuji,

I did not say that. PMIP-MIP is a netlmm issue. I just wanted to point out that the mechanism has benefit that justifies the extra effort.

Oliver

>Gesendet: Dienstag, 21. Oktober 2008 06:53
>An: BLUME, Oliver
>Cc: Marco Liebsch; [email-masked]; Marco Liebsch
>So, do you plan to support PMIP-MIP interaction HO in this 
>document, too?
>> thread), that in netlmm this approach has also been 
>considered in the 
>> following scenario: During handover between client based MIP 
>and PMIP 
>> there is the issue how to handle the involved BCEs of HA and LMA. 
>> Netlmm discussed that it is problematic to overwrite the pCoA (e.g. 
>> race conditions may occur due to different time of flight). As a 
>> solution Genadi proposed a deprecate state that is very 
>similar to the 
>> transient state in TBCE: 
>> http://www.ietf.org/mail-archive/web/netlmm/current/msg05277.html
>> 	> mobility signalling would overwrite the MIPv6 BCE and 
>vice versa
>> -- the
>> 	> MIPv6 signalling overwrites the PMIPv6 BCE. Is my 
>understanding 
>> correct?
>> 	> having a MIPv6->PMIPv6 transition, the PMIPv6 PBU 
>would update/ 
>> overwrite
>> 	> the MIPv6 BCE with the MAG's address. When a BU 
>deregistration sent 
>> by
>> 	> the MN arrives at the HA, there is no BCE matching to 
>the BU dereg, 
>> the
>> 	> PBU should set the MIPv6 BCE in 
>deprecated/deactivated state, i.e. 
>> the
>> 	> data packets are forwarded according the PMIPv6 BCE 
>and incoming BU 
>> dereg
>> The solution in tBCE is more explicit with secure signalling 
>in option 
>> fields. But the baseline is that the gain in control of forwarding 
>> achieved by transient bindings during handover may well be 
>worthwhile 
>> the additional complexity.
>>
>> Oliver
>>
>>> If you look at Fig. 5 of the draft, we propose the specification of 
>>> one default lifetime (ACTIVATIONDELAY), which is used for TIMEOUT_2 
>>> in the diagram. This timer is solely for keeping the uplink 
>>> characteristics of the tBCE for some time after the 
>activation of the 
>>> transient state has been initiated. We can do this as it does not 
>>> hurt keeping this characteristic.
>>> This is different for downlink, where the transient BCE lifetime 
>>> needs to be tuned to suit the handover. Hence, we propose to 
>>> configure a lifetime (TIMEOUT 1) during the transient registration. 
>>> Transient state is left either after expiration of this timer or by 
>>> means of signaling. I don't think the specification can give a 
>>> pre-defined value for TIMEOUT_1, as it depends on the technology.
>>>
>>>
>>>>
>>>> internal matter). I think the operator can easily tune the 
>>>> parameters by itself.
>>> Sure, if this is predictable enough. But since the tBCE supports 
>>> different use cases, we need to specify a vehicle for parameter 
>>> exchange. If these parameters are pre-configured on the 
>MAG, you need 
>>> a protocol option to notify the LMA about this parameter. This is 
>>> what the TB option does.
>>>
>>>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 21 Oct 2008 23:13:00 -0500

Dear Ryuji,

Just like you, I do not have unlimited time to dedicate to this issue:)
but since there is still some claims that this tBCE, specifically what
is referenced as usecase 1, can be addressed by implementation tweak,
tricks, or kluge at the LMA, I would like to explain a little more.

As I said earlier, there are two different cases here. 

Case 1:
=======
This one you apparently referenced in your original email where the LMA
may keep the BCE which points to the pMAG for a little longer to capture
in-flight uplink packets. In this case, the LMA has already received a
PBU and sent a PBA to the nMAG and the tunnel has been switched to pint
to the nMAG, taking in consideration the above trick.

In this case, apparently the MN (previous) Proxy BCE had a pCoA which
points to the pMAG and this was established via a secure PMIPv6
signaling. Additionally the LMA has received another secure PBU from the
nMAG to indicate the mobile node movement and HO process and to update
the MN proxy point of attachment by updating the MN proxy BCE with the
new pCoA. 

>From a security prospective, someone may argue that a preconfigured
timer may solve this issue and there is NOT much great security risk
involved in here, for the fact that the MN PMA (MAG) has signaled via
secure PBU that the MN is in the process of handoff in order for the LMA
to update the MN proxy BCE.

>From security prospective, the problem rises when some people think of
the usecase 1 as defined in tBCE draft as the same as this one!:)

Case 2:
=======
The case which we refer to as usecase 1 in the tBCE draft is as follows:

The LMA has a proxy BCE for the MN which has a pCoA that points to the
pMAG. 
The LMA has a routing entry for the MN HNP which points to the pMAG-LMA
tunnel.

ALL of a sudden, the LMA receives an IP-in-IP uplink data packet from a
MAG, it happens to be the nMAG with a payload carrying a data packet
with a source IP address which belongs to a MN HNP that is supposed to
be hosted at the pMAG.

NOW: 
====
What is the implementation trick that those who claim that this tBCE
usecase can be addressed ONLY by defining that implementation trick at
the LMA side and NO Need for a protocol?

A claim like this can for sure be categorized as one of the followings:

1. A Claim that does NOT understand the security implications of such a
claim and this case. BTW: UNTIL now, the details of such implementation
CLAIM is still UNCLEAR.

2. A Claim that probably has some understanding of the security
implication and its impact on PMIPv6 BUT at the same time has certain
undisclosed security assumptions THAT IS NOT in line to those of the
Proxy MIPv6 Domain as defined in RFC5213.

Finally, IMO, any action that the LMA MAY take based ONLY on receiving
an uplink data packet that is coming from a nMAG is similar to the "path
management" issue that we have discussed on netlmm mailing list in which
some people argued that the LMA can take an action based ONLY on
receiving an uplink data packet from a MAG while the LMA does not have a
BCE for the MN, I mean for the HNP. At least that was set to rest on
netlmm mailing list and I am sure this one will do too.

Cheers and sorry for the long email!

Regards,
Ahmad

> From: Ryuji Wakikawa [mailto:[email-masked]] 
> Sent: Tuesday, October 21, 2008 12:34 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; [email-masked]
> >> hopefully capture a solution  > for this issue; however, 
> it will be 
> >> beneficial for us on this mailing  > list to examine such 
> >> implementation in order to evaluate if it really  > works or NOT. 
> >> Please explain what you have in mind.
> >>
> > I guess what you are suggesting here is an attempt to 
> handle the case 
> > of switching the IP tunnel from the pMAG to the nMAG while 
> trying to 
> > Although this mechanism is NOT the best approach in my opinion, 
> > because the statically pre-configured timer could sometime work and 
> > sometime miss because of different delay in the network. 
> However, do 
> > you think that statically configured timer is very rigid or 
> a little 
> > more flexible. In other words, what happens if the timer 
> expires and 
> > there is still uplink traffic coming for the same session?
> 
> > The LMA will receive uplink traffic from the nMAG before the LMA 
> > receive any PMIPv6 signaling to switch the tunnel to the 
> nMAG. Do you 
> > see the difference?
> 
> > secure PMIPv6 signaling to start with while in your case, you would 
> > like to prolong the BCE to continue to point to the pMAG 
> for a little 
> > longer.
> >
> 
> If you have PBU-transient  before accepting the uplink 
> traffic, we don't need much modification.
> 
> other than 
> >> SECURE control  > signaling. This is clearly a change that impacts 
> >> the mobile node BCE at  > the LMA which was NOT created in 
> random BUT 
> >> via a secure PMIPv6  > signaling and MUST continue to be 
> maintained 
> >> via PMIPv6 protocol  > specification as captured in 
> RFC5213 or a new 
> > 2. The case we are talking about is a little different than the one 
> > you referenced.
> 
> see above comments.
> 
> >
> >>
> >> that your  > implementation "tweak" or "kluge" :) is 
> inline with the 
> >> above assumption  > which is applicable to any protocol.
> >>>
> >>>
> >> MIPv4 too and  > there is a work in progress to address 
> that at MIP4. 
> >> But what is the  > point you are trying to make here?
> >>
> > BTW: why you refer to the BCE update as delete then create. 
> It could 
> > be but in my mind for simplification it is just update:) Please see 
> > am not sure what the target BCE in the above means. Is it the BCE 
> > based on a PMIPv6 signaling received from nMAG?
> >
> I don't have any intention and time to write an ID for this 
> even on ML...
> I am not fully convinced the necessity of this document, but 
> consensus call was ended.
> I would rather wait for MIPSHOP Chair's clarification about 
> the scope of this document. (supporting MBB or not).
> 
> regards,
> ryuji
> 
> 
> 
> >
> >
> > Best Regards,
> > Ahmad
> >
> >>
> >>
> assignment 
> >> 10sec?) do you expect to configure at MAG depending on 
> access media 
> >> or what metrics?!
> >>
> >>
> >> multihoming  > > support for PMIP (i.e. The use of multihoming to 
> >> improve the  > > inter-tech HO.) If we will extend PMIP to 
> support  > 
> >> > multihoming, I would like to discuss this document at 
> the  > > same 
> >> time of multihoming discussion.
> >>>
> >>> [Ahmad]
> >> multihoming, but it  > seems that you agree that 
> multihoming needs to 
> >> be addressed via a  > protocol signaling mechanism while 
> at the same 
> >> time for this "special  > case of multihoming" you suggest 
> using some 
> >> implementation tricks!:)
> >>
> >> scenario (MBB). Other parts are just how to treat data 
> from oMAG in 
> >> such short minutes...
> >>
> >> draft-liebsch-netlmm-transient-bce-pmipv6-01.txt as a  > > > WG 
> >> document. We would like to confirm that consensus on the 
> mailing  > > 
> >> > list. You can find the latest document at  > >
> >>>>>
> >> support  > > > adopting the document as a WG document. If you have 
> >> already  > > expressed  > > > your opinion in the WG 
> meeting, there 
> >> is no need to send an  > > email on  > > > this.
> >>>>>