Changes between Version 2 and Version 3 of IETF89

11/03/14 13:01:58 (7 years ago)



  • IETF89

    v2 v3  
    88The WG spent around an hour of the f2f meeting time discussing the rechartering and identified areas to work on. The very draft charter text can be found: []. During the WG meeting few new topics were raised: linkage to other IETF WGs who do related work to some extent (not with mobility as the focus) like I2RS, SFC, LISP, FORCES and possibly VNFPool. The linkage to existing architectures was emphasised. If DMM WG wants to work on something that is deployable on e.g. 3GPP networks that should be documented how. Last, the current trend of network function virtualisation was brought up, and DMM should reflect that in its work.
     10== L2TPEXT ==
     12L2TPEXT did not meet in London for IETF89.
     14The WG has a draft being currently polled for adoption, "Keyed IPv6 Tunnel" (draft-mkonstan-l2tpext-keyed-ipv6-tunnel).
     16There are no concerns in L2TPEXT.
     18== PCP ==
     20The PCP WG met at IETF 89.  The DHCP option spec was submitted to the IESG
     21just before the meeting, and progress was made on several other documents.
     22The next rev of pcp-port-set should be ready to submit to the IESG, allowing an
     23app to request a range of ports (e.g., for RTP).   The PCP proxy spec and
     24authentication specs are making good progress; the WG discussed open issues
     25and determined next steps.  The WG also agreed to start work on updates to
     26the base PCP spec, collecting the deltas on which the WG already has
     29== HIP ==
     31The HIP WG is chartered to finish an old Experimental RFC-to-be and to
     32revise the main HIP specs, which are also Experimental, into Proposed
     33Standards. The old Experimental RFC-to-be, the RELOAD instance spec,
     34has already been published as RFC 7086.
     36The WG also has a few "bis" drafts. They revise the old Experimental
     37HIP specs. Additionally, there are a couple of drafts that are spin
     38offs of those specs: the NAT traversal mechanism and the multihoming
     39part of the mobility and multihoming spec. We decided to document
     40these in separate specs for clarity.
     42We intend to request their publication in batches so that reviewers
     43have the necessary context when performing their reviews. We will be
     44requesting the publication of the first batch, which includes RFC
     454843bis, RFC 5201bis, and RFC 5202bis, shortly.
     47== TRILL ==
     49The TRILL WG met Friday mid-day in the last meeting slot. After a review of status, Sue Hares presented a survey to gather information for the TRILL implementation report called for in the Charter and for which Sue has agreed to be editor.
     51There was a brief status and update presentation on TRILL OAM and a supplementary presentation on the Liaison the IETF received yesterday informing us the IEEE 802.1 WG has allocated blocks of CFM code points to the IETF. TRILL OAM uses these. WG Last Calls were started on draft-ietf-trill-oam-fm and draft-ietf-trill-loss-delay running through 24 March.
     53The next topic taken up was Active-Active. Draft-yizhou-trill-active-active-connection-prob, an Informational survey of the problems involved with TRILL active-actve connection at the edge, has been in call for WG adoption ending at this meeting with favorable comments on the mailing list. There were no negative comments from the meeting so the Chairs declared it adopted. Draft-hao-trill-analysis-active-active was then presented and there was a significant amount of discussion. This is an informational draft describing solutions to problems. Meeting comments indicate that another pass should be made on this document before calling for WG adoption.
     55Draft-zhang-trill-aa-multi-attach was presented and briefly discussed. While the material presented was good and coming along well, it raise enough questions that more discussion is needed.
     57Draft-mrw-trill-over-ip (which has been adopted as a WG draft although the WG filename version has not been uploaded yet) was then briefly presented and discussed with particular attention to the areas of the draft that may need more work. One question was whether UDP encapsulation or some custom encapsulation should be used. There was a strong consensus for UDP in the room, which will be confirmed on the list.
     59Finally, the status of the Directory Assisted Edge drafts was presented verbally but there was insufficient time to go into or discuss them.
     61== 6lo ==
     636lo  WG session was held on March 5th (Wednesday) in the 15:20 - 17:30 slot in the afternoon. The Agenda was full with several drafts and presentations.  Four adopted WG drafts were presented at the meeting out of which the BTLE document is in IESG review phase and it is  waiting for BTLE sig to comment on the IETF draft before moving further.  draft-ietf-6lo-lowpanz passed the WGLC call and received more comments due to change in privacy address in 6man.  draft-ietf-6lo-lowpan-mib WG comments were discussed at the meeting about providing interface specific MIB capability and the f2f WG meeting rough consensus was to include an optional interface-specific MIB in the document. Draft-ietf-6lo-ghc has been presented and discussed as well.
     64The presented adopted WG documents are:
     66  * draft-ietf-6lo-btle
     67  * draft-ietf-6lo-lowpanz
     68  * draft-ietf-6lo-ghc
     69  * draft-ietf-6lo-lowpan-mib
     71Waiting to be submitted: draft-ietf-6lo-lobac
     73draft-mariager-6lo-v6over-dect-ule was scheduled but not presented due to absence of the  presenter.
     75Two new drafts were presented at the meeting:
     77  * draft-savolainen-6lo-optimal-transmission-window
     78  * draft-rizzo-6lo-6legacy
     80An interesting presentation (  on link-layer privacy  from IAB STRINT workshop has been presented as well .  6TiSCH plugfest announcement and 6lo/6TiSCH possible collaboration area based on 6lowpan-nd are presented by the 6TiSCH co-chairs.  6lo co-chairs discussed possible interest in 6lo deployment usecase scenarios that require more work in the working group and develop a reference architecture related to other constrained node area network components.