# Monami6 WG Minutes, 64th IETF, Vancouver, Nov. 2005
- Notes taken by Will Ivancic
- Completed with notes from Thierry Ernst, Koshiro Mitsuya and Jabber logs.
- Get presentation material from
- Get them also from http://www.nautilus6.org/ietf/ietf64
- Jabber logs: http://www.nautilus6.org/ietf/ietf64/monami6-ietf64-minutes-jabber.xmpp.org.rtf
# 1. Monami6 welcome and introduction (5min.)
# 2. Agenda Bashing (5min.)
Presented by Thierry.
# 3. Charter description and explanation (10 min.)
Charter presented by Nicolas. See slides.
TJ - how are we to interact with other working groups such as NEMO
Thierry suggested interaction by all members via participation on
various working groups, but as chair of both NEMO and Monami6
Thierry will make sure about this at least for NEMO.
# 4. Motivations and Scenarios (10 min.)
# (Goals and Benefits of Multihoming, draft-ernst-goals-and-benefits)
# by Thierry Ernst
See slides. (Milestones should be read as "2006", instead of 2005)
Q/A: Multiple input from the floor, summary: - need distinction
between multi-homed and multi-addressed and multi-interfaced. When we
need to make a distinction between multi-addressed, multi-interfaced
Hesham: termilogy, need distinction between multihoming and
multiaddressed. There are scenarions with different actions
Henrik: different definitions is confusing. Choose different terms,
multiple iface = multihoming, if not pick another word. Can help to
find a word.
Erik: historically: back to RFC, no distinctions. Confusion because
of that. Useful to have a term which covers the union of the 2, and
one to make the distinction. Make sense to come up with a term that
better cover the union of the 2 ?
Tim Sheppard - In what situation would one have multiple prefixes
and not be multihomed?
Hesham. Good to make that distinctions. Not against using mhoming
to cover both, but need to be able to have terms which cover one but
not the other.
Henrik: actually happy to use any term. (as long we agree, and we
need to establish this terminology if it's not established yet
Take terminology to mail list.
Eric: Need to distinguish between host multihoming and site
multihoming - particularly with regard to shim6.
Erik: not finished read. In this document: going from the host
aspect to site multihoming: become confusing when doc speaks about
multihomed routers (MR -> multihomed site => making it clear =>
things common with the bigger picture. Would make the document
clearer and easier to undersatnad bigger pidure.
Jim Bound: Do you want to address this situation, not sure. Do we
need to consider manet technologies?
Answer by Thierry - This WG is directed toward mobile-ipv6 and nemo.
Poll and conclusions:
- 20 people have read the doc.
- 40 OK for WG item - no opposition
- Document will become working group
- Renamed, probably to draft-ietf-monami6-scen-motivations
- Confirmation on the ML
# 5. "Analysis of the use of Multiple Simultaneous Care-of Addresses and Home
# Agent addresses in Mobile IPv6" (15 min.)
# by Nicolas Montavont
# Discussion: adopt as a WG document?
# Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-18/sld1.htm
Nicolas goes through the description of the draft. See slides
Hesham: Is focus on CoAs or multiple HoAs? Discussion in Paris
indicated that focus would be in mulbiple CoAs?
Nicolas replies: WG focus on multiple CoA/several HA addresses
HS: strange because some is not related to mobility in the draft.
Erik: The 2 documents are actually broader than the solutions to be
provided by Monami6. Covering the important stuff.
Hesham: different prefixed for all HAs, or the same ?
Erik: Standardized multiple CoAs may result in multiple HoAs.
Tunnel may have multiple addresses at either or both ends. Doesn't
mean the MN has multiple HoAs. For this case, you need a Shim6
solution. You can seperate up the concern about these two cases.
Jim Bound: Having read all the specs. It points Shim6 is ongoing
work. Don't agree there all in one HA. MN can have multiple HoAs -
2, 4, 6 or more. Question to the chairs - (didn't catch all)
WG willing to work on operational paradigms ?
Thierry - Need help from people with operational
expertise/requirements. Let's take this to the mailing list.
Pekka Nikander (PN) - Recommendation: Keep it simple. Avoid
complexity and trying to solve all problems. There is a lot of
other areas working mobility problems and the space is in flux with
new proposed solutions.
Question from Thierry: Is description too complex? There is an
ppportunity to describe all the issues as done in NEMO WG for NEMO
Basic Support (draft-ietf-nemo-multihoming-issues).
PN - Be careful about idendity and locators. When doing the
analysis, what is the identify, what is the locator. Clarify when a
HoA is a locator and when it is an identifier
Eric: Agree there is a risk. Getting those description correct is
difficult. We need to understand enough as a WG that those solutions
will fit a bigger picture, but no need to describe what is a locator
or an identifier."
PN: Try to keep it focus and narrowed, but if you want to go wider,
you will enter this subtilities.
HS: You would be boiling the ocean if you would describe everything,
but understand it's not what you want to do. If analysis is
describing general issues and work documents are focused, that is
Poll and Conclusions:
- 10-15 people have read the draft
- 30 agree as a WG doc, nobody agains.
- Hesham: Only ten read document. Can group have a week to read and
respond before acceptance as working group?
- Thierry: Item will be confirmed on the mailing list. Initial
response from those that read document was positive.
# 6. Implementation report and virtual interface usage (5 min.)
# by Yong-Geun Hong
# Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-12/sld1.htm
See slides. Try to adap MIP6 and NEMO BS codes. Got comments on the ML before
Eric: How would DNA and other movement detection apply here?
Layering virtual interfaces on top of physical interfaces may be
YongGeun: Will look at this.
Ryuji W: SHISA implementation supports virtual
interfaces. Implemented in a different way. Also, look very
implementation specific. What are main issues regarding
Floor: Appears implementation specific.
Jim Bound: Good work, but needs to understand that people may have
to change there code. Needs lots of discussion. It should be part
of the group that this particular draft should be followed up.
Will Ivancic: Be careful how virtual model interacts with multiple
physical radios. Could cause problems - particularly if layer-2
triggers come about.
# 7. Accept Multiple Care-of Addresses Registration as a WG item? (15 min)
# Ryuji Wakikawa
Q/A on slide 4 (issue 2)
Hesham: BID appears better than "old CoA"
Eric: BID appears more robust.
Vijay: Question, how does one search binding cache update. Home
address is still an identifier, not always required to combine with
Hesham: 16bits is too much. We need to consider bandwidth when
development. Perhaps 8 bits vs 16 bits with 8 bits in reserve.
Ryuji: Right. Explains why it's currently 16, not important reason,
just for convenience: most of implementation is using 16 bits for
Alex: we always search the BC (this is implementation
dependant). This will probably lead to assign the BID to an
identifier to the host ? [Ryuji: no] To multiple identifiers to the
ChanWah: How are your going to define a new structure ? (separate
entries, or new field)
Ryuji: 100% implementation specific
ChanWah: Don't think it's implementation specific. You need to
define the conceptual data structure. You need to modify the
conceptual data structure of MIP6, because it would help to describe
how to look for CoAs.
Q/A on slide 5 (issue 3)
Hesham: Is "primary" CoA necessary?
Hesham: MN with two home addresses registers them home. What happens
when multihomed MN returns home? Either you come home or you don't.
Ryuji: Impossible with the current MIP6 spec. The HA defends only
one address currently. Which of the two will the HA defend?
Answer: If any interface moves home, remove all CoAs.
Ryuji: Perhaps terminology policy. All agree in general how system
should operate. When home, some interface needs to be "effectively"
disabled. Either the HA interface or the CoA.
Benjamin: Sorry guys sometimes I can't understand. Flags are scare.
Vijay and Hesham commented on Flag in BU and DHADD. [please comment
on mail, what was resolved was not catched up by the minute takers]
-- Vijay: difference between using a flag and a mobility option; a
flag is non-skippable; an mobility header is...
-- Vijay: extension of DHAAD is unnecessary
-- Hesham: agree, we don't want to extend DHAAD step when we have
Q/A next steps: How to proceed. Should document be WG document?
Hesham: Document is good, this is framework. Later on, if we want to
provide policies, this would be possible. Don't have anything
against with this doc, but should be processed at the same time as
the policy doc.
Alex: Is policy design team needed ? This may be going too fast.
ChanWah: Perhaps not enough requirements yet from the industry side.
Basavaraj: work has been presented for a couple of years. No reason
to delay. Should proceed forward. No need to discuss requirement
from the industry and so on.
Alex: Work should proceed and WG document.
Hesham: It is not constructive to wait for new drafts to show up.
We should proceed.
Poll and Conclusions:
- 40 people have read the draft
- 20 support this doc as WG doc. Nobody opposes
- Consensus of room is to proceed as WG document. Will take to mail
list for confirmation.
# 8. IKEv2 and IPsec issues with multiple CoAs (15 min.)
# Vijay Devaparalli
# Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-14.pdf
Erik: When doing forwarding over multiple CoA's things can get out
of order? Mobike doens't do this. ISPs would thrtough away some
Vijay: When sending a packet on 1 iface, then on anoter, you mean the
sequence number may be stuck [???]
Erik: Try to use a single IPsec SA for multiple flows and going
through a single CoA.
Hesham: Couldn't work at all.Use one primary CoA for HoTI and CoTI
but we can't use same SA over multiple interfaces.
Erik: Does one flow use one CoA and therefore one SA ?
Hesham: as far as protecting MIP6 signalling, pick one address for
HoTI and CoTI. But if we want to protect multiple interfaces then
there should be multiple SAs, unless VPN gateway.
Francis: Issue 8 in MOBIKE is similar.
Vijay, all: Yes (laugths)
Francis: Issue 8 is multiple address change. USe one IKEv2 session
to manage the different CoAs.
Vijay: if you have to have multiple exchanges and multpile SAs then
it becomes a pain.
# 9. Discussion on A "Flow/binding policies exchange" solution for an
# exchange of policies from the mobile host/router to the Home Agent
# and from the Home Agent to the mobile host/router influencing the
# choice of the Care-of Address and Home Agent address" (20 min.)
# Hesham Soliman
# Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-16.pdf
Multiple drafts address problems. Many have similar solutions. All
agree to use the BU/BA to set filters for different flows. Receivers
of the BU would route according to the filters received.
Documents will be merged. Differences are very minor and should not
impede the merger.
Mobile host issues appear easier to mobile router issues. Need a lot
of work ensuring group address all significant issues.
Out of Scope is Local Policies due to this being a implementation
Need more discussion on the MR side; MN side is clear.
Floor: Traffic flow templates [as defined by 3GPP ?] have possible
Sri: Can one prioritize interfaces and how?
Hesham: Good question, we touched on it on the last slide. Simple
case, some intelligence on the MN. Other case, MN behind
MR. Information should be sent on the link (discover capabilities
should be considered for this). How far along the path should one
go to discover capability.
Thierry: What is next step for this ? Should this item done in the
Monami6 WG ?
Hesham: Not sure, but certainly needs to be discussed. May be
analysis document ?
Calrsten, floor: Couple of other differences between the existing
propositions on the table. Binding flows to different CoAs [...],
dropping or splitting a flow [...]
Hesham: Did not bring up intentionally at this time. Concerned
about middle boxes dropping packets, not mobile node. HA doing it
unilateraly would be dangerous.
- Hesham: Start on what we agree on. Combine documents by next
IETF. Set up an issue tracker. 5 or 6 issues to discuss.
# 10. "Benefits of multiple care-of addresses and home addresses for low
# power multimode mobiles" (10 min.)
# Shiao-Li Tsao
# Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-19/sld1.htm
Turn on multiple interfaces consumes up to 30 percent of power even if
inactive. Want to add text in "Scenarios and Motivations" doc. Want to
add text in the MIP6 analysis doc.
Floor: Is assumption that different services are provided by same
Shioa-Li: No, assumes different ISPs
Floor: Then ISPs will not be able to route your addresses.
Hesham: HA is tied to physical address resulting in multiple
- Thierry: Be more precise on mail list about which text you would
like to see added in the oter documents.
# 11. Conclusion and next steps (5 min.)
# Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-15.pdf
This document was updated during the meeting and presents the
conclusions reached during the meeting.
Documents 1, 2 and 3 accepted as WG. Will be confirmed on the ML.
#3 should be proceeded at the same time/pace as #4
WG item 4, merge 3 existing drafts into one. Set up issue tracker.
Potential Next Steps:
- Move multihomieng activity from NEMO WG? HAHA ?
- Discover capabilities between RM and MNNs ?
- Work on seamless handover?
- Margaret points out that the WG was accepted based on the current
charter (very focused).