Softwire WG meeting IETF 84 THURSDAY, August 2, 2012 0900-11:30 Morning Session I Minute takers: Ole Trøan ** Introduction Induction of Suresh as new chair. Ralph thanking the old chair for the work and the new chair for taking on the challenge. 1. Agenda Bashing, WG & Document Status (Chairs) - 5 minutes Chair going through the document status. No comments. 2. WG Documents - 15 minutes *Public 4over6 WGLC issues discussion - 10 minutes (Peng) Suresh: Needs simplifications. It doesn't have the clarity. It can be revised to be much simpler. Alain: How do you plan to differentiate it from the lightweight version of it? Suresh: We are not sure yet. One is a wg document, one is not. We are not ready to make that decision yet. NN China Telecom: I think solution is very clean. Public 4over6 is very good and we suppoty it to move forward. -------- *Softwire Mesh Multicast (Updates) - Mingwei Xu draft-ietf-softwire-mesh-multicast-03.txt 5 minutes Bechel: July 2011 multicast-address-format dependency. Ole: If you didn't reference multicast-address-format you would likely have a more speedy way forward. Suresh: Offline discussion on how to proceed. Given the multicast-address-format issues. 3. Stateless IPv4 over IPv6 Migration Solutions Discussion - 90 minutes *A converged solution - Wojciech Dec 15 minutes Bechel comment on jabber: Yiu says MAP-T and MAP-E are two different solutions and shouldn't be in the same column. Chairs: Don't answer that. It is to be considered later. Gang: 4rd is not compatible with NAT64, that is not true. Chairs: Remi is presenting his view of the world. Xiaohong: May I ask questions now? What are the criteria in the left side features? Woj: They are desirable for some. Not all of them are... Xiaohong: The mesh isn't applicable to LW46 Chair: Lightweight is not handled as a part of todays discussion. Xiaohong: Sometimes people do get confused when we offer them too many choices. Alain: What you are highlighting here is that there are two modes here. Hub and spoke and mesh. May be the way to look at this is that this is an operational issue. With that in mind, trying to converge provisioning is perhaps something we can leave to discuss later. Woj: You don't disagree that CPEs must be provisioned? Beyond that there is nothing that differentiates the solutions. Alain: As I have said many times we don't use BGP to install static routes. We have decided as a community that hub and spoke is required. Woj: Why cannot we have the same provisioning model? Alain: Too early. There are some simplifications that can be made. Woj: Your point of view is that they should be separate? Two ways of configuring the same thing? Peng: if you only need hub and spoke you only need port range, but if you want mesh you need rules. Woj: It is possible to converge, in the h&s case, for e.g. MAP you only need to configure your concentrator address Peng: My point is that for h&s you only need port range and concentrator. Suresh: The point is that we don't have to go to DHC to ask for a LW option a MAP option and a 4rd option. Ian: Operators like the simplicity of the lw option. We need to look at common provisioning. The way this is worded at the moment, might predispose the answer. Alain: Back to the point that Peng made. The mapping rules as described... In MAP and 4rd they are overlapping, in lightweight these are separated. In a common model perhaps the 3 are different things. And have them as 3 separate solution. Woj: That is exactly what I'm proposing. You ask for it you get the option and if you don't ask for it, then you don't. Francis: I have a problem with bullet 2, putting everything in DHCP is not the right way. It is not possible to serve the two in softwire itself. Woj: I'm not saying which of these are the best. Francis: This discussion should be restricted to things within the softwire charter Gang: I have comments on this work. Many things have happened since A+P. If operators prefer a solution... Alain: Following up on Francis' comment on NAT444, the comment can be translated into, when thigns have to be configured in an IPv4 environment then use IPv4. Simon: In your proposal what do you envision as criteria to be able to combine? For compliance? *Discussion ensues. Simon: Not sure about the effects, approves of the intention. You have an ISP who wants to deploy LW46, what does he write in the RFP? Ralph: Internet AD. You suggest we write a document that lists all those options, an easy solution, we can write each option as a separate RFC, and the ISP asks for the ones we need. NN: I don't want IPv6 prefix in the DHCP optoin. it is useless to me. Mark T: I think it is a bad idea to try to create options that configure technologies that are outside of the scope of softwires. Don't go there. 2nd thing. Complaints I here. Too many options. Try in whatever way we can to have as few solutions as we can. Get the solution place tight and general. Peng: We have a DHCPV4 over IPv6 draft in DHC... Sun: From operators pov, it will be very clear to us to have separate solutions for separate use cases. * 4rd update and feature comparison - Remi Despres 15 minutes Woj: There is NAT44 here so you are updating the checksum anyway. Remi: There is NAT44 on shared addresses, if there is an IPV4 prefix on a site there is no requirement to do the checksum. Remi: The NAT44 does its original job. The BR does not have a NAT44 and we don't Woj: You still look at the ports. * Discussion between Remi and Woj continues. Gang: Replying to Woj' point, this is true if the address is shared, the benefit from the checksum, is mainly on the BR. draft-despres-softwire-stateless-analysis-tool (Remi) Woj: 4rd isn't compatible with NAT64. Remi: Describing the limitations of MAP-T vs 4rd Yui Li: Why is NAT64 a requirement? Mark T: C and D (slide 8) this is a general problem with tunnel encapsulation that could be solved in IP in IP encapsulation in a general way. May be we need an update to RFC2473? Specific to mapping of addressing to that, MAP-E could take the same solution from 4rd. Really the thing that 4rd gives is the reverse header translation. Suresh: There is already an RFC for doing ECN on tunnels. RFC6040? Cheng: There is no use of IPV4 options in the IPv4 Internet. There is a lot of filters to drop those packets. That is a very minor disadvantage. Maoke: About options. Even in practice there aren't many options in use I must say if you use that in encapsulated packets, who knows. In experiments options may be useful. Woj: Compared to MAP-E and LW46 is that they use IPv4 in IPv6 dataplane. We know that those CPEs are compatible with DS-lite, this is flexibility. With 4rd you have a new data plane. 4rd isn't compatible with DS-lite AFTR. Flexibility of deployment is desirable. Remi: If I have a CPE node, it can support 4rd and DS-lite. Cheng: Q for Woj. Although DS-lite and 4rd are more different, than DS-lite and MAP I don't see how it isn't possible to combine? Chairs: Clarifying Woj' point. * 4rd implementation report - Bing Liu 5 minutes Woj: With regards to need to process any L4 protocol. I will restate the comment to Remi. for the NAT44 function you need to look at the ports. Remi: To the same comment. The answer is the same. In the BR there is no NAT44. Woj, Remi, Cheng: Discussion of need to process L4 ports or not. Cheng: This is what we did in our implementation. We only make changes in the orange boxes (slide 2) Remi: We have to know where the ports are present. There is also the checksum, we don't care about what the checksum is. Remi: Are there some first figures of the size of the code? Bing: We haven't covered all the features. About 1K lines of code. We haven't planned to make it open source. * MAP simulation tool demo - Mark Townsley 5 minutes Gang: Can those rules be put directly on a CPE? Mark: We didn't get as far as putting these into DHCP options. Mark: This is perfectly applicable for 4rd as well. NN: Show 1:1 mode. *MAP Testing Results - Xing Li, 5 min Remi: What are the advantage of encapsulation is transparent, and advantage of translation is that you have 'real' IPv6 packets in the network. What would be the purpose? Xing: First we can show that E and T can be mixed. Still can work in mixed mode. Mark T: It is very important that what we go off and tell the CPE vendors is simple and clear. The nice part of this is that E and T mode, that this is something that the user should not care of, only the operator. Go to the vendor and tell him to do MAP, and he'll do both E and T. Thank you for doing that work and showing it is possible. Remi: Thanks to Mark that they want to make the choice between T and E. I don't see this as reasonable as an IETF output. Cheng: How can the operator choose between T and E? Mark / Cheng debate about E vs T mode. How the ISP make the choice? Suresh: Cutting mike. * MAP deployment - Maoke Chen (Qiong Sun) 5 minutes Suresh: This will be adopted. Remi: It shouldn't be restricted to MAP terminology. -------------------- Discussion of open issues and deciding way forward - 40 minutes Suresh: We need to start talking about picking a solution. Implementation reports. We have all the knowledge that we are ever going to have. The question is what are we going to do about it? Feel free to make any statement you wish. Be prepared to defend it. Woj: No mud slinging. Agenda question. The MAP interop, when can I present that? Suresh: Talk about it now. Woj: There is a nice slide set... Cameron: I don't think this group has to choose one solution. The IETF already chose one solution for transition. That's dual stack. It doesn't work. We have started using squat space for IPv4. We failed in doing one solution. Lesson learned there must be many solutions. Simon: Fully agree. Publish all as experimentals and let the market decide. Mark: Then why are we here? Verizon did dual stack... *discussion*... When we select technology that is the right selection, the operational use cases should guide us towards mechanisms. If we try to customize a solution per operator, the problem with that is that as a vendor I end up with doing 15 different things. That's why we end up with standards. And you can use it in many different ways. As few options in code as possible. In particular with retail CPE device... the operator cannot specify what is in it. It has to be everything to everyone on the planet. The discovery of which mechanisms to use even is complicated. That's why we have IP. There are reasons for standards. I applaud the group to have come together for the same algorithm for port mapping. We are bickering over how to get the bits over the wire. I think there is value in identifying which mewchanisms can use existing standards. That is MAP-E. I kind of like the translation option. That is MAP-T. I can tell the CPE vendor one thing. 4rd, the problem there is that we are not reusing anything. IF we are going to choose, then that is the order. MAP-E, MAP-T. I don't see the advantages of 4rd. It cast this balance between E and T, and has a little of the advantages of E and some of T. Let us choose one and let it be MAP-E. Let us stop there. Woj: Presenting interop results. Hui: First point. 2 camps. CPE simple to implement. Operator: Simple to operate. Second point: I don't agree 80% similar that we can merge to one solution. Third point: Not encourage people to include 3GPP case. Xiaohong: Second Hui's comment. As an operator would prefer simple and separated solutions. Making some metaphore with sugar and chocolate... Cheng: We have global customers. They have different understanding of network. We should not go for one solution. The best thing for me is to publish several solutions. Don't mix them together. Separate MAP T and E I can support both. Separate the solutions and publish all of them and make it a marketing choice. Suresh: When Cameron was talking this he talked about different mechanisms, I have an issue with doing multiple solutions to the same problem. This is all about consensus. Cheng: ... Suresh Remi: Back to Mark's comment. I like MAP-E I understand some people who wants MAP-T. Ignoring that it is so simple to have one solution... Maoke: The 3GPP stuff is added by our co-author from China Mobile, we can remove that. Send out the comments to the list. Woj: 1. Simplicty is raised. I think what it comes down to how much code does it take to do this stuff? It is possible to do this. 2. There is some fantastic work being done by some people. The community need a solution Gang: If the wg decides to a single solution. I don't like the combined solution. More complicated for the CPE, BR and network. Tina: 3 main flavours. ... 3 modes defined in RFC6346. having standalone mechanisms for these 3 different flavours. Suresh: You want one solution in each sapce? Tina: Yes. Mark: For the basic problem space. When you are transporting packets across the network, if you extend the problem space... and do things in the network. (cut off by Suresh). If you extend the space, that's where MAP-T comes in. NN: There is a consensus of a combined solution. MY point is that we have to move forward. This wg is too slow. We should move forward. Chairs: Going to ask a series of questions. *Slides* Q1: Do you consider MAP-E and MAP-T to be completely different solutions? A: About the same number of people answer yes and no. Q2: MAP-T will not preserve the DF bit in IPv4 packets in one specific case. Is this important? A: Some people answer yes. Remi clarifies why this is important. Discussion between Xing and Remi, Suresh. Simon: it would break path MTU. ** Coin toss: between MAP being one or two solutions. Ralph is calling. One solution is what Ralph calls in the air. Brian throws. Results is tails: MAP is two solutions. Q3: Which of the following do you want the WG to use as the basis for the MAP-E: 35 MAP-T: 8 4rd: 12 Tina: q for clarification. Suresh: after consulting with the ADs we see consensus for MAP-E. Q5: How many people want to continue to work on them? At a later date? - Advance to experimental? - 30 hands - don't work on them in the wg. - 2 hands. 4. Drafts for consideration by the WG - 40 minutes Lightweight 4over6 and deployment - Peng Wu/Qiong Sun draft-cui-softwire-b4-translated-ds-lite-07 draft-sun-softwire-lightweigh-4over6-deployment-02.txt 15 minutes DS-Lite Failure Detection and Failover - Juergen Schoenwaelder/Tina Tsou draft-tsou-softwire-bfd-ds-lite-03.txt 5 minutes Port Set Definition Algorithms Analysis - Simon Perreault draft-tsou-softwire-port-set-algorithms-analysis-02.txt 5 minutes IP Tunnel MIB Extension for softwire - Shishio Tsuchiya draft-shishio-softwire-rfc4087update-00.txt 5 minutes Stateless IPv4 over IPv6 report - Shishio Tsuchiya draft-janog-softwire-report-00.txt 5 minutes Lightweight 4over6 MIB - Juergen Schoenwaelder draft-zhou-softwire-lw4o6-mib-00 5 minutes END OF MEETING