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

[Marco Liebsch <[e-mail]>]

Hi Jari,

Jari Arkko schrieb:
> Marco,
>
>>> *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 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.
>
> I'm not sure these things can be assumed. Proxy mobile IPv6 has been 
> 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.

>
>> 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.
>
> 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)?
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.

>
>> 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.
>
> 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.

>
>> 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.
>
> 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.
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.


>
>> 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?
>
> 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.

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.

>
> Please continue discussing this; I don't claim to fully understand the 
> situation yet.
>
>
>>> 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 explain this to me first and then we can see if the document 
>>> needs changes because of this.
>> Please see above.
>>
>>>
>>> *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.
>>
>> 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.
>
> This sounds good, but I'm concerned that my example was just one case. 
> Are the other cases covered.
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.


>
>> 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.
>
> 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.
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


>
> Jari
>