Last Modified: 2004-10-01
Done | Submit terminology and requirements documents (for Basic support). | |
Done | Submit NEMO Basic Support to IESG | |
Done | Submit WG draft -00 on Threat Analysis and Security Requirements for NEMO. | |
Done | Submit WG draft -00 on Multihoming Problem Statement | |
Done | Submit WG draft -00 on NEMO Basic Support Usages | |
Apr 04 | Submit Terminology as Informational to IESG | |
Apr 04 | Submit Goals and Requirements as Informational to IESG | |
Apr 04 | Submit WG draft -00 on Prefix Delegation for NEMO | |
May 04 | Submit WG draft -00 on MIB for NEMO Basic Support | |
Jun 04 | Submit WG draft -00 on Analysis of the Solution Space for Route Optimization | |
Aug 04 | Shut down or recharter the WG to solve route optimization |
NEMO Working Group - IETF 61 ============================ Wednesday, November 10, 2004 Scribes: Marcelo Bagnulo, Masafumi Watari Jabber scribes: T.J. Kniveton, Alexandru Petrescu Agenda: ------- 1. Agenda, welcoming, etc .....................................05mins Chairs 2. NEMO WG Status............................................. 05mins Chairs Terminology and Requirements draft-ietf-nemo-terminology-02.txt draft-ietf-nemo-requirements-03.txt Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo NEMO Home Network Model draft-ietf-nemo-home-network-models-01.txt IPRs on NEMO Basic Support 3. NEMO Basic Support (draft status).......................... 20mins Vijay Devarapalli draft-ietf-nemo-basic-support-03.txt Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html 4 NEMO MIB Design ........................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt 5. Announcement: 6th TAHI interop test event ................. 05mins Yukiyo Akisada 6. Prefix Delegation ......................................... 10mins TJ Kniveton draft-kniveton-nemo-prefix-delegation-00.txt 7. NEMO Multihoming Issues ................................... 25mins "Analysis of Multihoming in Network Mobility Support" draft-ietf-nemo-multihoming-issues-01.txt Draft Issues: http://www.mobilenetworks.org/nemo/draft-ietf-nemo- multihoming-issues ChanWah Ng (10mins) Discussion (5mins) "Global HAHA" draft-thubert-nemo-global-haha-00.txt draft-wakikawa-mip6-nemo-haha-spec-00.txt draft-wakikawa-mip6-nemo-haha-01.txt Pascal Thubert (10mins) 8. NEMO RO Problem Statement ................................. 30mins "NEMO Route Optimization Problem Statement" draft-clausen-nemo-ro-problem-statement-00.txt Thomas Clausen / Ryuji Wakikawa (5mins) "RO with Nested CNs" draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst (5mins) "Update of "Taxonomy of RO models in the NEMO context" draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG (5mins) "NEMO RO Pb Statement, Requirements and Evaluation Considerations" draft-zhao-nemo-ro-ps-00.txt Fan Zhao (5mins) Discussion (10mins) 9. Securing Prefix in Binding Updates ......................... 05mins ChanWah NG "Extending Return Routability Procedure for Network Prefix (RRNP)" draft-ng-nemo-rrnp-00.txt 1. Agenda ========== No comments about the agenda 2. NEMO WG Status - Thierry Ernst ================================== Terminology and Requirements draft-ietf-nemo-terminology-02.txt draft-ietf-nemo-requirements-03.txt Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo The drafts have been updated a few weeks ago. There are still some open issues in the Terminology draft Few open issues in the Requirements draft, TJ will update it. The goal is to submit it to the IESG as soon as possible. NEMO Home Network Model draft-ietf-nemo-home-network-models-01.txt Ready for WGLC that will be issued in a couple of days IPRs on NEMO Basic Support Cisco has changed IPR Cisco new statemant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=497 Cisco old statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=135 Nokia IPR Nokia statement: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=136 The new IPR statement from Cisco is easier to interpretate, and facilitates open source code developers to implement the NEMO basic support. With this changes, Cisco IPR is easier to deal with than the Nokia IPR KAME and USAGI are likely to support NEMO after the new IPR. Question: --------- C. Ng: The Threats and Analysis draft has not been updated for while, but this is still a milestone on the wg charter, will those be adopted as wg items? Thierry and T.J.: If there is no additional threats, we should remove the milestone from the charter. This part is now covered with the NEMO Basic Support update. 3. NEMO Basic Support (draft status).......................... 20mins Vijay Devarapalli draft-ietf-nemo-basic-support-03.txt Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html Status - IANA assignments are done - Very close to AUTH48 call - Some issues raised recently by Erik Nordamrk - The question is why changes need/can be done now and which ones can be made later. The proposed classification for changes is: - Critical changes that imply a fundamental problem in the document and would require a new WGLC - Important changes where the text is not clear and may affect interoperability. these changes can be done if there is wg consensus and the IESG approves them - Desirable changes that imply clarifications. These can be done in this document or can be done in future versions - Minor changes mostly editorial, that can be done now since they don't affect the protocol. The proposed changes since IESG approval have been discussed on the WG ML The Draft Issues are at: http://people.nokia.net/vijayd/nemo/issues.html The changes have been classified in the above categories as following: * Critical changes None * Important changes Issue 42 The question is whether to include all the prefix in BU. The consensus in the discussion in the ML was to include all the prefixes in a BU BA status values MR discards BAck with status values 141 and 142 in implicit mode Status value 143 makes no sense in explicit mode. These would only occur in these modes if there is a misconfiguration. However, the current text says to silently discard. Then, the MR user wouldn't know what is happening without an error. The proposed solution is to treat this as a fatal error. This solution does not require any changes on the wire, it is mostly an implementation hint. The use of tunnel encapsulation limit There is text to limit the number of nested mobile routers. However, this is not possible, or would require a complicated solution. The proposed solution is to remove that paragraph. Issue 39 Conflicting wording of SHOULD and MUST The proposed solution is to use SHOULD Another issue to explicitly list authorization of the MR in the security considerations section The solution was to add text to security considerations section Another issue is to clarify text about error code 143 in BAck, without changing IANA considerations. Another issue is about sending routing updates on the visited link This can't be enforced. This was spotted by Alex Z. before the IESG last call, but mistakenly not updated in the doc. * Other changes that fall under the other categories refer to the above URL of the issues list Conclusions: - No critical changes - Few changes are needed - Authors recommendation: only accept changed don't require recycling the doc to the WG - IESG members should be made aware of the changes - Do the changes during AUTH48 Questions: ---------- Pascal: Which is the impact on existing implementations of these changes? No comments were made about this Thierry: Sense of the room: Is is a good idea to submit the draft or we should remove it from RFC queue? Hands for shipping the document ASAP: some hands Hands for retaining the document: none TJ: Is this classification of the changes is good approach? The proposal is to make important and minor changes now and defer the intermediate, any comments or objections? none 4 NEMO MIB Design ........................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt The MIPv6 mib was published and it manages the MIPv6 part. The focus here is NEMO as the managed entity The NEMO mib structure has 4 groups - nemoSystem Group: Provides general information relevant to the implementation and operation of the NEMO protocol - nemoStats Group: statistics related to the NEMO protocol - nemoNotification Group: defines the notification generated by the NEMO entity in response to the operationally interesting protocol state changes - nemoConformance Group: identifies the managed objects that needs to be implemented for conforming This is the first submission and we expect to include more objects in future releases The general question is what additional objects do we need? Additional Issues to be determined - Need to add the objects for HA - What other notification do we need? - Do we need other objects for diagnostics? What's next? - Review the draft based on the WG input - Get it reviewed by a MIB Doctor 5. Announcement: 6th TAHI interop test event ................. 05mins Yukiyo Akisada See http://www.tahi.org/inop/6thinterop.html Test event in Japan, Chiba, 24 Jan (1 week) Interop test: NEMO basic support is included Conformance test: NEMO is included 6. Prefix Delegation ......................................... 10mins TJ Kniveton draft-kniveton-nemo-prefix-delegation-00.txt Prefix delegation is included in the charter of the WG This draft is augmenting the work done by R. Droms The goal is to use NEMO signaling for prefix delegation New protocol elements are defined to carry prefix requests Both Transient (CoA) and Persistent (HoA) prefixes are considered This approach complements DHCP methods. NEMO signaling has some additional mobility related attributes and NEMO based approaches might save flows Question to the wg is: Is the WG interested in DHCPv6 only method? Does it make sense to merge this approach with DHCPv6? Questions: ---------- Vijay: I don't agree with statement that the two approaches are complementary. DHCP can provide a complete solution. TJ: You can have a solution with only DHCP, but there are some nemo specifics elements missing. You can also have a solution using only nemo signaling also. So there are three options only NEMO, DHCP, hybrid. Vijay: Could we have two proposed methods, where we just have the DHCPv6, and the other with this apporach? TJ: We could consider this options. Opinions from the WG? Pascal: The motivation part of the draft says clearly why we need this so please read it if you haven't. Pascal: Do we need to merge this or separate is fine? Vijay: Separate is fine TJ: No sense from the room. We proceed working with Ralph and Pascal and figure out how to integrate those, since there is no sense from the room Vidya: MIP6 agreed on using NAI for HoA, are we just relying on MIP6 for whatever they decide? TJ: NEMO is an extension on MIP6, whatever agreement HA and MN have, they'll be a parallel set of rules for MR Vidya: There needs to be a way for authorizing MR say it's acceptable to own this prefix TJ: This is an implementation/policy decision, how do we decide MR allowed to use a HoA? The same thing happen with prefixes. TJ: In conclusion, since there's really no strong oppinion. We could advance both of these documents (DHCP based and NEMO based) as WG items. Ryuji: Both mechanisms are statefull, do we need two statefull mechanisms? Do we need a stateless mechanism? Erik: This draft will be a wg but i can't find the draft in id directory TJ: It was submitted late and it is not in directory TJ: Ralph's draft is expired 7. NEMO Multihoming Issues ................................... 25mins "Analysis of Multihoming in Network Mobility Support" draft-ietf-nemo-multihoming-issues-01.txt Draft Issues: http://www.mobilenetworks.org/nemo/draft-ietf-nemo-multihoming-issues ChanWah Ng (10mins) Discussion (5mins) List of issues and proposed solutions: Issue 1: fixed Issue 2: rejected Issue 3: accept and remove text Issue 4: remove the word different Issue 5: rejected Issue 6: updated benefits lists Issue 7: updated description Issue 8: explain that it is only an example Issue 9: description of the problem Issue 10: other failure modes explored Issue 11: follow multi6 How to close 12-13? Keep the text as an appendix Move to a separate draft WG opinions: Marcelo: Move it to separete draft TJ: Do both. Keep it as an appendix for now and make a new doc if needed. Which problems should be solved by NEMO WG - Path survival - Path selection - Ingress filtering - Failure Detection - Media Detection - HA sync - Prefix Delegation - Multiple Binding Registration - Source Address Selection - Impact on Routing Infrastructure - Nested Mobile Networks - Split Mobile Networks Questions: ---------- Pascal: Split mobile network should not happen, or must not happen. Marcelo: Path survival may be different in NEMO than in multi6 since on of the goal of NEMO is to support ubiquity. This means that the failure will occur in the access link. It may make sense to optimize this case. In addition, paths in NEMO case may have very different characteristics, so they may be different considerations than in the multi6 case. Finally, in multi6 it is assumed to be multiple prefixes, which may not be the case in NEMO multihoming. Pascal: Can we just say wait for multi6? TJ: We can't expect other WG to solve items we need that is not addressed in the charter. Marcelo: We should identify which can be expected to be covered by multi6 and which needs to be done in NEMO. PAscal: My conclusion is I believe some of it may end up here TJ: Does everybody agree with the categorization presented here? We should really follow up with this offline "Global HAHA" draft-thubert-nemo-global-haha-00.txt draft-wakikawa-mip6-nemo-haha-spec-00.txt draft-wakikawa-mip6-nemo-haha-01.txt Pascal Thubert (10mins) The history of the document is that it started as draft-wakikawa-mip6-nemo-haha and then the document split into 3 documents: The Base document for HAHA gives normative part. Then Global HAHA provides distribution of home across internet and the local HAHA which provides high availability in a link. In this presentation we will focus on Global HAHA. The NEMO requirements include Multlihoming support and that multiple HA has to be distributed both locally and globally. One use case for the global disctributions is the airplane case. Among the problems that are being addressed we have the main target is the HA synchronization Additionally, we propose to obtain a L3 operation for NEMO In both NEMO basic support and MIPv6 Home are anchored to Home Link at L2 This means that the home can not be distributed geographically Then the Home link is a single point of failure So NEMO is an hybrid L2-L3 operation The proposal is to make NEMO full L3 Questions: ---------- Alexandru - Global HAHA implies 2 home agents. So maybe we should have HAHAHAHAHA for multihoming 8. NEMO RO Problem Statement ................................. 30mins "RO with Nested CNs" draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst (5mins) Short presentation on the status of his new Nested CN route optimization draft "NEMO Route Optimization Problem Statement" draft-clausen-nemo-ro-problem-statement-00.txt Thomas Clausen / Ryuji Wakikawa (5mins) The goals of this draft is to consider a MANET solution to RO problem statement Question to merge with other RO-problem-statements Pascal: Perhaps this is too much solution oriented. similar to local mobility management approaches. may be an overkill for some cases where there is only a default route "NEMO RO Pb Statement, Requirements and Evaluation Considerations" draft-zhao-nemo-ro-ps-00.txt Fan Zhao (5mins) Presentation of the draft. Several scenarios described Scenario 1: CN is in the infrastructure Scenario 2: CN is in the NEMO network "Update of "Taxonomy of RO models in the NEMO context" draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG (5mins) Important changes from initial versions, in particular the problem statement is more clear, the description of the solutions is moved to the appendix Discussion: ----------- Thierry: We have 4 drafts about RO. We need to select one wg document candidate. The options would be to use the Taxonomy draft as a base wg document or to start from scratch. Alex: Start from scartch Thierry: Motivation for this preference? Alex: Current problem statement draft is too solution oriented. We need a neutral problem statement that is neutral. Thierry: Could you expand on this? Alex: For example the tree discovery approach is stated in the draft Pascal: This was true for version 0 but this version is new. You should read it Thierry: Did you read it? Alex: I don't remeber Tierry: Could you read the draft again and restate the position in the ml Ng: Please read the new version of the draft, since the changes are based in your comments Cristophe J.: We need more time to read the drafts, move it to the ml Erik: The problem is that the taxonomy is based on the solution space . We need to state the problem and not explore the solution space Pascal: There is a huge number of drafts proposed, we can get rid of the detail of the different solutions, but we think it is useful to keep the info about solutions, and pro and cons identified. Alex: Who has considered this?, this was not discussed in the ml Pascal: We are not only providing a problem statement but also we are also providing history Alex: The ml was silent Hesham: We are ratholing, if we just want to do the charter item, 3 pages drafts is enough Alex: The goal is to understand the problem and not based in a solution Hesham: We could simple do a 4 page doc with the problem description Thierry: Move the discussion to the ml Changes in the agenda: ====================== - Point 9. Securing Prefix in Binding Updates was not presented - A new presentation about v4/v6 transition and mobility by Vijay was presented. 9. v4/v6 transition and mobility The problem that is presented is what the NEMO MR should do when it finds itself on an IPv4 access network. This is related to the discussion on v6ops. One option would be something similar to TEREDO, where NEMO runs over a transition mechanism. We can build mobility mechanisms for the transition tunnel (i.e. when the v4 address changes) and another one for the MR tunnel (v6 address). However, the idea would be to collapse all in one tunnel. Questions: ---------- Sri: When you're traversing v4 network, tunneling will be there. When you collapse with HA it's the same. Erik: Are you assuming MR and HA have v4 connectivity with no NAT boxes? Vijay: We want to allow NAT Erik: You're going to end up having every protocol having NAT support Hesham: The problem is that a mobile host ends up in all sorts of access networks. Whether it's a host or router is orthagonal. There are different levels of mobility between host and access network, especially where LMM is being used. there are serious inefficiencies for managing mobility on those two levels. The scope is not bound by nemo or mobile ip for hosts, bit it's a general problem for mobility and transition. So, it would be nice to have a general framework for mobility. Henrik L.: I agree with Hesham. A lot of different aspects to transition in combination with mobility. I've authored a draft showing the full field of all these combinations. We shouldn't jump into this barrel from different directions from 3-5 work groups, we need a more generic approach. Vijay: Need to disagree. I don't think we can come up with a generic mechanism that can cover all mobility solutions. So we should use v6ops tunneling as much as possible. But if MR is v4/v6 and HA is v4/v6, we don't want a NEMO tunnel inside a transition tunnel Henrik: I don't think we disagree. Read the draft. Hesham: There are a few drafts. Different solutions for different problems. Get an idea of the problem, then we can talk solutions for next year. Pascal: I encourage people to read those drafts. This is more critical to us than v4, because you can't do anything w/o v4 Thierry: should we take this as a milestone for the WG? 10. Conclusions and Next Steps ................................. 10mins - More comments expected on terminology and requirements for wg last call. - WG last call for nemo home nw models in a few days - Remove threat analysis from milestones (already done). - NEMO basic support: next action to be taken about new issues. It will happen on ML in the next week - Prefix delegation: we need to discuss whether we accept 1 or 2 documents as wg document. - Multihoming: want to close accepted and rejected issues. - RO problem statement: need to discuss whether taxonomy draft will be WG document, or whether we will make a new, shorter document. - v4/v6 transition will be discussed on mailing list |