Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Oct 2008 19:39:05 -0700

I forgot to mention a date in the previous email.  Please respond by Nov 4th, 2008. 

Thanks,
Vidya

> -----Original Message-----
> From: Narayanan, Vidya 
> Sent: Tuesday, October 28, 2008 2:13 PM
> To: [email-masked]
> Subject: PMIP6-MIP6 Interactions - Take 2
> 
> All,
> <Chair Hat On>
> A few weeks ago, we had a discussion on supporting the 
> colocated LMA/HA case (Scenario C in 
> draft-ietf-netlmm-mip-interactions-00) with a single vs. 
> separate BCE to manage the MIP6 and PMIP6 entries.  I have 
> reviewed all the emails on this topic from a few weeks ago 
> and note that we do not have consensus yet on this topic.  I 
> will attempt to summarize the main points raised here and see 
> if we can get to some form of consensus.  If this try results 
> in lack of consensus again, the chairs and the AD will review 
> all the technical points and make a decision on the way forward. 
> 
> First, before moving to a summary of the points, I want to 
> note a few things. 
> 
> - This discussion is about what we need to specify at the 
> IETF.  Please refrain from specific discussions on what has 
> been done in 3gpp or WiMAX or any other SDO.  We can get 
> requirements from other SDOs, but, ultimately, we decide what 
> to specify in our specs with a discussion here. 
> 
> - As IETF, we need to specify what works for the general 
> Internet, with regular IP and MIP6 capable nodes.  We cannot 
> assume SDO-specific solutions or any restrictions on managing 
> interfaces at the MN to be in place.   
> 
> - The support for this scenario is based on a desire to 
> support packet delivery without tunnel headers (or ROHC, 
> necessarily) while the MN is on the home link (by extending 
> the home link to be a home network using PMIP6).  We are not 
> supporting this scenario just because 3gpp has chosen this 
> scenario - if there was no logical explanation for supporting 
> this, we'd be specifying a 3gpp specific document for this or 
> just leave it to 3gpp to specify it in their specs. 
> 
> On to technical points, here is a brief summary to help the 
> discussion: 
> 
> - It may help to view the discussion in terms of processing 
> behavior of the HA/LMA.  This leads to the following two 
> options - a) always use the MIP6 BCE and only use the PMIP6 
> BCE when there is no MIP6 BCE vs. b) forward using the most 
> recently updated BCE.  
> 
> - The issue of the separate vs. same BCEs is also relevant 
> from the point of view of whether the MIP6 BCE is going to be 
> overwritten by the PMIP6 BCE or not.  
> 
> Summarizing concerns with a), we have: 
> 
> - Additional memory needed to maintain both the MIP6 and 
> PMIP6 BCE during the time of transition 
> 
> - Additional 1RT delay between the MN and LMA before packets 
> can be forwarded to the new CoA when compared to b) 
> 
> Summarizing concerns with b), we have: 
> 
> - There is no way to tell if the MN intended to handoff or be 
> multihomed with the new CoA.  Hence, if the BCE is 
> overwritten, it may have incorrectly eliminated the 
> multihoming for the MN. Packets sent from the MN using the 
> old CoA will now be dropped. 
> 
> If there are additional concerns with either approach that I 
> have failed to note, please let me know.  
> 
> Please respond to this email selecting option a) or b) and 
> providing reasons why the corresponding concerns either do 
> not apply or how they can be mitigated.  
> 
> </chair hat on>
> 
> Thanks,
> Vidya
> 
> 
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm