Softwire WG Agenda @ IETF 94 Thursday, November 5 13:00-15:00 Afternoon session I @ Room 303 Note Taker: Lishan Li Agenda Bashing, WG & Document Status (Chairs) Suresh: another thing is discuss the milestone. Feel free to comment. Seeking for new work. Ian: Have got many comments. Would you please post an update of the milestone based on those comments? Suresh: exactly. Slightly revise the milestone based on the opportunistic items. Adding new staff has very high bar. Will have a hard time getting review for docs. Radius for MAP: Present the changes according to comments from mailing list. Moving forward? Ian: Why removing MAP-T? Yu: MAP-T has some other sub options Ian: Some sub options may or may not be included, it not clear in there. For example, the provisioning of PSID values, you may or may not need. Suggest to include MAP-T. Ian: It’s possible to cover both modes with different sub options. Section 4.2. Yu: Technically, it can be done in one doc. Can define some sub options for map-t. Will look into that. Ole: map dhcp defines containers and sub options. You can mirror the radius stuff on the dhcp stuff. All the three flavors in one doc. Ian: Another doc for lw4o6 radius, including both dhcpv6 provisioning and dhcpv4odhcpv6 provisioning. The radius for dynamic lw4o6 could be in another document. Yu: Some in the wg suggested to merge lw4o6 radius into this doc. Linhui: We have unified YANG, unified CPE. Unified radius is reasonable. Ian: List what’s in the softwire dhcp option and document it here. Easy to have one goal. Yu: OK. Suresh: Yu, do you know what to do now? Summaries to the list. Radius for lw4o6 Qiong: Agree to merge. Ian: Is there complete provisioning mechanism using PCP? Qiong: Yes. Ole: This has expired. Qiong: Yes. Ole: Not use the mask. Suggest to merge. Ian: Intend to deploy, but because of loss of dhcp relay function, want to use radius. Unified CPE Ian: Previously, use the combination of dhcp options. Now use identifier. Option Code and a priority field. Bernie: one option code the priority, another code the same priority. Ian: yes. The behavior for more than one sw mechanism Ole: multiple ISP. Same priority from different ISPs. Ian: You could. But that would be different DHCP messages on different interfaces. Ole: Right. Use case for this? Transition from one to another. You make life harder. Ole: drop the priority field. Tomek: From DHC prospective, it would be cleaner without priority field. Ian: No need to configure more than one softwire mode simultaneously. Ole: Can’t send dhcp messages to right client. Ian: A client supports more than one mode. Ole: client requests all you support, server replies with the preferred one. This is not needed. Ian: That is not how server works. Doing that is hard. Bernie: Sever can do that (i.e. gets all kinds of requests but replies with that particular one), but the problem is how fast it can be deployed. Ian: We have two dhcp vendors developing that. You can do that, but the performance is bad. Ole: simplify the client. Ian: Openwrt or commercial CPE. ??? Suresh: See what is practical. The point of this doc is the common part of the mechanisms. Ian: what is next? Suresh: sense of the room: work on the draft hum (many people). Not work on the draft (Ole). Take to the list. I personally see the value of doing this. But if there is not much energy the should drop it. Ole: Gather vendors together to discuss whether should do this. Ian: The most who care are those building the service. No work be done, or some work be done. Ole: don’t disagree. Ian: if we drop the draft now, then there will be no work done. Suresh: Ole, do you think it makes sense to put other options in the draft? Need some guidance on this. We have to write something done. It could be informational. Ole: For the client, You could define a static list of option orders. Publish such a RFC. Suresh: that would take 5 years. Never be there. Ole: if it adds some value, then can try. Bernie: Most would only have one tech anyway. Ian: No. Bernie: Analyze in the draft. Ian: Many ISPs now running DSlite, but how to go to next. If Openwrt supports all of the functions, the migration is the problem. Linhui: Need this general work. Combine unified CPE with the CPE YANG profile? Ian: No. Currently no YANG for managing this. Discuss offline. Suresh: No reference to the YANG profile. Linhui: Maybe it’s out of scope of this topic. Suresh: I think so. MAP deployment Qiong Sun Cover MAP-T/E, 4rd-U WGLC? Suresh: Can we get some reviewers? Volunteers? Ole: Need v6ops review before publishing it. Just become RFC, very little deployment experience. Get review from MAP perspective. Ian: deployment exp doc in v6ops. Not clear about the difference between deployment consideration doc vs. deployment experience doc. Deployment experience doc is more valuable. Question: What’s the purpose of deployment consideration doc vs. deployment experience doc. Linhui: Considerations is prior to large scale deployment. China telecom deployed some networks but others don’t. They need considerations on how to do that. Qiong: Guideline for deployment. This is about what you need to think and to do in the deployment. Ian: Still think it’s goanna be a problem Lee Howard: v6ops Chair hat off. Finding More reviewers is useful. In addition to the exp you’ve had. Hat on, don’t think this is in the scope for v6ops, but welcome to call for reviewers in v6ops. Suresh: I will send mail to v6ops. Yu: Considerations are guidelines. Exp is to share info for this. This is the difference. Suresh: Ian’s meaning is that you deploy that you got the exp. lw4o6 deployment Qiong Sun Linhui: difference: using dhcp4o6 not pcp Ian: with dhcp4odhcp6 how to allocate port set Linhui: use that option. Ian: not dhcpv4ov6 but dhcpv6 Linhui: Not sure. Ian: logging question. Is this be tackled in the map deployment draft? Qiong: if using map, it’s determined. If using dynamic way, report logging. Ian: depending on sharing ratio etc. depending on which country. Ian: Support the doc, also as a contributor. Linhui: support Suresh: continue on the list. Softwire YANG Linhui Sun Ian: Need to get the text right. Make sure an implementer understand what to be referenced. Lin: Fragmentation not needed. Because it’s complicated. Ian: Fragmentation or not able to support it mess you up every time. Need to list out the determined interface configurations / find the configuration options to expose. Ole: MAP-E allows inner/outer fragmentation. MAP RFC said please do not fragment. Make sure MTU is managed well. How much fragmentation would be Conner case? Ian: lw4o6 / PPPoE. PPPoE, v6 headers. Ole: we need a YANG model. Suresh: a lot support for the doc about adding to the milestone. Add to the milestone. RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes Wei Meng Suresh: Anyone has reviewed the draft? Linhui: I have reviewed the draft. And will review again and post the comments to mail list. Wei Meng: I wonder know the process of the recharter. Or discuss the recharter on the meeting? Suresh: The question is anybody needs it. And it need more review Terry: Before the new milestone or recharter, the more review is needed. Suresh: Continue the discussion on the mail list. A Redundancy Mechanism for Dual-Stack Lite Yu Fu Ian: Not clear that what the document to do here. Yu Fu: AFTR devices may have other new requirement. Ian: Show the architecture slide. Qiong Sun: This is a deployment suggestion, not introduce a new protocol. Lee Harward: This is a good idea, which provides the redundancy mechanism. lw4over6 source address option & dynamic provisioning Ian Farrer Ian: Is there any problem from DHC WG Bernie: The following DHC WG will discuss this problem. Should listen the options from the other DHC guys.