Hi Rajeev,
> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev.koodli nokia.com]
> Sent: Monday, November 27, 2006 11:23 AM
> To: Narayanan, Vidya; Alper Yegin; Vijay Devarapalli
> Cc: mipshopietf.org
> Subject: Re: FMIPv6 Security (was Re: [Mipshop]
Confirmation
> on decision onHMIPv6 Security)
>
>
> Hi Vidya,
>
> We have some results on WLAN and EV-DO VoIP handovers
which
> suggest the need for something faster than MIP Binding
> Update. The paper is under submission.
>
When you have it, I'd be interested in reading the paper.
Also, I agree
that we need something faster than MIP for seamless
handoffs. The
question was about whether we need MN involvement and I
think we are in
agreement about that.
> The decision to involve a MN in signaling is
> deployment-specific (which includes "market
dynamics", case
> in point PMIP). I am okay with taking the base FMIP
protocol
> and adapting it as such. It would not be desirable to
go off
> and spend many months (or years) re-designing a
"new
> protocol" under the pretext of network-based
signaling. If
> you think through it, you will perhaps realize that
there is
> not much more to do from a protocol design standpoint.
So, I
> hope we pool our energies together to standardize one
good
> design and let the industry take its own course on
deployment.
>
No disagreement here. I also think that a network-based
design doesn't
require too much more - it is a question of adapting FMIP
for such a
design.
> I agree that the messages in network-controlled
signaling in
> draft-3gfh need to be harmonized with FMIP signaling; I
don't
> understand why they are not HI and HAck.
>
> Finally, we should work on IP-based protocols here,
> acknowledging and even adapting such protocols over
some
> specific link layers of interest. That's what we are
doing
> here in MIPSHOP (bis, fmip-over-XX). That's what we in
an
> IETF WG are arguably capable of doing. Deployments are
> another thing and while they clearly matter to us, the
> parameters there are far broader than we can
effectively
> address here. So, I would not want to be all carried
away by
> that. Let's stick to good protocol design, making use
of
> meaningful input.
>
Agreed. I was only trying to stress that we should not be
requiring 6
messages to establish FMIPv6 security.
Regards,
Vidya
> Thanks,
>
> -Rajeev
>
>
>
> On 11/27/06 10:41 AM, "ext Narayanan, Vidya"
> <vidyanqualcomm.com> wrote:
>
> > Hi Rajeev,
> >
> >>
> >> Hi Vidya,
> >>
> >>>
> >>> There is no operator that currently wants
to run FMIP,
> >> given that it
> >>> introduces additional signaling over the
air, every time
> >> the AR changes.
> >>
> >> Where did you get such a conclusive and
comprehensive
> evidence? I ask
> >> because it can be very useful if turns out to
be the _only_ reason.
> >>
> >
> > I should have said that I am not aware of any
operator
> wanting to run
> > FMIP at the moment. If anyone is aware of an
operator thinking of
> > FMIP, I'm interested in hearing about it. The only
reason
> I've heard
> > is the signaling part.
> >
> >> To put things in perspective: there is one
message (FBU) to effect
> >> route change, and one message to announce
attachment
> (FNA). In fact,
> >> FNA is an ND message with a different Type
Number. The
> neighborhood
> >> discovery messages are discovery messages,
which could be combined
> >> with L2 signaling or omitted if there are
other means of obtaining
> >> that information.
> >>
> >
> > I agree with the above. However, we have to look
at the
> alternatives
> > and see if those are any better/faster/more
efficient. I think FMIP
> > has value for inter-technology handoffs between
border ARs.
> Within the
> > same technology, we are likely to see just
network-based
> edge tunnels
> > setup and torn down quickly based on L2 IDs. There
is
> really no reason
> > to involve the MN in signaling for short-lived
edge tunnels.
> >
> > For inter-technology handoffs, that is normally
facilitated
> by having
> > multiple radios on the mobile - if so, there needs
to be
> overlapping
> > coverage areas between those technologies to even
have a seamless
> > handoff to begin with (if there are gaps at the
PHY layer,
> nothing we
> > do will make the handoff seamless). If there is
overlapping
> coverage,
> > one can envision setting up the FMIP tunnel and
then using the new
> > interface. Even there, it needs to be rather quick
- but,
> something at
> > the IP layer is needed, since the L2 IDs are not
compatible across
> > technologies. One could argue that if the
inter-technology
> coverage is
> > overlapping, there may be sufficient time to
update the MIP binding
> > and hence, no FMIP is needed. That remains to be
seen. But,
> I do think
> > that FMIP is a good candidate for inter-technology
fast handoffs.
> >
> >> FYI: There is network-based FMIP signaling in
> >> draft-ietf-mipshop-3gfh-01.txt
> >>
> >
> > IMHO, that is not FMIP. It is a new protocol with
its own
> messages. It
> > doesn't seem to have anything in common with
RFC4068. I do
> think that
> > a network-based flavor of FMIP would be useful to
standardize, but,
> > that's not RFC4068 or rfc4068bis.
> >
> >> I think we (especially informed folks) should
keep things in
> >> perspective while making bold statements.
> >>
> >> I agree that adding more signaling is
something we should avoid.
> >>
> >
> > Yes, this was the ultimate message I was trying to
convey 
> >
> > Vidya
> >
> >> -Rajeev
> >>
> >>
> >>> If there is someone who wants to allow an
additional 6-message
> >>> exchange with the MN to create SAs for
securing FMIP, sure
> >> - that is their call.
> >>> But, this clearly is not the typical case.
> >>>
> >>
> >>
>
>
_______________________________________________
Mipshop mailing list
Mipshopietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|