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

From: Marco Liebsch <[email-masked]>
Date: Fri, 28 May 2010 15:08:26 +0200

Julien,

let me reply to my own mail, as I did not get feedback on my last reply
to you. We would like to find a solution to the very last issue to proceed
with the draft. For that we really need to understand if there is an 
issue at all
and if additional text for clarification is needed.

In your mail you refer to RFC5213 text that says "...RFC 5213 provides
additional support for such a host when it can reliably detect it..." The
transient binding support builds on such detection on the nMAG as
described in 4.3.1 and enters transient state only if the host supports it.

Do we need to make this more clear in 4.3.1? If yes, let us propose
an additional paragraph.

W.r.t. dual radio handover in RFC5213 and what you claim about
host break, PMIPv6 is not aware of any application specific data
sessions. If 'break' means that the session breaks, the same can happen
with RFC5213, even though the LMA may assign the same prefix to the
target interface. As long as the UE does not move the same suffix to the
target interface, session continuity will fail. That's not detected 
according to
RFC5213 but implicitly assumed that the UE supports and does it.

marco

Marco Liebsch schrieb:
> Hi Julien,
>
> Laganier, Julien schrieb:
>> Hi Marco,
>>
>> Marco Liebsch wrote:  
>>> Laganier, Julien schrieb:
>>>    
>>>> Marco Liebsch wrote:
>>>>      
>>>>> Laganier, Julien schrieb:
>>>>>        
>>>>>> Marco Liebsch wrote:
>>>>>>          
>>>>>>> Laganier, Julien schrieb:
>>>>>>>
>>>>>>>            
>>>>>>>> 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.
>>>>>>>
>>>>>>>             
>>>>>> 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.
>>>>>         
>>>> 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, you cannot assume a certain behavior on the host dependent on
>>> 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.
>>   
> whatever 'support' means. You probably mean that such host should not 
> break.
>
>>  
>>> 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.     
>>
>> 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.
>>   
> 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 describing 
>> in your draft is a single IP address being assigned to two different 
>> interfaces (during the transient period.)   
> 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
>>