Re: [Mipshop] MIPSHOP discussion on new items and milestones

[Takeshi Ogawa <[e-mail]>]

Hi Gabriel,

I agree with Rajeev on "FMIPv6 itself".

I proposed a new dhcp-extension for fast handovers in last 
mobopts meeting that require no handover specific function 
on access routers. Combining it and "tunnel buffering" in HA 
proposed by Moor, seamless handovers can be achieved. I 
suppose it would be useful in a specific circumstance where 
it is difficult to add new functions to access routers in a 
service area.

However, except the such circumstance, I believe current 
FMIP itself has no major issues and it is solid enough to be 
PS. Many groups including us have verified its basic 
feasibility in their test systems, and we are looking 
forward to it being PS soon.

I hear dna people chose two approaches, one is adding new 
function to access routers and getting best DNA, and the 
other is using current access routers and getting better DNA.

I suppose we can go similar way.


 
-Takeshi.

Rajeev Koodli <[e-mail]> wrote:

> 
> Hi Gabriel,
> 
> gabriel montenegro wrote:
> 
> > Folks,
> >
> > Thanks for the excellent exchange so far. At this point, based on what 
> > I've
> > seen, I'd like to share with you how I'm seeing things.
> >
> >
> > MN-AR security
> >     seems like there is sufficient interest and this item is
> >     narrow enough to warrant further work on the SeND key
> >     reuse method as well as to develop a AAA-based solution.
> >     Whereas we believe there may be some IPR-issues to clarify
> >     with the SeND based approach (in spite of Jim's interpretation)
> >     we don't have the same clarity with respect to the AAA approach.
> >     Please come forward with your IPR disclosures on this. This is not
> >     optional.
> >     
> >     looking at 2 PS documents.
> >
> > FMIPv6 itself
> >     I'd postpone this item given that we don't have a clear 
> > understandiung
> >     of what the exact relationship with DNA, CARD, 802.21 and the 
> > forthcoming
> >     neighborhood discovery is (and heck, there's even a proposal for 
> > dhcp).
> >     I'm inclined not to include it for now
> >     until we know more, and look into it again until a few months have
> >     gone by and we have a better grasp of the security and the discovery
> >     portions. The former to continue here, the latter to continue 
> > elsewhere
> >     (e.g., mobopts).
> >
> Clearly, I am a bit surprised at this. We would work on 2 PS documents 
> for MN - AR
> security but not on the spec for which those two PS documents are meant 
> for?
> 
> Also, I don't think the relationship wrt other work is unclear.
> 
> DNA: works for reactive FMIP when no neighborhood information is available
> CARD: re-uses FMIP messages for MN - AR interaction. (This is in the 
> CARD spec)
> 802.21: Provides triggers in a "Media-Independent" way. Should help FMIP.
> 
> What am I missing here? I didn't hear anyone express the "lack of 
> understanding"
> as you put it. But I remember Jim Kempf saying some work can be done on 
> Neighborhood
> discovery in MobOpts.
> 
> Also, if folks want to work on extensions of FMIP (e.g., dhcp 
> extensions), it is
> up to them. That cannot be the reason to deduce that there is less clarity.
> 
> -Rajeev
> 
> 
> 
> > FMIP-over-cdma
> >     This experimental document is a useful exercise to better understand
> >     deployment considerations and the above issues. It's also good in 
> > that
> >     it encourages another SDO to seriously think about this, even if 
> > it is
> >     in a preliminary manner (I don't believe they have firms and urgent
> >     deployment plans). I have heard of at least two groups of folks in
> >     the working group interested in this. You know who you are, and you
> >     should work together on one document. Highly desirable: go through 
> > the
> >     regular channels (ietf liaisons) and produce a document from 3GPP2
> >     on this subject.
> >
> >     looking at one informational document
> >
> > MN-MAP security for HMIPv6
> >     I'd like to think that such an item could be included, but we do 
> > need to see
> >     a draft on this subject in very short order. Conceptually, it does 
> > not seem
> >     a much more difficult problem than MN-AR security, so depending on 
> > how quickly
> >     the relevant draft can be produced, this could be entertained. It 
> > seems to me
> >     that without this piece in place, talking about other HMIP work in 
> > MIPSHOP
> >     is premature (but it should continue elsewhere). Like FMIP, other 
> > work could
> >     be taken on later on.
> >
> >     perhaps (if a first solid draft appears shortly) one PS document
> >
> > RO issues
> >     Not clear how much of EBU is new and how much is just further 
> > language on
> >     rfc 3775. At any rate, it does seem like a CGA-based scheme could be
> >     worked on (heck, the basic concept has been around for ages), using
> >     omip as a starting point. Highly desirable: go through the ietf 
> > channels
> >     and using the proper liaisons obtain a message from the SDOs 
> > reputedly
> >     interested in this item. This document would have the precondition 
> > for
> >     CBA (authenticated notification of CoA change to the CN). Ideally, 
> > we'd
> >     have a very simple CBA scheme in place as well.  Both of these 
> > mechanism
> >     would be optional (i.e., we're not in the business of replacing RR).
> >
> >     looking at one PS document.
> >     
> >
> > This gives us a lot already, perhaps too much:
> >     (up to) 4 PS documents (perhaps 3)
> >     1 informational document
> >
> > I don't think we want to take on any more load for now. As we complete
> > items, we will look into it (as we are doing now).
> >
> > This may not be everybody's favorite list, but hopefully it works 
> > reasonably well
> > (or at least *maximizes the distribution of unhappiness*, as Brian put 
> > it at the plenary).
> >
> > comments? close enough, way off?
> >
> > -gabriel
> >
> >
> >
> >
> >     
> >
> > _______________________________________________
> > Mipshop mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> 
> 
> _______________________________________________
> Mipshop mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop


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