[nemo] Draft Minutes

[Thierry Ernst <[e-mail]>]

Dear all,

Here are the NEMO WG meeting minutes, please check and comment if you
find any serious mistakes or wrong statement. 

Many thanks for Marcelo for taking notes and putting these minutes in
shape and also for Masafumi's contribution with additional notes.


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