Subject: [Mipshop] AD review of draft-ietf-mipshop-transient-bce-pmipv6

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Dec 2009 01:13:48 +0200

I have reviewed this draft. The draft is generally well written and easy 
to read. With the exception of two major issues and a number of smaller 
issues its in very good shape. I need to hear your explanation first for 
the two major issues before I can say anything about how we should move 
forward. Hopefully the fix, if needed, is small.

Please respond to the issues below and revise the document accordingly.

Technical:

*Host effect*:

I failed to understand what the effect to hosts is, and what is expected 
from the host implementation when two interfaces are active at the same 
time. Or do you assume this can happen? Are the requirements the same as 
those in RFC 5213 or do they go beyond it? For instance, presumably the 
host could be switching interface 1 to interface 2 in an atomic fashion, 
but some packets could still be in flight from the first MAG to the LMA, 
so the ability to accept those packets is important. But it would be a 
very different situation if you assumed the host should be able to keep 
alive two different interfaces, using the same IP address on both, and 
be able to accept traffic to them and/or send traffic to the right 
outgoing interface.

Please explain this to me first and then we can see if the document 
needs changes because of this.

*Corner cases*:

The specification needs to include a description of what happens in 
cases where you move on from the nMAG to a (n+1)MAG while in the 
transient states. There may be other corner cases as well; the loss of 
PBUs is well handled already, but I'm concerned about other sequences of 
events that the orderly movement from one place to another. You move 
from A to B and while that movement is still in progress, you move back 
to A. And so on.

*Single HNP*:
> The aforementioned problem is illustrated in Figure 1, which assumes
>    that the HNP will be assigned under control of the LMA.
Please go through the specification and ensure that it does not assume 
there's a single HNP -- RFC 5213 assumes a set.

*Inconsistency*:
> 4.6.2. Activation of a transient BCE
>
>
>    When the LMA receives a PBU from an MN's nMAG which has no Transient
>    Binding option included, the LMA should check whether the MN's BCE is
>    in any of the specified transient states.  If the MN's BCE is not
>    transient, the LMA processes the PBU and updates the MN's BCE
>    according to the PMIPv6 protocol [RFC5213]. 

Isn't this in conflict with Figure 4, which allowed the LMA to decide 
that it wants to set up a transient BCE even if no transient option was 
included?

*Alignment*:
>    The format of the Transient Binding option is as follows.

Please specify alignment rules, too.

*References*:

