[Mip4] IETF-64 Minutes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mip4] IETF-64 Minutes
========================================================================
Mobility for IPv4 WG (mip4)
========================================================================
THURSDAY, November 10, 2005, 1300-1500
========================================================================
CHAIRS:
Henrik Levkowetz <henrik at levkowetz.com>
Pete McCann <mccap at lucent.com>
AGENDA:
1. Preliminaries 10 min Chairs
------------------------------------------------------------------------
- Minutes
- Agenda bashing
No comments on agenda
2. Document Status 15 min Chairs
------------------------------------------------------------------------
draft-ietf-mip4-rfc3344bis
New revision submitted right before the meeting.
Next: Chair writeup and publication request
Comments:
Henrik:
Charlie submitted a new version before the meeting. One request for a
new error number was done.
Charlie:
submitted the weekend before the deadline but it has been on the
website for a month and there has been no change.
Vijay:
the target is draft standard?
Pete:
we had some subsequent technical changes therefore we need to
recycle to proposed.
Henrik: Yes, we had indicated draft standard but people need to be
aware that we have done changes.
Vijay: not exactly sure what changes were made?
draft-ietf-mip4-vpn-problem-solution
Ready for WG last call
draft-ietf-mip4-dynamic-assignment
Waiting for AD Go-Ahead::AD Followup
draft-ietf-mip4-faerr
Waiting for AD Writeup
draft-ietf-mip4-reg-tunnel
AD Evaluation::Revised ID Needed
This draft has an Appendix which the authors don't agree
on how to handle. We've had an independent review of
the Appendix too, and need to decide what to do with it.
Comments:
Henrik:
Had a long and painful story. We may be splitting up the draft
into an appendix and the main part and then do the appendix as
informational.
draft-ietf-mip4-rfc3012bis
Waiting for AD Writeup
Several reviews done for AD,
Need to decide whether to fork off the Generalized
Mobile IP Authentication Extension as a separate draft.
Comments:
Henrik: Jayshree is doing the few changes..
draft-ietf-mobileip-lowlatency-handoffs-v4
IESG Evaluation::AD Followup
(Just re-submitted by Karim, ready to go to RFC Editor)
Comments:
Henrik: has been approved.
draft-ietf-mip4-rfc2006bis
MIP-centric review done, new revision needed
Comments:
Henrik:
Kent is going to do the review alone or with help. Hopefully
ready for MIB doctor.
draft-ietf-mip4-experimental-messages RFC 4064
draft-ietf-mip4-vpn-problem-statement RFC 4093
Comments:
Henrik: that is nice.
3. New charter 5 min Chairs
------------------------------------------------------------------------
http://mip4.org/charter/mip4-charter-2005-09-08.html
Comments:
Henrik:
Did not get to the IESG slate. No indication of negative
results. If you have comments, this is your last chance. We
have a new work items that will make into charters. Until that
is cleared, we will not take new work items. There are some
presentation are here for addition to the charter but that is
the bottom line at this point.
4. New WG drafts: 20 min Author
------------------------------------------------------------------------
Status summary, open issues:
draft-bharatia-mip4-gen-ext 5 min Kent
Presentation:
http://www3.ietf.org/proceedings/05nov/slides/mip4-2.pdf
Presentation by Kuntal.
The draft aims to send conf info from HA to the mobile during the
initial exchange.
Changes from -00 to -01 is formatting of configuration parameter
based on DHCP options, no longer MIP-specific
Also allows the MN to request config info from the home or visited
network and that at the same time if needed.
Here we reuse DHCP codes so you don't have to define new
subtypes. Adopted the DHCP option code structure and formatting.
received some comments on the mailing list and updated the draft based on that.
A generic extension to be used for the method was shown, including
type, length, entity-type (distinguishing between FA ad HA), and
config data (conf parameters are packed here).
an example of config parameters were shown.
open issues:only DHCP based parameters are considered. Do we have to
define non-DHCP parameters?
Comments:
Sri:
You may also need a default realm for DNS queries.
Pres:
You can basically piggyback DHCP info with this.
Henrik:
Can we define this as DHCP-only information and if we need
non-DHCP we define a different extension for that later.
Kuntal:
good idea
Yoshi:
DHCP option length
Kuntal:
If all the option are going to fit in one or multiple NVSE.
Kent:
We have talked among ourself on what to do with the DHCP versus
non-DHCP, we think we should built that at subtype level rather at
type level.
Henrik: either way works for me.
draft-devarapalli-mip4-mobike-connectivity 5 min ???
Presentation:
http://www3.ietf.org/proceedings/05nov/slides/mip4-3.pdf
Presented by Vijay:
Brief update from 00 to 01:
01 has been submitted with not
many changes, some based on Jari and TJ's reviews.the target is
going to a BCP doc. some additions on when this mechanism is
used. the idea is use this for IKEV2. and IKEv1 reference was
removed.
draft-sastry-mip4-string-extension 5 min Kent
Presentation:
http://www3.ietf.org/proceedings/05nov/slides/mip4-0.pdf
Presented by Kent:
Update since version 00:
update to 02 some changes regarding the revocation messages.
Changes on the use of message string extension, correction to
security considerations. Some changes based on TJ's comment and
addressed most of the issues.
Can we have some comments? it seems to be pretty straight forward and
should go to last call.
draft-nakhjiri-radius-mip4 5 min Madjid
Presentation:
http://www3.ietf.org/proceedings/05nov/slides/mip4-1.pdf
Presented by Madjid:
Update since version 01:
Clean up of the attribute section.
Review from Jari Arkko. There was a question on why the registration
request was being hashed. this was to avoid the attribute size issue
in the future if the reg. req gets too big.
Diameter can tell whether you are dealing with a HA or a FA. for
RADIUS you can do this only by some information in the
attributes. Something new is needed. A new MIP-Agent type
Some work remaining. More details on Diameter AVP-RADIUS attribute translations
Issue with MN-AAA authenticator and MFCE. please fix 3012bis.
Comments:
Vijay:
Don't agree with CCoA mode calculation in 3012bis draft
Kent:
Discusses already on WG. Folks agree there are 2 solutions in RFC 3012.
Henrik:
Take it to the WG alias.
Henrik:
We've had quite a bit of discussion with RADEXT chair and need to make
clear what we are doing here and how we separate that from what it is
done in Diameter. There should be a doc on this.
draft-koodli-fmipv4 5 min ???
Nothing to go over here.
5. IPv6 over MIPv4 and MIPv4 over IPv6. 5 min Chairs
------------------------------------------------------------------------
Taking on some work in this area has been discussed earlier, during
IETF-62. The question has been raised by some people again, in view
of the work on MIPv6 over IPv4 and IPv4 over MIPv6 which is being
done in the MIP6 working group.
Comments:
Henrik:
Authors have asked to reconsider this again. He likes to ask
for a HUMMM on which way to go. No decision is to be done here.
Hesham:
The aim is to allow the operator to do IPv6 over MIPv4 and a
similar work is done in MIPv6.
Kent agrees.
Vijay:
I like to discourage these sort of things in general. It is
better to move on to IPv6 rather to do run things this way.
Henrik:
Not everybody agrees plus there are specific cases that you simply cannot do it.
Hesham: Philosophically is better to force people on these things.
Rajeev K:
questions what is the relation between this and the traversal work in MIPv6.
Henrik:
this only deals with MIpv4 and not MIPv6 and that is why.
Kent:
the goal is to use one signaling protocol.
Pete:
chair hat off, I submitted this draft a while ago. It makes sense IPv6 over MIPv4.
Vijay:
personal experience. Operators are willing and want to move to IPv6.
Henrik:
we are not proposing people to not move to IPv6 here.
for information only how many people want to take this or not to take this on.
The HUMM for for is stronger than the HUMM against.
Mohan:
Scope of work?
Chairs:
Both drafts.
Related drafts:
draft-tsirtsis-v4v6-mipv4
draft-larsson-v6ops-mip-scenarios
6. GRE Key Extension for Mobile IPv4 10 min Parviz
draft-yegani-gre-key-extension
GRE (Generic Routing Encapsulation) [ RFC 2784 ] is one of the
encapsulation formats permitted by RFC 3344. GRE may use keys
to distinguish different tunnels from each other. [RFC 2890].
This draft proposes a MIPv4 extension to communicate GRE keys
between MIPv4 tunnel endpoints when requesting GRE tunnelling
for MIPv4 traffic.
Parviz presented.
3344 optionally supports GRE tunneling.
The proposal is to allow this tunneling.
there is a need for subscribers who are home in 3GPP. You cannot
really distinguish between traffic streams based on HoA, CoA. So we
need a new extension.
The idea is to allow both HA and FA to assign different keys (assymetric).
There are situations that these keys can be available to HA and FA.
But in 3344 the MN can set the G bit. Here we should be able to based
on policy overwrite the G-bit setting and request a GRE tunneling.
Henrik: clarification, we are talking about GRE key, not encryption key.
Mohan: is it for FA CoA or colocated mode
Parviz: no for both.
This is for FA CoA mode only.
Parviz: the HA can assign two addresses to the same subscriber because
it is private addresses.
back to presentation: GRE key assignment is outside of the scope. The
behavior of FA is new, the G-bit overwriting is not the in RFC. The
impact is that key allocated by the FA can be used for FA-to-HA use.
No changes to the MN behaviour.
Questions/ comments/ working group item?
Comments:
Kent:
good idea. When HA is wholesale, this is a good idea. Today the
only solution is to have different instances of HAs.
Pete:
I like the idea, it is done 3GPP2. But not comfortable with G-bit overwrite.
Parviz:
the final decision is by the HA and the HA can reject and
finally have a different tunneling.
Henrik:
what happens to MN-HA-AE if you can the G-bit?
Parviz:
G-bit in the GRE extension is not changed.
Kuntal:
why would the MN care whether you are GRE or not? why does
have to be based on MN request.
Kent:
when the tunnel is between FA and HA, what is the role of MN?
this is breaking the paradigm of the 3344.
Sri:
consistent. The extension is added by the FA.
Parviz:
which entity should assign those keys, FA or HA or both.
Kuntal:
both. the key that FA wants to receive should be specified by
the FA and the one HA wants should be assigned by HA.
Kent:
Unidirectional and bidirectional should be supported. HA should
be able to assign the keys for both sides.
Kuntal:
can't see a use case for when we want the HA to allocate both.
Pete:
receiver should allocate the key.
Kent:
agree, it is ok for the HA to allocate the key, technically.
Henrik:
may simplify what FA wants to do, but does not simplify the FA code.
Kent:
don't think implementation pov either way is harder.
Kuntal:
should we really have to have both options in the draft.
Henrik:
proposing to have the receiver assign the keys.
Kent:
Agree with everything but it does not hurt to add it and make it optional.
Kuntal:
how does the FA know what sort HA is it talking to.
Henrik:
Kent to propose some text and take it to the list.
7. Generic Notification Message for Mobile IPv4 10 min Hui
------------------------------------------------------------------------
draft-deng-mip4-generic-notification-message-00.txt
This document proposes a protocol enhancement that allows Mobile
IPv4 entities to asynchronously send and receive explicit
notification messages. The Registration Revocation mechanism of RFC
3543 could have been specified using a message such as the one
proposed here, had it been available at the time.
Presented by Hui
Presentation:
in some cases, there is a need for MIPv4 entities to send and rx
asynch notification events during a session. 3344 does not provide
specification for this.
This doc defines generic message and notification model for this process.
does not define specific notification extensions.
some examples are presented.
HA initiates a notification to MN, FA initiates a notification to MN, another case.
Generic notification msg send by mobility agent to inform another
mobility agent or a MN.
3 flags were defined
flag A, bit identifies if ack to the notification msg is need.
other fields of the message were defined.
issues: to discuss whether a notification MUST be acked and whether
the use of flag is good or not.
issue 2: R bit in Agent advertisement
usage examples were presented:
registration revocation, asynch. user notification (out of credit,
coming service interruption), asynch MN or agent notification, may be
necessary for high availability scenarios with long reg. life times.
Comments:
Henrik:
comments on the issues and the general idea
Kuntal:
similar in MIP6 regarding HA switch. I think this is a good
idea, but I am struggling with the use cases and who will be doing
this. Why would you notify the HA when the system is going down, and
create more traffic.
Hui:
Just one BS with access channel in cellular won't cause that much traffic.
Henrik:
you are not sending 1 Million notification, it is good idea to
cover in the draft for planned maintenance, when you notify that you
want to take the HA down in so and so hour.
Kuntal:
still you may have thousands of MNs maintained by HA, still
that is a lot of messages.
Henrik:
This a small subpercentage of the overall traffic.
Kuntal:
why not use reg. revoke. why this one?
Henrik:
Are you supposing that we should do this using another message? don't agree.
Kuntal:
reg. revoke is done today.
Kent:
make this optional, not mandatory.
Henrik:
We should put our foot down and say no if we think something
is causing a lot of problem (personal opinion).
Hui:
3GPPX wants to use SIP SDP for this.
Parviz:
not sure I can see the use case scenario for this.
Hui:
the real scenario is HA switch.
Sri:
don't focus on where it is used, but focus on whether this is
useful or not. example is prepaid.
Kuntal:
last comment on prepaid and people use text messages for that
purpose. HA has no business sending notification to the MN when
account is up. for MN-FA notifications you would need specific
bootstrapping methods. If something is already solved in the industry
we don't try to go and design a new solution.
Kent:
right now the revocation only goes to FA, but not to the MN, so
it may not be the right way to do it but we do have a MN-HA
association. In deployments people don't completely shut down the HA
anyway, but if you want to do that more power to you.
8. Mobile IPv4 Fast Handovers for 802.16e networks 5 min Junghoon
------------------------------------------------------------------------
draft-jee-mip4-fh80216e
IEEE 802.16e is an amendment of 802.16 ("WiMAX") which extends it
from fixed terminals only to fixed and mobile operation.
This document describes how Mobile IPv4 Fast Handover can be used
IEEE 802.16e link layers.
Presented by Junghoon.
Presentation:
rfc 4068 is a work item (FMIPv4), so he proposes fmipv4 over 16.
some of related work is done in MIPshop, so he is mentioning.
some mobility is done in layer 2.
predictive and reactive (??) modes were discussed.
Is there interest in this work? is this a topic for this working group?
Comments:
Pete:
the problem is that FMIPv6 over X is supported in MIPSHOP, but
they have strict charter on v6. Should we get into FMIP stuff here?
Rajeev:
True, may be it should be here.
Parviz:
why just 16e? should be FMIPv4 over anything?
Pete:
you need to take the specifics of the link to make it working.
Hannes:
it is good stuff.
Kent:
it is interesting.
Henrik:
I can predict problems down the line when we want to go for publication.
9. Using multiple interfaces for increased throughput 5 min Srinivasa
------------------------------------------------------------------------
draft-srinivasa-mip4-mir-00.txt
This document defines enhancements that allow a MN, when away from
home, to simultaneously use multiple connected network interfaces
so as to obtain higher aggregated bandwidth.
Henrik:
Author is not here. it is interesting work. uses multiple
interfaces to stream videos to remote villages in India because the
existing cellular systems and it is actual deployment. It is mature
for adoptions. As an example of what you can do in a multiple
interface scenarios.
Attachment:
signature.asc
Description: OpenPGP digital signature
--
Mip4 mailing list: Mip4 at ietf.org
Web interface: https://www1.ietf.org/mailman/listinfo/mip4
Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
