[Netext] Draft revision of the NETEXT charter

jari.arkko at piuha.net (Jari Arkko) Thu, 23 April 2009 13:55 UTC

From: "jari.arkko at piuha.net"
Date: Thu, 23 Apr 2009 16:55:58 +0300
Subject: [Netext] Draft revision of the NETEXT charter
In-Reply-To: <00de01c9c3b6$37fc5e00$150ca40a@china.huawei.com>
References: <00de01c9c3b6$37fc5e00$150ca40a@china.huawei.com>
Message-ID: <49F0736E.5030805@piuha.net>

Yungui Wang wrote:
> Hello Jari
>
> Yeah, of course you are right that 'MIF does not rely on Mobile IPv6 
> or Proxy version thereof'. 
> I just want to view it from side of PMIP domain. Such as, there is
> a valid requirement/scenario that a certain multiple interface
> capable node, which maybe can't enable traffic flow handover 
> between interfaces but needed, is located in the PMIP domain. 
> Next step will be how to do in PMIP domain. Thus, I'd like to 
> propose its working item into Netext charter, not to MIF charter. 
> >From requirement/scenario to working item, in my understanding, 
> that's a general process in IETF.
>   

Ok. I think this does fall under the category that we are already 
discussing, the multihoming and inter-access handover support in PMIP. I 
realize your issue is looking at it from a different aspect, but it is 
still part of the same overall problem area. Please propose some 
concrete work item.

Jari

> Also I have seen that debate at before. The opposed voices 
> are similarly solution-based, e.g. existing MIP multihoming 
> works, unmodified-host, etc. I won't join in. 
> However, could you tell me how to deal with above 
> requirement/scenario?
>
> Thanks.
> Yungui
>
>
>   
>> -----Original Message-----
>> From: Jari Arkko [mailto:jari.arkko at piuha.net] 
>> Sent: Wednesday, April 22, 2009 11:57 PM
>> To: w52006 at huawei.com
>> Cc: netext at mail.mobileip.jp
>> Subject: Re: [Netext] Draft revision of the NETEXT charter
>>
>> Yungui,
>>
>>     
>>> I am concerning of how MIF capable node works in PMIP domain.
>>> In the charter of MIF, there is a paragraph described as below:
>>> "...The group shall not assume any
>>> software beyond basic IP protocol support on its peers or in network
>>> nodes. No work will be done to enable traffic flows to move from one
>>> interface to another. The group recognizes existing work on 
>>>       
>> mechanisms
>>     
>>> that require peer or network support for moving traffic 
>>>       
>> flows such as
>>     
>>> RFC 5206, RFC 4980 and the use of multiple care-of 
>>>       
>> addresses in Mobile
>>     
>>> IPv6. This group does not work on or impact such mechanisms.  ..."
>>>
>>> That's, MIF capable node is dependent on network to provide 
>>>       
>> traffic flows 
>>     
>>> moving among interfaces.
>>>       
>> No, maybe this is a misunderstanding. MIF is really not assuming 
>> anything like that happening. The charter text simply notes that such 
>> work exists and that its not MIF WG's place to develop those further.
>>
>>     
>>>  However, how to do traffic flows handover 
>>> between interfaces in PMIP domain is not described. If MIF 
>>>       
>> capable node
>>     
>>> is located in PMIP domain, then this feature will be disable. 
>>> I am wondering if/when these works will be done in Netext(PMIP).
>>> Some PS and I-D had stated these issues as below.
>>>
>>>       
>> http://tools.ietf.org/html/draft-devarapalli-netext-multi-inte
>> rface-support-
>>     
>>> 00
>>> http://tools.ietf.org/html/draft-jeyatharan-netext-multihoming-ps-01
>>> http://tools.ietf.org/html/draft-xia-netext-flow-binding-00
>>> http://tools.ietf.org/html/draft-koodli-flow-handover-00
>>> Thus, personally propose this working item is included in 
>>>       
>> the charter 
>>     
>>> and making things progress. Thanks.
>>>   
>>>       
>> The MIF charter did not mention PMIP specifically, but the 
>> list was not 
>> intended to be complete. Multiple care-of address work in 
>> Mobile IPv6 is 
>> already being standardized, and PMIP multihoming is under 
>> consideration 
>> (currently heavily debated).
>>
>> In any case, MIF does not rely on Mobile IPv6 or Proxy 
>> version thereof. 
>> Those efforts are proceeding independently.
>>
>> Jari
>>
>>     
>
>
>
>