>---------------------------------------------------------------------------< > NEMO Working Group meeting during the 66th IETF, Montreal > Tuesday, July 11, 2006 - 18.50-19.50 > Chair: Thierry Ernst >---------------------------------------------------------------------------< - Minutes taken by Masafumi Watari, Bruno Stevant Meeting merged and completed by Thierry Ernst using audio input - Presentation material set: http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf - Links: IETF Agenda and Slides: http://www3.ietf.org/proceedings/06jul/index.html Audio recording available from ftp://limestone.uoregon.edu/pub/videolab/media/ietf66/ NEMO Audio is on channel 5: ietf66-ch5-tue-afnoon.mp3.2 (from 11'30'') Secondary NEMO WG Page: http://www.ietf.org/PASTMEETINGS/IETF-66b.html - Meeting started 15min late (MONAMI6 meeting just before was extended) 1. Welcome, agenda bashing ....................................... 05 mins Chairs 2. WG documents status ........................................... 10 mins Chairs See slides 3-10 http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf Thierry summarizes the status for each document. Some documents have expired and as such were removed from the WG page, but a new version for each of these should be reissued. Several documemts are ready for WGLC and this should be issued shortly after the meeting. ooo Q&A ooo * RFC 3963: commercial and non-commercial implementations exist NEMO Basic Support spec should be revised based on implementation input (see "Rechartering items") * Any concern on draft-ietf-nemo-multihoming-issues ? => no => WGLC will be issued * NEMO Prefix Delegation 2 WG docs exist (one has expired, but will be re-issued) Vijay: Why merging the 2 drafts ? First is simple (DHCPv6 on top of the NEMO tunnel), the other one extends MIPv6 messages (extensive messages exchange) ... They should be kepted separated. Alex: Agree with Vijay (no need to join) Thierry: The point is that we didn't get enough feedback from others. Vijay: DHCP based has been stabled for over two years now. We have actually been waiting for WG Last Call. The simple one is straight forward 3. Summary of Recent Discussions on the ML Chairs 3.1. Deployment Requirements .................................. 10 mins Open Mic See slides 11-15 http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf The purpose of this slot is to give the opportunity to people who intend to deploy RFC 3963 (NEMO Basic Support) in their networks, products, or services to express the deployment concerns they came through, and on which the NEMO WG may be expected to work. Thierry gives some perspectives about the aviation industry and the vehicular industry. Input from the industry highly awaiten, otherwise we might miss the opportunity window to address concerns from vendors and operators willing to deploy NEMO Basic Support (RFC 3963) ooo Q&A ooo Alex: People already sent on ML ? => Waiting for a formal document Thierry: A document may be written if this is agreed for the NEMO WG rechartering. So far, the WG is waiting for input from different industry. Boeing, speaking for the aviation industry, is expected to issue such a document (expressing their own view) We expect [i.e. we hope] similar contribution from the car industry. 3.2. IPv4 Network Mobilty ..................................... 05mins Chairs See slide 16-18 http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf Thierry summarizes the history behind this discussion. ooo Q&A ooo Henrik (MIPv4 WG Chair): This has also come up on the MIPv4 ML. As a chair, we would be happy to take it on after talking with the ADs. Hesham: I think it would be better to have this in MIPv4 if that can be worked out. Jari Arkko (Internet Area Director): No reserve to move this to MIPv4 Location of the work doesn't really matter, but the fact that there are needs for this work is more important (here or later on the list) Alex: I'm happy to see NEMOv4 anywhere as long as it happens. It's also good that deployment requirements are being discussed here in NEMO WG. Thierry: Not quite, the deployment requirements discussion is about RFC 3963, i.e. IPv6, not IPv4. Alex: OK, that is also really good that we get the deployment requirements. 3.3. IPv4 and NAT traversal scenarios ......................... 10 mins Hesham Soliman http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-02.txt This draft is co-hosted by the MIP6 and NEMO WGs. The purpose of this slot is to update the NEMO WG about the scenarios covered by this draft. (a somewhat different) presentation to be also done on mip6 Hesham is speaking about the scenarios of interest for NEMO. ooo Q&A ooo Fred T: How UDP NAT traversal compares with the Teredo mechanism ? Hesham Soliman: There is no discovery issue. We already know the HA address. We set up a UDP tunnel interface. We use the BU to keep alive the NAT binding. ??: Mecanism is simplier, because doesn't try to reach through 2 NATs, so no need to send the bubbles both ways. We simply establish connectivity with the HA. Fred T: Does the HA need to be in the Internet, or behind the NAT Hesham: HA can be behind a NAT. It must be configured to be reachable. Fred T: Through a public address ? Hesham: Yes. Port forwarding if behind NAT. 3.4. Rechartering Items ...................................... 20 mins Chairs Slide 20-25 http://www3.ietf.org/proceedings/06jul/slides/nemo-0.pdf Thierry reviews the discussion which happened on the ML since last IETF meeting. Put the last version of the charter on screen: http://www.mobilenetworks.org/nemo/charter2_2.txt ooo Q&A about Charter Update ooo Thierry speaking about "Address issues with the base RFC": Shall we be more specific on the issues we are speaking about ? Jari Arkko: You would probably not be able to know what are the issues that arise later. Are you planning to issue a base document or not ? Thierry: Yes. ooo Q&A about RO ooo Jari Arkko, about RO solutions: Are there plans to publish multiple alternatives schemes for different scenarios? Thierry: We don't think one solution can meet all RO needs Jari Arkko: Fair enough. But would be happier with an approach where we do one and simple thing. Easy to recharter. We can add things later. Some doubt on how much we need in this RO space. Hesham: Agree with Jari. But, 1st, has some doubt on pure end-to-end RO. NEMO seems more complicated than MIPv6. HMIP-RO is not the purest RO, need network support and is not end to end, but is quite easy to do. What other solutions you have in mind ? Are other solutions about RO inside a NEMO? Thierry: Yes. Another could be not about RO, but about avoiding multiple encapsulation in the nested case. Hesham: But this is another problem, not a RO problem. Marcelo: One of the problem is that there are multiple solutions that try to address a single scenario. So I agree to first see what scenario we want to support and then work on a RO solution. Delivering use-cases should be done before re-chartering Thierry: For the new charter, I would have a doc on use-case, and that's it. Marcelo: Agree. Jean-Michel Combes: Agree with Marcelo. I don't think we can have a single solution for all scenarios. Alex: There is also an option to shutdown the WG and take some time to think about it. This is just to mention that there are alternatives. Thierry: We wan't to do something more, and that is the use case and deployment requirements. After, we will see if we need to continue. Alex: Use case is good, but there is no WG chartered just to produce a use case. Thierry: There are other things. The fault-tolerance issue, etc. Of course, we should have solutions in mind before rechartering (for ex. for fault tolerance issue) ooo Q&A about global HAHA ooo Hesham: Where would Global HAHA fall under? RO? Thierry: It is useful for multihoming as well. Hesham: It has wide impact on routing management. The applicability should be limited. Ryuji: Global HAHA is not limited to RO, but for HA reliability and redundancy. MIPv6 WG DT is working on HA reliability which message exchanges are quite similar to Global HAHA. We could extend that to be used for NEMO. Chan-Wah: Global HAHA, is not specific to NEMO but RO effects of Global HAHA is. If you talk about HA-HA reliability, it is not specific. Better to rename the protocol. ooo Q&A about deployment requirements ooo Ryuji: Also tried to get information from industry, but they tend not to disclose. ooo Q&A about RFC 3963 revision ooo Alex: There are editorial issues that needs to be applied to RFC 3963. => So, a revision of the RFC seems justified. ooo Q&A about MANEMO ooo Keiichi Shima, about MANEMO: What do you mean by MANEMO work? Thierry: Just wanted to mention that there maybe possibility for this work to be worked on here. Ryuji: There is a ML for this. Post-Note: here is the information to subscribe the MANEMO ML: The target case is when multiple MRs form a nested NEMO, each MRs can exchange routes with others to avoid the path through HAs. ooooooooooooooooooooo Summary/Conclusions from the meeting oooooooooooooooooooooooo - issue the WGLC and finish existing document - recharter to define use cases and deployment requirements, and that's it - RO solutions would be the next step. - Sense of the Room (just being curious, this is not supposed to drive a decision): How many people think we should recharter: 20 How many people think we should close-down the WG: 0