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

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Apr 2010 16:19:22 +0300

Was there a response to this e-mail? I'm going through my list of drafts 
that are stuck, and this issue is the one that is keeping transient-bce 
from moving forward. Apologies if I've missed the discussion...

Jari

Jari Arkko kirjoitti:
> 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.
>
>> 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)?
>
>> 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.
>
>> 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.
>
>> 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.
>
> 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.
>
>> 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.
>
> Jari
>
>

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 21 Apr 2010 15:27:00 +0200

Hi Jari,

no problem. Yes there were replies to your mail on 18. Dec and on the 
27th Jan in the context
of an updated version taking your comments into account. I'll forward 
you the mails.

marco

Jari Arkko schrieb:
> Was there a response to this e-mail? I'm going through my list of 
> drafts that are stuck, and this issue is the one that is keeping 
> transient-bce from moving forward. Apologies if I've missed the 
> discussion...
>
> Jari
>
> Jari Arkko kirjoitti:
>> Marco,
>>
>>>> *Host effect*:
>>>>
>>>> expected from the host implementation when two interfaces are 
>>>> active at the same time. Or do you assume this can happen? Are the 
>> 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.
>>
>> 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.
>>
>> Please continue discussing this; I don't claim to fully understand 
>> the situation yet.
>>
>>
>>>> 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.
>>> During the transient phase, the LMA forwards uplink packets from 
>>> both MAGs.
>>>
>>>> and/or sendtraffic to the right outgoing interface.
>>>>
>> 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
>>> specification.
>>

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Apr 2010 08:11:30 -0700

Hello Marco,

Marco Liebsch wrote:
> active
> >> can fully benefit from transient BCE without adding any new
> >> requirements to these 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.

If another SDO (3GPP in this case) requires specification of a protocol behavior that is not compatible with an IETF standard compliant host, then they should be doing it on their own.

The IETF should NOT be developing protocol that break IETF standard compliant hosts and only works properly for hosts built according to another SDO specification set.

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

I'd like to understand what substantiates your statement that "setting the same IP address on both interfaces is supported?"

Best,

--julien

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 21 Apr 2010 17:50:19 +0200

Hello Julien,

> If another SDO (3GPP in this case) requires specification of a protocol behavior that is not compatible with an IETF standard compliant host, then they should be doing it on their own.
good for them that it's already there
> The IETF should NOT be developing protocol that break IETF standard compliant hosts and only works properly for hosts built according to another SDO specification set.
what do you mean with 'not compatible'? The extension to PMIP does not 
break the host more
than RC5213 does.

>>>> been configured and disables the previous interface, some packets to
>>>>         
>> the
>>     
configure an IP address to IF1 and IF2. Both IFs will forward a received 
packet,
which is destined to this address, to upper layers.

marco

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Apr 2010 09:03:10 -0700

Hi Marco,

[ cutting thru a bit ]

Marco Liebsch wrote:
> > The IETF should NOT be developing protocol that break IETF standard
> > compliant hosts and only works properly for hosts built according to
> > another SDO specification set.
> 
> break the host more than RC5213 does.

This extension seems to require the host to configure the same IP address on two interfaces, doesn't it? 

RFC 5213 does not require that. 

> >>> provide the same prefix (or address -- your stuff needs to work
> >>> with ipv4-support as well)?
> >>
> > I'd like to understand what substantiates your statement that
> > "setting the same IP address on both interfaces is supported?"
>
> configure an IP address to IF1 and IF2. Both IFs will forward a
> received packet, which is destined to this address, to upper layers.

Are you implying that configuring the same IP address to two interfaces is supported?

Best,

--julien

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Apr 2010 19:12:33 +0300

Julien, Marco,

And in fact, RFC 5213 is supposed to work even if no configuration or
any other special arrangement is done on the host. A host without any
knowledge of 3GPP or PMIP, accidentally connecting a PMIP domain will
not have any issues.

Jari

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 21 Apr 2010 18:12:16 +0200

> This extension seems to require the host to configure the same IP address on two interfaces, doesn't it? 
no. if it can, good, if not, the host will not break. Latter is the 
requirement.

> Are you implying that configuring the same IP address to two interfaces is supported?
please see above.

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Apr 2010 09:25:55 -0700

Marco Liebsch wrote:
> >>> compliant hosts and only works properly for hosts built according
> >>> to another SDO specification set.
> >>>
> >> what do you mean with 'not compatible'? The extension to PMIP does
> >> not break the host more than RC5213 does.
> >

If the host can't assign the same IP address to the second (i.e. target) interface then this results in a failure of IP address configuration on the second interface. 

When connectivity across the first interface is eventually lost, the host end up with no connectivity at all because it has no IP address configured on the second interface.

This does seem to break the host -- in the absence of said PMIP extension, it would have been assigned another IP address on the second interface and would have ended up with connectivity.

