Minutes from the MONAMI6 WG meeting, IETF68 March 18-23 2007 Prague Monami6 WG page: http://www.ietf.org/html.charters/monami6-charter.html Chairs: Thierry Ernst & Nicolas Montavont 1. Welcome, agenda bashing ....................................... 05 mins (Chairs) Blue sheets, scribes etc. were sorted out. Notetakers: Henrik and Alex. Nicolas went over the agenda; no comments from the room. 2. Int-Area MIPv6-related WGs Reorganization ..................... 10 mins (Jari Arkko - Internet Area AD) Jari went over the thinking behind the proposed MIP6/NEMO/MONAMI6 merge: With the current number of mobility-related groups, scheduling is *really* difficult, and coordination between related work is also hard. The workload of the groups doesn't seem to be too high to do a merge now. 3. WG Status ..................................................... 10 mins (Chairs) http://tools.ietf.org/wg/monami6/ Nicolas went over the WG status, mentioned the WG Wiki and issue tracker, which is accessible from the menu at http://tools.ietf.org/wg/monami6 4. MIPv6 Analysis Draft Update (Nicolas) http://www.ietf.org/internet-drafts/draft-ietf-monami6-mipv6-analysis-02.txt Two reviews has been done, resulting in a lot of editorials, and some substantive changes. For details, see the document status slideset: http://www3.ietf.org/proceedings/07mar/slides/monami6-0.ppt - Hesham: Question the change of multihoming. Would like to exclude the case of one interface with multiple addresses from the definition - Erik: The new definition is in line with the basic meaning of multi- homed, and also aligned with the common practice - Nicolas: Do you want to change the definition, or change to use another term which has the meaning of 'multiple interfaces'? - Hesham: Don't want to make to much work for you, but the second option would work for me. 5. MCoA Update http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-02.txt 1. Overall Changes ............................................ 15 mins (Ryuji Wakikawa) Ryuji went over the changes. For details, see the MCoA status slideset: http://www3.ietf.org/proceedings/07mar/slides/monami6-3.ppt There was a question about keeping the priority field, or remove it since it's not really needed and not well explained. Hesham suggested that the best would be to explain it. The returning home issue hasn't gotten many comments -- comments on the list clearly needed. draft-wakikawa-mip6-no-ndp discusses a possible resolution of this. - Hesham: Overwrite flag -- How does this work - are you changing the semantics of a binding update? Normally a binding overwrites... - Ryuji: The overwrite flag takes away the other bindings if you set it - Henrik: Wouldn't "Clear flag" be a better name if it means that you clear out the previous bindings if it is set? - Erik: Depends on the error handling semantics -- with this flag you have 2 operations, one remove and one set operation -- what you do if the set operation fails might make one name or the other more appropriate. 2. IPsec & IKEv2 in MCoA ...................................... 15 mins (Vijay Devarapalli) Vijay went over the security related changes; the use of IKEv2 etc., see the 'IPsec update to MCoA' slideset: http://www3.ietf.org/proceedings/07mar/slides/monami6-1.ppt - Alex: Isn't the permission of BU coming from *any* CoA a new security issue? - Vijay: Not really, these addresses are all addresses that has been explicitly configured on the MN and mentioned in a previous BU. - Hesham: Why is it harder to handle IPsec tunnelled traffic than IPsec BU/BAck traffic? - Vijay: The IPsec implementation doesn't have as much knowledge about the CoA as the monami6 implementation, so it doesn't necessary know to use the correct CoA when encapsulating the packets. (Prolonged discussion Hesham - Vijay, with Hesham trying to say that it's not difficult, while Vijay is saying that you have to handle this, and the difficulty may depend on the implementation and the degree of integration. Ends with a suggestion that Hesham writes up the problem he sees and send it to the list). - Alex: (Suggests a possible solution to the problem, details to be written up and sent to the list). 6. Implementations Issues ........................................ 10 mins (Umar Toseef) draft-soliman-monami6-flow-binding-04.txt Umar presented some implementation experiences with the soliman draft, see the "Flow binding implementation" slideset: http://www3.ietf.org/proceedings/07mar/slides/monami6-2.ppt - Hesham had a question about the "Duplicate receipt of filter rules" slide. It is the whole first BAck which is lost. The handling could be rather simple, since error 135 is a warning rather than an error, and the state is correct on both ends. Some further comments suggested a state machine to define the proper handling. 8. Summary of Feb. discussion on INT-area ........................ 15 mins (Chairs) draft-soliman-monami6-flow-binding-04.txt draft-larsson-monami6-filter-rules-02.txt draft-mitsuya-monami6-flow-distribution-policy-02.txt Topics: - mechanism to exchange preferences, not necessarily one needed for the determination of path - 1 sol fits all vs 1 tailored sol per protocol - MNN-MR Preference Settings . - NEMO RO and flow bindings for NEMO tightly related ? - having several exchange mechanisms, but a common format ? - host<->router and router<->router exchanges of filter rules, - distinction between filter rules and policies/preferences Thierry first went over the needs of the Monami6 work and then summed up the discussion. See the slideset "?????": http://www3.ietf.org/proceedings/07mar/slides/monami6-4.ppt ??? - Koshiro Ichii?? : We have an implementation of the mitsuya draft. Draft soliman is not aligned with the - Jari: What should be the scope of the work in this group, and the ambition level. On one of the slides you had a slide with problems with the different approaches. It's not your task to provide a solution to all the potential users of this, but you should apply good modular design and engineering sense -- you can apply that here, and do a modular approach, without doing the binding for the other protocols. - Larsson: Is PMIP considered here?? - Jari: If you have a generic solution, that is fine, then work on the Monami6 binding of that generic solution, and don't work on other bindings. - Hesham: One way of capturing this commonality, option 2 earlier, of having a common format for the rules, but to have domain-specific transport. Also, I don't understand the rationale for the proposal of informational/experimental for draft-soliman - Jari: I would ask you to do some more work before giving up the idea of standardising something. - Hesham: I think I'd be ashamed not doing a standard, and just going for experimental. - Ryuji: (Missed comment) 2 basic paths - (Missed long interaction around the approach to be taken here due to participation in the discussion). Highlights: * Although none were really happy with it, most people at the mike were OK with one generic re-usable filter spec, and one monami6-specific container being defined by the working group. * Issue: securely binding the MN BU identity and the identity associated with filter rules carried by another protocol * Should the filter rules also be useful for router-to- router filter exchange? Not in the sense of ensis, but if it so happens that in some cases they are useful, fine. 9. Conclusions ................................................... 05 mins Thierry closed the meeting. ------------------------------------------------------------------------------