Re: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00

[Qin Wu <sunseawq at huawei.com>]

Hi,:
What I feel for the current PS I-D is IPv4 aspect is a little bit fatter than IPv6 aspect.
I agree we need to focus on LR for IPv6 and some of issues in the IPv4 aspect are not
 big/urgent issue which may complicate LR signaling design,e.g., Private IPv4 addressing, 
we can delete it if there is no interests on it. But I am not sure we need to remove all the
IPv4 aspect and narrow the scope to the LR for the only IPv6 aspect. 

Given the current IPv6 deployment,the transition from IPv4 to IPv6 is still a insurmountable phase. 
Also there are some existing relevant work in IETF,e.g, draft-ietf-netlmm-pmip6-ipv4-support-17,
but LR aspect is not covered. And 3GPP provided some standards to support dual stack operation.

So I am wondering 
1)Is there any pragmatic IPv4 issues that needs to be addressed in the LR PS draft but not necessarily to be covered by PS solution work?
2)Whether we should obviate all the IPv4 part from the LR PS draft? How about shortening and even dropping some of the text.

Regards!
-Qin
----- Original Message ----- 
From: <Basavaraj.Patil at nokia.com>
To: <netext at ietf.org>
Sent: Thursday, September 24, 2009 4:05 AM
Subject: [netext] Issue with I-D: draft-ietf-netext-pmip6-lr-ps-00


> 
> Hello,
> 
> Regarding the scope of localized routing for PMIP6, I believe the
> current PS I-D has some issues w.r.t the following:
> 
> 1. Localized routing for IPv4 HoA (Sec 3.3.1)
> I do not believe we should work on supporting LR for IPv4 HoA at this
> time. Given the possibility of multiple MNs with the same IPv4 HoA
> (RFC1918 addresses) in a PMIP6 domain, we will be bogged down on this
> capability. Lets just worry about LR for only the IPv6
> prefix/address. 
> 
> 2. Transport network between the MAGs (Sec 3.3.2)
> Rather than making assumptions about the capability of MAGs in a PMIP6
> domain, and defining negotiation mechanisms, we can make an assumption
> that MAGs support IPv6 transport. Keeping the scope constrained will
> ensure we get something done here.
> 
> So I would recommend (with chair hat on) that we delete secs 3.3,
> 3.3.1 and 3.3.2. 
> 
> -Chairs
> 
> _______________________________________________
> netext mailing list
> netext at ietf.org
> https://www.ietf.org/mailman/listinfo/netext