--julien

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 22 Apr 2010 10:44:28 +0200

> This does seem to break the host -- in the absence of said PMIP extension, it would have been assigned another IP address on the second interface and would have ended up with connectivity.
Julien, you cannot assume a certain behavior on the host dependent on 
whether PMIP has or has not enabled
transient BCE support. Consider a  host which performs handover 
according to RFC2513 expectation
(seem to be a lot of assumtions on limitation of such hosts) it may 
disable the IP address of IF1 before
setting the IP address on IF2. PMIPv6 with or without transient BCE will 
not break the host's connectivity.
In particular when IF1 detaches from MAG1, which could make sense as it 
has no IP address enabled anymore,
MAG1 sends a deregistration PBU to the LMA, which terminates a transient 
phase anyway.

marco

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 22 Apr 2010 13:21:17 -0700

Hi Marco,

Marco Liebsch wrote: 
> > If the host can't assign the same IP address to the second (i.e.
> > target) interface then this results in a failure of IP address
> > configuration on the second interface.
> >
> > When connectivity across the first interface is eventually lost, the
> > host end up with no connectivity at all because it has no IP address
> > configured on the second interface.
> >
> > This does seem to break the host -- in the absence of said PMIP
> > extension, it would have been assigned another IP address on the second
> > interface and would have ended up with connectivity.
> 
> whether PMIP has or has not enabled transient BCE support. 

This is exactly my point. 

We can't assume any specific behavior, but we have to support a simple host that only complies to the baseline IETF standard, e.g., RFC1122.

> Consider a  host which performs handover according to RFC2513 expectation
> disable the IP address of IF1 before setting the IP address on IF2. 

I would not qualify such a host as performing handover as per RFC 5213 expectations.

The host behavior you describe is the exception rather than the norm, and RFC 5213 provides additional support for such a host when it can reliably detect it, but mandates that no such IP address switching support is assumed by the network if the network can't reliably determine that the host has support because doing otherwise would break the host. Quoting RFC 5213:

        *  The mobile access gateway can choose to use the value 2
           (Handoff between two different interfaces of the mobile
           node), only when it knows that the mobile node has, on
           purpose, switched from one interface to another, and the
           previous interface is going to be disabled.  It may know this
           due to a number of factors.  For instance, most cellular
           networks have controlled handovers where the network knows
           that the host is moving from one attachment to another.  In
           this situation, the link-layer mechanism can inform the
           mobility functions that this is indeed a movement, not a new
           attachment.

[...]

        *  The mobile access gateway MUST NOT set the option value to 2
           (Handoff between two different interfaces of the mobile node)
           or 3 (Handoff between mobile access gateways for the same
           interface) if it cannot be determined that the mobile node
           can move the address between the interfaces involved in the
           handover or that it is the same interface that has moved.
           Otherwise, Proxy Mobile IPv6-unaware hosts that have multiple
           physical interfaces to the same domain may suffer unexpected
           failures.

But here I understand that the situation goes a bit further than what RFC 5213 talks about. RFC 5213 talks about moving an IP address from the old interface to the new interface, while what you are describing in your draft is a single IP address being assigned to two different interfaces (during the transient period.) 

[ In other words RFC5213 describes (limited) support for inter-access handovers, while what your draft describes implies support for (transient) simultaneous access. ]

A host that supports the IP address switching technique outlined in RFC 5213 does not necessarily same IP address assignment to two interfaces. In case it does not, the host can possibly break as I've outlined in my previous note. I do not think this is acceptable.

--julien

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Apr 2010 08:34:59 +0300

Oh, and I forgot to say but all the other issues have been resolved 
through the new draft.

Jari

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 23 Apr 2010 12:15:34 +0200

Hi Julien,

> We can't assume any specific behavior, but we have to support a simple host that only complies to the baseline IETF standard, e.g., RFC1122.
whatever 'support' means. You probably mean that such host should not break.

>            physical interfaces to the same domain may suffer unexpected
so what? do you propose that the specification should ensure that 
transient binding is used
only when a MAG reliably can set the HI flag, excluding HI=4?

> But here I understand that the situation goes a bit further than what RFC 5213 talks about. RFC 5213 talks about moving an IP address from the old interface to the new interface, while what you are…
if the host can, why not? If it can't, it should not break. The latter 
is what we discuss, right?

> [ In other words RFC5213 describes (limited) support for inter-access handovers, while what your draft describes implies support for (transient) simultaneous access. ]
Same as above, if a host can, it gets the full benefit. If it cannot, 
there is also benefit, but to not deviate again:
More relevant is that the host does not break.

> A host that supports the IP address switching technique outlined in RFC 5213 does not necessarily same IP address assignment to two interfaces. In case it does not, the host can possibly break
How and why?
We described these cases btw. in Dec when we replied to Jari's mail.

marco

>  as I've outlined in my previous note. I do not think this is acceptable.
>
> --julien
>