Changes between Version 9 and Version 10 of IETF89


Ignore:
Timestamp:
12/03/14 06:59:04 (7 years ago)
Author:
suresh.krishnan@…
Comment:

Arranged the WGs in alphabetical order

Legend:

Unmodified
Added
Removed
Modified
  • IETF89

    v9 v10  
    1 == 6MAN ==
    2 The 6man working group held a two and a half hour session on the Tuesday of the IETF in London. The session was well attended with over a hundred participants. It was recorded by Meetecho and the audio/video archives are available.
    3 
    4 There has been active discussions on the mailing list since the last IETF, with over 800 messages. The main topics of discussion has been "Why /64", SSAS, the recommendation for default interface-identifiers, address privacy and efficient ND. The working group has had 5 RFCs published, and currently have no document in the IESG queue.
    5 
    6 The main topics for the London meeting, was the "Why /64" document, that is a document that explains why the /64 boundary was chosen, and also explores the consequences of changing that boundary, if we ever wanted to do that. There was strong support in the room for adopting this document as a working group document. We also had a 45 minute session to talk about efficient ND. Both with regards to battery efficiency, and how ND behaves on link-layers that do not handle multicast well. The chairs have decided to form a design team to work on this problem, anyone interested in participating should contact the chairs. The design team is expected to report back to the working group at the Toronto IETF meeting.
    7 
    8 There was also consensus in the the room to adopt the following drafts:
    9 
    10         * draft-gont-6man-lla-opt-validation
    11 
    12 This consensus is being verified on the mailing list.
    13 
    14 == DMM ==
    15 
    16 The DMM WG is about to complete the work on its current charter. The requirements document has already been submitted into the publication process and the second working group document on the current practices & gap analysis is nearing the completing. The next step with the gap analysis is the WGLC, which will be called after the IETF#89 week. The outcome of the gap analysis has pinpointed potential topics and areas of future work.
    17 
    18 The WG aims to recharter before the IETF#90. There has been vivid offline discussion already on the possible work items and the revision of the charter text. The future distributed IP mobility management deployments are going to look rather different than what tradition IETF IP mobility protocols have been designed for. The DMM WG is not going to restrict itself only to existing IETF IP mobility protocols tweaking.
    19 
    20 The 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: [https://github.com/jounikor/dmm-re-charter]. 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.
    21 
    22 == intarea ==
    23 
    24 The intarea working group met in a short one hour slot. The draft describing the use of the IPv6 Flow Label for Load Balancing in Server Farms was published as RFC7098. Internet Area Director Brian Haberman announced the formation of the INT directorate to assist the INT area directors in document reviews. 
    25 
    26 The draft describing a fragmentation strategy for Generic Routing Encapsulation (GRE) was presented. The intent of the document was to provide guidance to future implementers. The content of the draft was well received by the working group, but there were differing opinions as to whether this work would continue to be a point solution or be folded into some form of generic work on tunnels. This will be discussed on the list.
    27 
    28 The draft describing issues with IP links in spontaneous wireless networks was presented. The goal of the draft was to raise wider awareness to some issues that need to be handled by IP on ad-hoc wireless networks. There was some resistance to this draft as some people involved in earlier work in the autoconf working group believed that the scope of the problem is much larger than envisioned by this document. The chairs have requested them to have offline discussions with the draft authors and get back to the wg with a way forward.
    29 
    30 There was a presentation concerning the potential effects of the NFV initiative and the associated data plane acceleration technologies on IETF protocols. The draft authors are looking for feedback from the Internet Area community. Please send comments to the authors. There was also a presentation about the Asynchronous DNS API by the folks involved in an open source implementation of the same. Their goal was to solicit comments and contributions from DNS folks in the Internet area. The draft concerning use of CGAs for Transaction signatures was updated based on comments received from the working group. The draft will be discussed further on the list.
    31 
    32 == L2TPEXT ==
    33 
    34 L2TPEXT did not meet in London for IETF89.
    35 
    36 The WG has a draft being currently polled for adoption, "Keyed IPv6 Tunnel" (draft-mkonstan-l2tpext-keyed-ipv6-tunnel).
    37 
    38 There are no concerns in L2TPEXT.
    39 
    40 == PCP ==
    41 
    42 The PCP WG met at IETF 89.  The DHCP option spec was submitted to the IESG
    43 just before the meeting, and progress was made on several other documents.
    44 The next rev of pcp-port-set should be ready to submit to the IESG, allowing an
    45 app to request a range of ports (e.g., for RTP).   The PCP proxy spec and
    46 authentication specs are making good progress; the WG discussed open issues
    47 and determined next steps.  The WG also agreed to start work on updates to
    48 the base PCP spec, collecting the deltas on which the WG already has
    49 consensus.
    50 
    51 == HIP ==
    52 
    53 The HIP WG is chartered to finish an old Experimental RFC-to-be and to
    54 revise the main HIP specs, which are also Experimental, into Proposed
    55 Standards. The old Experimental RFC-to-be, the RELOAD instance spec,
    56 has already been published as RFC 7086.
    57 
    58 The WG also has a few "bis" drafts. They revise the old Experimental
    59 HIP specs. Additionally, there are a couple of drafts that are spin
    60 offs of those specs: the NAT traversal mechanism and the multihoming
    61 part of the mobility and multihoming spec. We decided to document
    62 these in separate specs for clarity.
    63 
    64 We intend to request their publication in batches so that reviewers
    65 have the necessary context when performing their reviews. We will be
    66 requesting the publication of the first batch, which includes RFC
    67 4843bis, RFC 5201bis, and RFC 5202bis, shortly.
    68 
    69 == softwire ==
    70 
    71 The softwire working group met in London for a 2.5 hour session. The MAP-E and the lw4over6 drafts had completed working group last call before the meeting. The main goal of the meeting was to resolve the open issues on the lw4over6 draft that had been brought up during WGLC and on later revisions. There were three major issues open in the draft and there was general agreement on the way forward for two of them. The third issue was a bit more controversial as it deals with the relationship between the MAP-E and the lw4over6 documents. The text for describing this will be discussed on the list and included on both MAP-E and lw4over6 drafts. The MAP-T and the 4rd drafts have also completed WGLC and will be progressed to the IESG soon. There were several presentations about potential new work for the WG, including DS-Lite Failure Detection and Failover, RADIUS Extensions for Lightweight 4over6, Prefix Binding recommendations in the Softwire DS-Lite Context, an  IPv4 Prefix for IPv6 Transitional Technology and an Unified IPv6 Transition Framework With Flow-based Forwarding. These presentations were informational as the WG is not currently accepting any new work items until the stateless solution documents are progressed.
    72 
    73 == TRILL ==
    74 
    75 The 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.
    76 
    77 There 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.
    78 
    79 The 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.
    80 
    81 Draft-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.
    82 
    83 Draft-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.
    84 
    85 Finally, the status of the Directory Assisted Edge drafts was presented verbally but there was insufficient time to go into or discuss them.
    86 
    871== 6lo ==
    882
     
    10519
    10620An interesting presentation (https://www.w3.org/2014/strint/papers/35.pdf)  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.
     21
     22== 6MAN ==
     23The 6man working group held a two and a half hour session on the Tuesday of the IETF in London. The session was well attended with over a hundred participants. It was recorded by Meetecho and the audio/video archives are available.
     24
     25There has been active discussions on the mailing list since the last IETF, with over 800 messages. The main topics of discussion has been "Why /64", SSAS, the recommendation for default interface-identifiers, address privacy and efficient ND. The working group has had 5 RFCs published, and currently have no document in the IESG queue.
     26
     27The main topics for the London meeting, was the "Why /64" document, that is a document that explains why the /64 boundary was chosen, and also explores the consequences of changing that boundary, if we ever wanted to do that. There was strong support in the room for adopting this document as a working group document. We also had a 45 minute session to talk about efficient ND. Both with regards to battery efficiency, and how ND behaves on link-layers that do not handle multicast well. The chairs have decided to form a design team to work on this problem, anyone interested in participating should contact the chairs. The design team is expected to report back to the working group at the Toronto IETF meeting.
     28
     29There was also consensus in the the room to adopt the following drafts:
     30
     31        * draft-gont-6man-lla-opt-validation
     32
     33This consensus is being verified on the mailing list.
     34
     35== DHC ==
     36
     37DHC WG met on Monday morning. The session was attended by 60 people and lasted
     382 hours and 32 minutes. We had one RFC (7083, Modification of default values
     39of SOL_MAX_RT and INF_MAX_RT), one I-D is in review queue, 4 I-Ds sent to AD
     40and/or IESG. Chairs were concerned that WGLCs receive not enough reviews,
     41just handful of +1s. The decision was to not start WGLC until there is enough
     42review volunteers.
     43
     44Update about DHCPv6Bis work was presented (good progress, but it essentially
     45just started).
     46
     47The second presentation was about DHCPv6 Failover. The failover-design
     48draft reached AD review, but was essentially rejected. Authors and AD decided
     49to split it into trimmed down failover-design (info) and failover-spec (std).
     50
     51Work on Selecting DHCP configuration based on network topology was resumed
     52after a short hiatus. One more rev is needed. There were 6 volunteers for
     53review, so we'll go ahead with WGLC.
     54
     55Author of Secure DHCPv6 with public key work believes it is ready. 6 volunteers
     56signed up for review, so chairs will go ahead with WGLC soon.
     57
     58DHCPv6 Load Balancing work has been resume after spending more than a year
     59in limbo. There was WGLC over a year ago, but there were several comments,
     60so updated rev was published on Monday. We have 4 volunteers for review. That's
     61less than chairs would like to have, but since this draft has been around
     62for a long time and is very similar to its v4-counterpart, it is enough and
     63we'll go with another WGLC.
     64
     65Stateful issues draft has been presented. This draft fixes several important
     66snags in stateful DHCPv6. Since those changes would affect everyone, chairs
     67felt that the bar is set higher than for average draft. There was very few
     68reviews and only a handful +1s during WGLC, so chairs decided to fail it.
     69This appear to made an impact. 8 people promised to do the review. That should
     70be more than enough to pass a new WGLC once chairs announce one.
     71
     72Stateless reconfiguration (individual) was presented. There are some
     73improvements since last meeting, but it is still not clear whether the WG
     74is willing to work on it. The work will continue as individual for now.
     75
     76Customer Edge Router ID option was presented. It's a proposal that overlaps
     77Homenet, HIPNET and generic CPE deployment. The draft has some DHCP issues
     78(tries to do auth by itself, rather than using standard auth option or reusing
     79secure-dhcpv6 being developed). The AD will follow up to determine the best
     80place for this work to proceed.
     81
     82Homenet Naming DHCP Options draft was presented. It is intended for Homenet WG,
     83so it was presneted in DHC as info only. Several DHCP-specific comments were
     84provided.
     85
     86A new draft about dynamic Allocation of shared IPv4 address has been presented.
     87This is DHC-specific part of the solution. It is expected to be reused by
     88other solutions being developed in Softwires. The room was inclined to adopt
     89that work. Will do adoption call on the mailing list soon.
     90
     91DHCPv4 over DHCPv6 source address option is an extension to the DHCPv4-over-DHCPV6
     92solution that is sent to IESG. This is a very fresh proposal, there was not
     93enough time for thorough discussion and no dicussion on ML, so this topic
     94will be discussed further.
     95
     96The last 4 minutes presentation was delivered by Tsinghua University, which
     97implemented DHCPv4-over-DHCPv6 server and client. It is a nice data point
     98for the draft that is awaiting IESG review now.
     99
     100== DMM ==
     101
     102The DMM WG is about to complete the work on its current charter. The requirements document has already been submitted into the publication process and the second working group document on the current practices & gap analysis is nearing the completing. The next step with the gap analysis is the WGLC, which will be called after the IETF#89 week. The outcome of the gap analysis has pinpointed potential topics and areas of future work.
     103
     104The WG aims to recharter before the IETF#90. There has been vivid offline discussion already on the possible work items and the revision of the charter text. The future distributed IP mobility management deployments are going to look rather different than what tradition IETF IP mobility protocols have been designed for. The DMM WG is not going to restrict itself only to existing IETF IP mobility protocols tweaking.
     105
     106The 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: [https://github.com/jounikor/dmm-re-charter]. 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.
    107107
    108108== DNSSD ==
     
    140140document.
    141141
     142== HIP ==
     143
     144The HIP WG is chartered to finish an old Experimental RFC-to-be and to
     145revise the main HIP specs, which are also Experimental, into Proposed
     146Standards. The old Experimental RFC-to-be, the RELOAD instance spec,
     147has already been published as RFC 7086.
     148
     149The WG also has a few "bis" drafts. They revise the old Experimental
     150HIP specs. Additionally, there are a couple of drafts that are spin
     151offs of those specs: the NAT traversal mechanism and the multihoming
     152part of the mobility and multihoming spec. We decided to document
     153these in separate specs for clarity.
     154
     155We intend to request their publication in batches so that reviewers
     156have the necessary context when performing their reviews. We will be
     157requesting the publication of the first batch, which includes RFC
     1584843bis, RFC 5201bis, and RFC 5202bis, shortly.
     159
     160== intarea ==
     161
     162The intarea working group met in a short one hour slot. The draft describing the use of the IPv6 Flow Label for Load Balancing in Server Farms was published as RFC7098. Internet Area Director Brian Haberman announced the formation of the INT directorate to assist the INT area directors in document reviews. 
     163
     164The draft describing a fragmentation strategy for Generic Routing Encapsulation (GRE) was presented. The intent of the document was to provide guidance to future implementers. The content of the draft was well received by the working group, but there were differing opinions as to whether this work would continue to be a point solution or be folded into some form of generic work on tunnels. This will be discussed on the list.
     165
     166The draft describing issues with IP links in spontaneous wireless networks was presented. The goal of the draft was to raise wider awareness to some issues that need to be handled by IP on ad-hoc wireless networks. There was some resistance to this draft as some people involved in earlier work in the autoconf working group believed that the scope of the problem is much larger than envisioned by this document. The chairs have requested them to have offline discussions with the draft authors and get back to the wg with a way forward.
     167
     168There was a presentation concerning the potential effects of the NFV initiative and the associated data plane acceleration technologies on IETF protocols. The draft authors are looking for feedback from the Internet Area community. Please send comments to the authors. There was also a presentation about the Asynchronous DNS API by the folks involved in an open source implementation of the same. Their goal was to solicit comments and contributions from DNS folks in the Internet area. The draft concerning use of CGAs for Transaction signatures was updated based on comments received from the working group. The draft will be discussed further on the list.
     169
     170== L2TPEXT ==
     171
     172L2TPEXT did not meet in London for IETF89.
     173
     174The WG has a draft being currently polled for adoption, "Keyed IPv6 Tunnel" (draft-mkonstan-l2tpext-keyed-ipv6-tunnel).
     175
     176There are no concerns in L2TPEXT.
     177
     178== PCP ==
     179
     180The PCP WG met at IETF 89.  The DHCP option spec was submitted to the IESG
     181just before the meeting, and progress was made on several other documents.
     182The next rev of pcp-port-set should be ready to submit to the IESG, allowing an
     183app to request a range of ports (e.g., for RTP).   The PCP proxy spec and
     184authentication specs are making good progress; the WG discussed open issues
     185and determined next steps.  The WG also agreed to start work on updates to
     186the base PCP spec, collecting the deltas on which the WG already has
     187consensus.
     188
     189== softwire ==
     190
     191The softwire working group met in London for a 2.5 hour session. The MAP-E and the lw4over6 drafts had completed working group last call before the meeting. The main goal of the meeting was to resolve the open issues on the lw4over6 draft that had been brought up during WGLC and on later revisions. There were three major issues open in the draft and there was general agreement on the way forward for two of them. The third issue was a bit more controversial as it deals with the relationship between the MAP-E and the lw4over6 documents. The text for describing this will be discussed on the list and included on both MAP-E and lw4over6 drafts. The MAP-T and the 4rd drafts have also completed WGLC and will be progressed to the IESG soon. There were several presentations about potential new work for the WG, including DS-Lite Failure Detection and Failover, RADIUS Extensions for Lightweight 4over6, Prefix Binding recommendations in the Softwire DS-Lite Context, an  IPv4 Prefix for IPv6 Transitional Technology and an Unified IPv6 Transition Framework With Flow-based Forwarding. These presentations were informational as the WG is not currently accepting any new work items until the stateless solution documents are progressed.
     192
    142193== SUNSET4 ==
    143194
     
    157208Sunset4. The chairs will send the request to the AD.
    158209
    159 
    160 == DHC ==
    161 
    162 DHC WG met on Monday morning. The session was attended by 60 people and lasted
    163 2 hours and 32 minutes. We had one RFC (7083, Modification of default values
    164 of SOL_MAX_RT and INF_MAX_RT), one I-D is in review queue, 4 I-Ds sent to AD
    165 and/or IESG. Chairs were concerned that WGLCs receive not enough reviews,
    166 just handful of +1s. The decision was to not start WGLC until there is enough
    167 review volunteers.
    168 
    169 Update about DHCPv6Bis work was presented (good progress, but it essentially
    170 just started).
    171 
    172 The second presentation was about DHCPv6 Failover. The failover-design
    173 draft reached AD review, but was essentially rejected. Authors and AD decided
    174 to split it into trimmed down failover-design (info) and failover-spec (std).
    175 
    176 Work on Selecting DHCP configuration based on network topology was resumed
    177 after a short hiatus. One more rev is needed. There were 6 volunteers for
    178 review, so we'll go ahead with WGLC.
    179 
    180 Author of Secure DHCPv6 with public key work believes it is ready. 6 volunteers
    181 signed up for review, so chairs will go ahead with WGLC soon.
    182 
    183 DHCPv6 Load Balancing work has been resume after spending more than a year
    184 in limbo. There was WGLC over a year ago, but there were several comments,
    185 so updated rev was published on Monday. We have 4 volunteers for review. That's
    186 less than chairs would like to have, but since this draft has been around
    187 for a long time and is very similar to its v4-counterpart, it is enough and
    188 we'll go with another WGLC.
    189 
    190 Stateful issues draft has been presented. This draft fixes several important
    191 snags in stateful DHCPv6. Since those changes would affect everyone, chairs
    192 felt that the bar is set higher than for average draft. There was very few
    193 reviews and only a handful +1s during WGLC, so chairs decided to fail it.
    194 This appear to made an impact. 8 people promised to do the review. That should
    195 be more than enough to pass a new WGLC once chairs announce one.
    196 
    197 Stateless reconfiguration (individual) was presented. There are some
    198 improvements since last meeting, but it is still not clear whether the WG
    199 is willing to work on it. The work will continue as individual for now.
    200 
    201 Customer Edge Router ID option was presented. It's a proposal that overlaps
    202 Homenet, HIPNET and generic CPE deployment. The draft has some DHCP issues
    203 (tries to do auth by itself, rather than using standard auth option or reusing
    204 secure-dhcpv6 being developed). The AD will follow up to determine the best
    205 place for this work to proceed.
    206 
    207 Homenet Naming DHCP Options draft was presented. It is intended for Homenet WG,
    208 so it was presneted in DHC as info only. Several DHCP-specific comments were
    209 provided.
    210 
    211 A new draft about dynamic Allocation of shared IPv4 address has been presented.
    212 This is DHC-specific part of the solution. It is expected to be reused by
    213 other solutions being developed in Softwires. The room was inclined to adopt
    214 that work. Will do adoption call on the mailing list soon.
    215 
    216 DHCPv4 over DHCPv6 source address option is an extension to the DHCPv4-over-DHCPV6
    217 solution that is sent to IESG. This is a very fresh proposal, there was not
    218 enough time for thorough discussion and no dicussion on ML, so this topic
    219 will be discussed further.
    220 
    221 The last 4 minutes presentation was delivered by Tsinghua University, which
    222 implemented DHCPv4-over-DHCPv6 server and client. It is a nice data point
    223 for the draft that is awaiting IESG review now.
    224 
     210== TRILL ==
     211
     212The 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.
     213
     214There 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.
     215
     216The 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.
     217
     218Draft-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.
     219
     220Draft-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.
     221
     222Finally, the status of the Directory Assisted Edge drafts was presented verbally but there was insufficient time to go into or discuss them.
     223
     224