Subject: RE: [Mipshop] MIPSHOP discussion on new items and milestones

From: [email-masked]
Date: Fri, 18 Mar 2005 12:52:52 -0600

Hi Jari,

>Hi Basavaraj,
>
>Let me ask a clarifying question. You wrote:
>
>>Return routability enhancement and new route optimization techniques
>>are topics that are probably worth more thought. One possibility that
>>has been discussed previously is that the RO and RR enhancement work
>>be discussed in a focused and scoped manner in the MOBOPTS RG. And
>>based on a better understanding from such an exercise we could
>>standardize them in either MIPSHOP or MIP6.
>>  
>>
>I'm trying to understand your proposal. Is your suggestion that the
>Charlie's and Francis' work on RO security methods be moved to the
>IRTF? Or are you suggesting some kind of a split where some methods
>are pursued in the IETF while some others are sent to IRTF and
>standardized only later?

Just as a clarification, I am not suggesting that the Precfgkbm 
and cn-ipsec IDs be moved to the IRTF. If you look at the history of
the MIP6 work, there was an intention to include the precfgkbm work in
the base spec itself. However it was decided to separate it from the
base protocol specification. And that is why the current charter
specifically mentions that the WG would standardize this feature. My
view on Francis' I-D is that the cn-ipsec solution is along the same
lines as Charlies precfgkbm I-D (albeit the use of an IPsec SA). Hence
we decided to accept it as a WG item.

Both these RO solutions are not really applicable for large-scale
deployments. RR based RO is the only method that can be used if we are
to deploy MIP6 on an Internet wide basis. These schemes are for
limited deployments and has been clearly stated as such. 

Alternative (to RRT based mechanism) RO solutions are to me at least
worth further investigation and hence my suggestion for doing this
work in Mobopts. 

>
>If its the latter, what kind of criteria do you think we should apply in
>selecting work that gets done now vs. later? (From where I stand it
>looks like we have the wrong priorities. But it would be helpful if we
>could discuss the priorities, and the reasons for them, rather than
>just saying that something goes forward and something does not.
>Then no one would need to guess what the motives are. And we
>might even learn something about the applicability and limitations
>of various schemes.)

So lets clear up any confusion or misunderstanding that may exist:
There is NOT an immediate need for an enhanced or alternate RO scheme
for MIP6 today. It makes sense to get some experience with the current
RO solution specified in the base specification before deciding that
we need to take on new work. Solutions such as precfgkbm and cn-ipsec
IDs are not really in the same category as the RRT based RO scheme
since their applicability is quite limited. 
One of the tasks that the Mobopts WG was going to undertake was
understanding the performance of the current RO scheme for
MIP6. Shortcomings, security issues as well as enhancement suggestions
coming out of such work could be undertaken in the MIP6 WG. But at
least we would have some basis for doing the work.

>--Jari

-Basavaraj

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Mar 2005 21:44:10 +0200

Hi Basavaraj,

>base protocol specification. And that is why the current charter
Yes, although it isn't all that different situation for CGA either.

>limited deployments and has been clearly stated as such. 
(snip)

>MIP6.
So are you saying that in your opinion there is no need for immediate
RO enhancement and that's the reason why general purpose mechanisms
are not needed at this point in time? I can understand this argument,
even if I don't necessarily agree. But I have harder time understanding
how we simultaneously need to progress precfgkbm and cn-ipsec
if, as you say, there is no need and, in addition, the solutions have a
limited
applicability.

Note that I'm not proposing that the one or two new methods be made
mandatory, or be forced upon anyone. But in order to put this in our
products we need to be nice and allocate suitable option numbers.
All I'm asking is a level playing field, the same chance
that other schemes of similar maturity and history (precfg~cga~
ipsec) have been given.

--Jari