> [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
>              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861 <http://tools.ietf.org/html/rfc4861>,
>               September 2007.
>
> [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
>              Address Autoconfiguration", RFC 4862 <http://tools.ietf.org/html/rfc4862>, September 2007.
>   
In my opinion, these references do not need to be normative. They form a 
part of the rationale and explanation of the environment, but they are 
not required reading for implementing this in proxy MIP nodes.

*Editorial*:

> In order to eliminate the risk of lost packets, this
> document specifies an extension to PMIPv6 that utilizes a new
> mobility option in the Proxy Binding Update (PBU) and the Proxy
> Binding Acknowledgement (PBA) between nMAG and LMA.
>   
You need to expand references to nMAG and LMA on first use. Please go 
over the other abbreviations from the document as well.

>
> The aforementioned problem is illustrated in Figure 1, which assumes
> that the HNP will be assigned under control of the LMA.
>
I don't think HNP term has appeared before in the document.

> the
> forwarding entry of the pMAG is removed from the MN's BCE, the
> Transient-L state is left and the BCE state changes to active.
>   

Maybe ".... MN's BCE, the BCE state changes to active."

> nMAG enters the MN's data, such as the assigned HNP, into its BUL and

BUL term has not appeared before

>    experienced by MNs, which have multiple network interfaces

MN term has not appeared before

>    AAA messages.  This document specifies advanced binding cache control

AAA term has not appeared before

>    the PBA, such as the MN's HNP and the link local address to be used

HNP term has not appeared before

> Thus it is not possible that due to the loss of
>       signaling or due to a failure of the nMAG to initiate turning a
>       transient BCE into an active BCE the transient state may not get
>       terminated, i.e. stable operation of the PMIPv6 protocol [RFC5213 <http://tools.ietf.org/html/rfc5213>]
>       has reliably recovered.
>   
Lengthy sentence. Please see if you can make it clearer.

>       TIMEOUT_1 expires. .  After TIMEOUT_1 seconds, the protocol

Two dots.

Jari

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 15 Dec 2009 13:00:26 +0100

Hi Jari,

thanks a lot for your review and comments.
I split the response into two mails. Please see inline for our answers 
to your questions.

Jari Arkko schrieb:
> I have reviewed this draft. The draft is generally well written and 
> easy to read. With the exception of two major issues and a number of 
> smaller issues its in very good shape. I need to hear your explanation 
> first for the two major issues before I can say anything about how we 
> should move forward. Hopefully the fix, if needed, is small.
>
> I failed to understand what the effect to hosts is, and what is 
> expected from the host implementation when two interfaces are active 
> at the same time. Or do you assume this can happen? Are the 
> requirements the same as those in RFC 5213 or do they go beyond it?

For Linux-based mobile terminals and for terminals which are under
development for mobile communications (e.g. 3GPP), this can be
assumed. Such terminals are designed for seamless handover and
make before break support. PMIPv6 according to RFC5213 does
not efficiently support these terminals. These types of mobile terminals
can fully benefit from transient BCE without adding any new requirements
to these hosts.

For other terminals such as PCs or Laptops, activating two interfaces is
supported in many cases. The benefit of transient BCE mainly occurs
during the host interface’s configuration. Transient BCE does not
depend on hosts having both interfaces up and configured with an IP
address for parallel use. The PBU is triggered by an attach event or RtSol.
The handover performance issue with switching the downlink traffic at
that time is described in the draft. The transient BCE delays the downlink
path switch in a controlled manner while the host configures its new 
interface.
In case the host implementation switches to use the new interface after 
it has
been configured and disables the previous interface, some packets to the
previous interface may be dropped, but transient BCE is still beneficial.

For such host behavior, the new MAG could, for example, use the first
uplink packet from the host’s new interface to terminate the transient BCE
state on the LMA. Should we add this as further information to the draft?

Optimal would be the possibility to use both active and configured
interfaces during the transient period. This should also be possible
on most host implementations and is evaluated in more detail here:

Now, two cases are to be distinguished:

Case (A): Use of the same prefix on both interfaces
Case (B): Use of the same IP address on both interfaces.

For downlink traffic, the transient binding extension comprises the
rules to take routing decisions on the LMA while both interfaces are
registered. Reception of packets on the MN works for case (A) if the
host supports the weak host model. This can be configured on the
host. If case (B) can be enabled on the host, and at least with Linux OS
this is possible, the host accepts packets on both interfaces.

For uplink traffic (MN->Network), the host must have a routing rule.
This is needed in any case when you have two interfaces active and
is neither PMIPv6 nor transient BCE specific.

Hence, for transient BCE, downlink should work for unmodified hosts.
Uplink needs a routing rule, same as for RFC5213 in case an LMA has
multiple PMIPv6 sessions active for a multi-interface host. Otherwise
uplink traffic during handover is not optimal.

We had a short section on MN impact in previous versions, but took
it out. We may propose adding a new section to the draft and clarify
about Host Effect if needed. Would that be acceptable?

> For instance, presumably the host could be switching interface 1 to 
> interface 2 in an atomic fashion, but some packets could still be in 
> flight from the first MAG to the LMA, so the ability to accept those 
> packets is important.
This is uplink and is solved by the transient BCE extension on the LMA.
During the transient phase, the LMA forwards uplink packets from both MAGs.

> But it would be a very different situation if you assumed the host 
> should be able to keep alive two different interfaces, using the same 
> IP address on both, and be able to accept traffic to them and/or send 
> traffic to the right outgoing interface.
>
Please see above.

> PBUs is well handled already, but I'm concerned about other sequences 
> of events that the orderly movement from one place to another. You 
> move from A to B and while that movement is still in progress, you 
> move back to A. And so on.

For the MN stepping back during the transient BCE phase to its
pMAG, this case is covered in 4.6.1:
“In case the LMA receives a PBU with a Transient Binding option
included from a MAG which serves already as Proxy-CoA to the
associated MN in an active or transient BCE, the LMA MUST ignore
the Transient Binding option and process the PBU according to [RFC5213].”

This means the LMA terminates the transient state, ignores the
Transient Binding option and continues to use pMAG as current MAG.

For handover to (n+1) MAG, we could distinguish 2 cases:
Case (1): (n+1)MAG include a Transient Binding option
Case (2): (n+1)MAG does not include a Transient Binding option

For case (2), the procedure should be covered by 4.6.1 and the LMA
terminates the transient BCE and performs regular handover to (n+1)MAG
according to RCC5213.

For case (1), we want to keep complexity low for this version of the
specification and prefer the following solution: Also here the LMA should
ignore the Transient Binding option and proceed according to case (2).
Re-setting the transient binding phase for (n+1)MAG may be dangerous
as it’s hard to guess how long the connectivity to the previous interface
will survive. Hence we propose the immediate use of the (n+1)MAG for such
rapid handover sequence. If desired, more sophisticated solutions to such
rapid handover could be specified in future releases of the transient BCE
specification.

Please see a separate e-mail for answers to the remaining comments.

Best regards,
marco

> that it wants to set up a transient BCE even if no transient option 
> was included?
>
> *Alignment*:
>> Address Autoconfiguration", RFC 4862 
>> <http://tools.ietf.org/html/rfc4862>, September 2007.
> In my opinion, these references do not need to be normative. They form 
> a part of the rationale and explanation of the environment, but they 
> are not required reading for implementing this in proxy MIP nodes.
>
> *Editorial*:
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 15 Dec 2009 13:06:02 +0100

Hi Jari,

please see below and in-line for our response to the remaining comments.

Jari Arkko schrieb:
> packets is important. But it would be a very different situation if 
> you assumed the host should be able to keep alive two different 
> interfaces, using the same IP address on both, and be able to accept 
> traffic to them and/or send traffic to the right outgoing interface.
>

The transient BCE extension and description focuses on the HNP
of the relevant interface. Of course the LMA can handle a set of
HNPs, which does not conflict with the transient BCE extension.
If you think this needs clarification, we could add such as statement
to the draft.

> that it wants to set up a transient BCE even if no transient option 

The case where the LMA decides to enter a transient BCE is
covered in 4.6.1, where we describe the “Initiation of a Transient BCE”.
The section you refer to describes solely activation of an existing
transient state. Adding the case you describe could somehow mix
the steps. Do you agree?

> Please specify alignment rules, too.

As the option meets a 32-bit boundary alignment, we don’t
see any additional alignment rule here. But we can add a statement
that the Transient Binding option has no alignment requirement.

> are not required reading for implementing this in proxy MIP nodes.

We agree and will move these RFCs to informative references.

> *Editorial*:

All your editorial comments are valid and very much appreciated.
We’ll expand all abbreviation on first use and will shorten and clarify
the paragraph you pointed to.

Thanks and best regards,
marco

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Dec 2009 15:19:13 +0200

Marco,

>> Please go through the specification and ensure that it does not 
>> assume there's a single HNP -- RFC 5213 assumes a set.
>
> HNPs

No. RFC 5213 specifically allows multiple prefixes per interface and 
binding. Extensions of RC 5213 need to support that as well. In the past 
we've sent documents without this support to the IESG and they came back 
with a Discuss. We should fix this now.

> which does not conflict with the transient BCE extension.

What I would like to see is that every place where you talk about the 
prefix, you ensure that you talk about the prefixes instead. You should 
also go through the document to see if there are any other issues 
related to this

> transient state. Adding the case you describe could somehow mix

Lets talk about what really happens in the code, before we worry about 
document clarity.

There are two places in the document that talk about the reception of a 
PBU without the transient option. Section 4.6.1 says:

   In case the LMA receives a handover PBU from a MN's nMAG which does
   not include a Transient Binding option and the associated MN's BCE is
   active and not in transient state, the LMA MAY take the decision to
   use a transient BCE and inform the nMAG about the transient BCE
   characteristics by including a Transient Binding option in the PBA.

Section 4.6.2 says:

The code that we need to write has no knowledge of what section of the 
document it should be reading. It just gets a message, and the two text 
excerpts above are inconsistent.

I would propose that the latter text be changed to, say,

   according Section 4.6.1.

> that the Transient Binding option has no alignment requirement.

Traditionally, we've specified the mobility option alignment rules for 
every new option, even if the specification amounts to "The Pad1 option 
does not have any alignment requirements."

>> In my opinion, these references do not need to be normative. They 
>> form a part of the rationale and explanation of the environment, but 
>> they are not required reading for implementing this in proxy MIP nodes.
>
>

OK

> the paragraph you pointed to.
Good, thanks.

Jari

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 15 Dec 2009 16:35:52 +0100

Hi Jari,

Jari Arkko wrote:
> binding. Extensions of RC 5213 need to support that as well. In the 
> past we've sent documents without this support to the IESG and they 
> came back with a Discuss. We should fix this now.
Ok, got it.

> prefix, you ensure that you talk about the prefixes instead. You 
> should also go through the document to see if there are any other 
> issues related to this
Sure, we'll take care that the text reflects that multiple HNPs can be 
assigned to that link.

>>> Isn't this in conflict with Figure 4, which allowed the LMA to 
>>> decide that it wants to set up a transient BCE even if no transient 
>>> option was included?
>>
>>
> There are two places in the document that talk about the reception of 
> a PBU without the transient option. Section 4.6.1 says:
>
> document it should be reading. It just gets a message, and the two 
> text excerpts above are inconsistent.
true
>   transient, the LMA processes the PBU and updates the MN's BCE
Ok, I see what you mean. I've no problem with this. So far, according to 
the title,
the procedure in section 4.6.2 assumes that the MN's BCE state is 
transient. That's
why it says "Activation of a transient BCE", which is not needed if 
there is no
transient binding state. So, code-wise, the program should not end up in 
this 'section'
if the MN's BCE is not transient.
But I see in the current text it's redundant to write then again in 
4.6.2 "..., the LMA should
check whether the MN's BCE is in any of the specified transient states."
That was also Oliver's point. So, I am fine with both proposals: Either 
omit the superfluous
text about the LMA's check of the transient state or to adopt your 
proposal and refer to
4.6.1 for further processing in case the MN's state is not transient.
I see an advantage in Oliver's proposal that text in 4.6.2 would better 
suit the
title of the sub-section.

> every new option, even if the specification amounts to "The Pad1 
> option does not have any alignment requirements."

Ok, we'll add text about the alignment of the Transient Binding option.

Thanks,
marco

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Dec 2009 17:38:47 +0200

Marco,

>
> That was also Oliver's point. So, I am fine with both proposals:

I'm fine with either approach, too.

Jari

> Either omit the superfluous
> I see an advantage in Oliver's proposal that text in 4.6.2 would 
> better suit the
>> Traditionally, we've specified the mobility option alignment rules 
>> for every new option, even if the specification amounts to "The Pad1 
>>>> form a part of the rationale and explanation of the environment, 
>>>> but they are not required reading for implementing this in proxy 
>>>> MIP nodes.
>>>
>>>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Dec 2009 21:25:27 +0200

Marco,

> can fully benefit from transient BCE without adding any new requirements

I'm not sure these things can be assumed. Proxy mobile IPv6 has been 
designed to work on unchanged hosts.

> In case the host implementation switches to use the new interface 
> after it has

What is the behavior of common OSes when two different interfaces 
provide the same prefix (or address -- your stuff needs to work with 
ipv4-support as well)?

> host.

This assumes a specific configuration on the host.

> If case (B) can be enabled on the host, and at least with Linux OS

I'm not sure this is true. Normally you would have different addresses 
and prefixes on different interfaces, and RFC 3484 would simply choose 
one, the rest would work based on which source address you decided to use.

> about Host Effect if needed. Would that be acceptable?

I think this is a bigger issue than what can be solved with such an 
explanation. RFC 5213 was designed to ensure that pmip-unaware hosts do 
not break, not even in multihoming or other special configurations. You 
are deviating from this model by making assumptions on what the OSes on 
the hosts need to do and what configuration (weak/strong model, routing 
table) exists on the hosts. This is an architectural issue with your 
extension.

My initial response to all this is to ask you to make sure that you 
never assume anything about the host and that you ensure you do not 
cause breakage to the host under any possible configuration. I'm not 
quite sure how to achieve this though. Would it be enough to require 
that transient BCEs be enabled only when HI=2,3? Even so, what do we 
know about the host? And why would we specify multihoming and 
cross-interface handover mechanisms with host changes in MIPSHOP when we 
decided that we are not doing them in NETEXT? But maybe there's a way to 
scope the functionality of the draft so that this is not an issue.

Please continue discussing this; I don't claim to fully understand the 
situation yet.

>> transient states. There may be other corner cases as well; the loss 
>> of PBUs is well handled already, but I'm concerned about other 
>> sequences of events that the orderly movement from one place to 
>> another. You move from A to B and while that movement is still in 
>> progress, you move back to A. And so on.
>

This sounds good, but I'm concerned that my example was just one case. 
Are the other cases covered.

> rapid handover could be specified in future releases of the transient BCE

I do not care so much about how optimal these solutions are. I care 
about (a) covering all corner cases and (b) not breaking anything.

Everything you've said above looks fine, but I'm still worried about 
item a in particular.

Jari

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 18 Dec 2009 14:36:20 +0100

Hi Jari,

> designed to work on unchanged hosts.
IETF has liaison with 3GPP and other SDOs, which deploy PMIPv6. 3GPP is 
specifying
inter-system handover (3G<->non-3G). Mobile terminal vendors build 
devices which
support such handover efficiently. So, I think the assumption is valid.
But I also understand your point about not breaking unchanged hosts.
Please see below for that.

> provide the same prefix (or address -- your stuff needs to work with 
As a known fact, a common behavior cannot be assumed, as OSs, even 
distributions, differ.
We did some tests again and setting the same IP address on both 
interfaces is supported.
This allows reception of downlink packets. For uplink, there is a 
problem and as said
something needs to be done to solve routing. If you enable a second 
interface with the
same IP address, the MN continues to route packets through the previuos 
connection.
Further, still the previous MAG is used as gateway for uplink packets. 
If now
the previous interface is disabled, there is a problem with uplink for 
unmodified hosts,
as the routing table has no gateway information. This can be solved by 
sending a
further RtAdv from the new MAG. As soon as this has been received, the MN
sends uplink packets through the new interface.

The test was useful for us, so, if this is a way to proceed, we may add 
to the draft
that the nMAG sends a further RtAdv to the handover target interface to 
ensure
that (unmodified hosts) use it as default gateway. Is this accpetable?

Please see more about unmodified hosts below.

> This assumes a specific configuration on the host.
It's activation of an existing function. Some OSs have the function
enabled by default. This is inter alia described in
draft-bernardos-mif-pmip-01.
The MIF WG will analyze what's possible with current implementations.
Afaik, the group will also analyze gaps and find solutions how to address
them in a subsequent step.
Anyway, I am deviating, as this is optimization.

> one, the rest would work based on which source address you decided to 
Please see above for the test we performed. The remaining issue was that 
when the previous
interface has been switched off, the host needs a further RtAdv on the 
target interface to
set a default gateway into the routing table.

> explanation. RFC 5213 was designed to ensure that pmip-unaware hosts 
> do not break, not even in multihoming or other special configurations. 
> You are deviating from this model by making assumptions on what the 
> OSes on the hosts need to do and what configuration (weak/strong 
> model, routing table) exists on the hosts. This is an architectural 
> issue with your extension.
> cross-interface handover mechanisms with host changes in MIPSHOP when 
> we decided that we are not doing them in NETEXT? But maybe there's a 
> way to scope the functionality of the draft so that this is not an issue.

Now, let me try to clarify one thing: What we have to ensure is that the 
extension we propose does
not break unmodified hosts. Correct?
We argue that the transient BCE extension does not break a host more 
than RFC5213, which should
be acceptable if true. RFC5213 supports inter-technology handover. And 
for unmodified hosts, the
does not assume more than RFC5213 for inter-technolgy handover.

There are two cases for unmodified hosts.
(1) the host switches off interface 1 before it activates interface 2
(2) the host activates interface 2 before it switches off interface 1

In case (1), the previous MAG would have sent a deregistration PBU to 
the LMA, which does
not allow entering a transient BCE with that MAG as proxy CoA.
If case (2) can happen with an unmodified host at all, the new MAG
may send a PBU with a transient binding option to the LMA. When host 
releases its
previous link, the transient binding is released as well due to the 
previous MAG's
deregistration PBU.

I try to understand your proposal for scoping the functionaility. Is the 
proposal to
limit the scope to HI=2/3? The draft says that the MAG *may* decide to 
set a transient
binding. This is based on some information on the MAG. It would be 
difficult to decide
this without knowledge about the handover type, hence information about 
HI=2 or 3 should
be there. However, I don't see advantage in binding the draft to the HI 
settings. If you
think this brings us further, no objections from my side.

>>> should be able to keep alive two different interfaces, using the 
>>> same IP address on both, and be able to accept traffic to them 
>>> and/or send traffic to the right outgoing interface.
>>>
Ok. We'll check if there are further cases. From the specification of 
the protocol operation,
all cases should be resolved. But we'll think about additional cases to 
be described in 4.8. Maybe
from this we can find an additional rule which needs to be added to the 
MAG or LMA operations
sections.
If there is one unforeseen case, well, the specification is 
experimental. Maybe experimental
implementations can help to find them out and to specify additional rules.

> Everything you've said above looks fine, but I'm still worried about 
Ok, we'll add your cases to section 4.8 and describe how they are 
resolved with the
specified MAG and LMA operation.
We'll think about more cases and add them, but we address them first on 
the list.
W.r.t. not breaking a host, does the description and proposed change 
above help
us to proceed?

Thanks,
marco