softwire WG IETF 86 Monday, March 11,2013 0900-11:30 Morning Session I Minute takers: Ole Trøan and Tom Taylor Ralph: Stepping down as AD and introducing the new AD Ted Lemon. Agenda discussion: Ian suggests changing order of unified CPE, MAP-E and lightweight 4over6 Suresh: OK, you go first then. Administrative and WG document status, Chairs, 15 minutes Yong presented the WG document status. Suresh: Will talk to abstaining ADs about stateless motivation draft. Shishio: I did a presentation about 6rd MIB. I think 6rd MIB is ready to be adopted as working group document. Suresh: We will ask on the mailing list. DS-Lite Management Information Base (MIB), Yu Fu, 5 minutes https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib/ No comments. Softwire Mesh Management Information Base (MIB), Qi Sun, 5 minutes https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ Suresh: I’ll take a look at the latest document and then issue a working group last call. Unified CPE, Ian Farrer, 20 minutes http://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe/ Tom Taylor: Wouldn’t it be simpler to send a single parameter stating, please use this mode? Ian: Yes, you could do that, but how would you do it. Tom: We put together a paper on what you need in diameter on what you need in the provisioning system. Made provision for an enumeration of methods. I can’t talk DHCP in particular. Ian: It is the presence of the option that determines the mode. Tom: I’ll review. Suresh: The idea is that if you have a DS-lite B4 then it is expected to continue to work. Ian: Having the ability to know in a mixed mode CPE is very useful... Ole: Commenting on DMR. Fine with using the RFC6334 option. Suresh: You still have two methods, EA-len = 0. Ian: It wouldn’t do that in that case. Qi: LWo46 draft has been updated to align with the unified CPE model. Ian: We haven’t finalized the DHCP option Mark T: “Good job, great to have a single CPE that can support narrowed set of modes.” Satoru: MAP rule is not only to define port ranges, but how do you define local endpoint address of the tunnel? Ian: The endpoint, the local IPv6 address? There are two ways you can do it. You don’t fundamentally have to do it, depends on provisioning systems. But experience with a proof of concept. It might be best to tell the CPE directly what address to use. Yang: Submitted some draft “*naming*” …. ? Discuss offline Xing: You mentioned DHCP. About DHCPv6 and PCP what about these things? Ian: These things were pointed out on the mailing list. DHCP is provided as an illustration.It could be something else. Xing: Only discussed the parameters, the document is fine, it is only the parametersyou cannot implement. How about MAP-T and others? Considered? Ian: MAP-T it was not considered and in scope. Tomek: Do you think the OPTION_BIND will be specified in the MAP DHCP draft? Ian: Yes, and perhaps call that the softwire configuration option draft? Tomek: Should the draft be kept as it is with a new name? Suresh: It is not so important to change the name. Makes sense to fold this into the MAP DHCP document. Alain: Response to Suresh. At this point it is perfectly fine to wait for the outcome of the DHCP transport but then add normative text. Alain is suggesting that all documents should be working group documents. MAP-E Open issues discussion, Ole Troan, 20 minutes https://datatracker.ietf.org/doc/draft-ietf-softwire-map/ Tom Taylor's proposed text will not be added unless requested by more wg members. Suggested resolutions for #18 Title and file name no comments in room - closed #19 IPv4 address in MAP-E interface IDs again no comment in room, closed #21 Fragmentation must not be handled according to RFC2473, need normative text in draft Alain: DS-Lite handles frragmentation OK Ian: Difference with more intelligence in concentrator Mark: Could engineer a network to make this never happen, but since stuff happens, should design to eliminate. Alain: That is overengineering. Conclusion: to the list. Ted: to the list since no agreement in room. Could the parties concerned get together? If Remi is sole objector, Chair is entitled to make a call anyway. The disagreement was in this room too, however. Further: even with multiple discussants, Chair eventually has to make the call. Ole: nature of disagreement is more in the nature of: may be a problem, MAP document isn't the place to fix it. Mark: do have to supplement reference in this document to 2473 with description of the potential problem and how to avoid it. Then say problem is being worked on elsewhere. Summary of agreement: MAP document continues to refer normatively to 2473. Notes problem, for which no solution currently available. Work on a 2473bis draft to cover the problem. #25 Maintain or remove MAP1:1 mode? Ian: either delete incomplete description or expand on it. Qiong Sun: remove 7.4 and example in Appendix. Ole: change mechanism or just the text? Resolution: Qiong to propose text changes. Jan Z: 1:1 mode good for gradual deployment. Start with unshared mode, then transition to address sharing. Wojciech Dec: not clear why 7.4 needs to be taken out. Suresh: It takes nothing away from implementation. ???: will PSID option still exist? Yes. ???: What happened to the offset parameter? Ole: Has been simplified. Tom Taylor: what should be the value of the offset? Suresh: Put it as 6 and see if anyone objects. ACTION: example to be renamed since there will be no further explicit reference to 1:1. Tom Taylor: Purely editorially speaking, Appendix B is unnecessarily obscure. Suresh: Put the issue in the tracker and propose text. Lightweight 4 over 6, Ian Farrer, 20 minutes http://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite/ Ole: Support with the provision that it uses the same port mapping algorithm and the same provisioning mechanism as MAP. Ian/Suresh: Updated with two revisions in the last two weeks. Adoption call. Strong support to adopt. Port set algorithm: Contiguous or not, Qi Sun, 10 minutes http://tools.ietf.org/html/draft-ietf-softwire-map-04 http://tools.ietf.org/html/draft-sun-dhc-port-set-option-00 Tom Taylor: The argument for not using a = 0 approach it would constrain the IPv6 addresses on the endpoint. Couldn’t assign 0. If differentiate between port set identifier and index. You got throw away PSID==0. If you divide the range... never mind. Subtract the ports from the index. Francis: The complexity, there is a choice where to put the complexity. You can put the complexity in the CPE or in the ISP box. Be contiguous from the CPE to the ISP box. And be not contigous on the ISP side. Should be called port range router. Suresh: What’s the goal of this? Are you proposing to change MAP? (NO) *Discussion* Suresh: If someone feels strongly that the offset should be 0, please raise your hand. (NOBODY) Wojciech: There is some confused use of terminology between a == 0 and contiguous ports. Alain: noted desire to have same algorithm for LW4over6 and MAP introduces complexity. Not sure how it works with non-contiguous port sets. Affects packet filtering. Wants to be to configure min-port, max-port. Woj: whole point of this architecture is to simplify CPE device. Suresh: proposes compromise where MAP-E fixes a at 6 and LW4over6 fixes it at 0. Ted Lemon (not as AD): sees no advantage to port scattering. Mark: nothing to do with security. Yes, could add flexibility, but each option has a cost. Alain: basically two approaches: database versus PSID and GMA. Mark: In terms of forwarding, a port range that falls on a bit boundary is a lot simpler, and that needs to be preserved. Tom: The structure is exactly the same for both structures.You need something to indicate the block size, in the contiguous case the block case is 64K. the default is 1K. the structure is the same. Suresh: That’s not the same. My suggestion was to have two options for offset 0 and 6. We need to take this further on the list. Obtaining IPv4 parameters in IPv6 networks, Ted Lemon, 30 minutes Discussion Wojciech: Can you propose a time or a venue for the discussion? Ted: It is in the DHC agenda. Woj: It would be good if we could huddle. Ted: It would be good if we could do it on email so we could be clear. Alain: There would be requirement for IPv4 stuff. What’s the address of my IPv4 SIP server. We know that this is coming. This is a DHC problem, not a softwire problem. I would like to remove all the softwire issues from the discussion. We should have the discussion on the mailing list. Ted: We have actually tried to make it purely a DHC thing, and that has failed. The DHC group Wojciech: One of the key hard to quantify is that some people view this as transition to IPv6. I agree that there are some that will put all the old baggage of IPv4 on these different customers. We shouldn’t recreate how to run IPv4 over IPv6. We need to move people to IPv6. Ted: You agree that there will be people who will configure IPv4 options Woj: Yes Ian: Requirements coming from softwire and dhc. Gather the requirements and map the solutions to them? Ted: What I would like to happen. I would like to have your draft, a couple of solutions added, and then I would like to have feedback from softwire, on what benefits and problems a solution would have for me. Then that feedback folded back into the Ian’s draft. Suresh: Analysis left out one thing. The complexity of the CPE. It boils down to a judgement call. Do I want one IPv4 parameter or do I want multiple things in the future. That would lead to a different solution. Ted: The CPE implementor has the choice of which options to support. Suresh: The document needs to reflect that there are multiple preferred solutions based on how much IPv4 configuration is needed. softwire WG IETF 86 Wednesday, March 13, 2013 09:00-11:30 Morning Session I Minute taker: Ian Farrer 4rd ug bit clearance and 4rd identifier in IID Sheng Jiang no draft Suresh: What happens if the U&G bits go away? Ole Troan: Discussion in 6man: U&G bits have no meaning. Any address must do Duplicate address detection. Ole: Slot in 6man, can be discussed there Sheng: Identifier is to show if it's a 4rd packet or a native packet. It doesn't conflict with any existing addresses. Ole: Let's take the discussion to 6man MAP-T updates Xing Li https://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ Suresh: Send a question to the mailing list requesting to close the items in the tracker. MAP deployment Qiong Sun https://datatracker.ietf.org/doc/draft-ietf-softwire-map-deployment/ Wojcech Dec: Consider adding lw4o6 to the documents so that the draft covers all softwire mechanisms (except DS-Lite) Gang Chen: Including lw4o6 makes a different consideration for the concentrator, so it shouldn't be included Woj: The only difference in configuration. this is the right doc to put it in. Gang: I'm not arguing about the concept of stateless. It is a special consideration on the concentrator part Woj: All deployment considerations can be equal for any of these. Gang: There is a special document for lw4o6 Woj: They should be combined for all of the deployment considerations Ole: This aligns with the unified CPE approach, have one documemt Suresh: unified CPE doesn't cover translation Ole: There should be one deplyment doc for the standards Gang: If you want to cover all of them also include DSLite Suresh: Not enough people to make a decision. Ask on ML Tom Taylor, Qi Sun, Ian Farrer volunteered to review. Gateway-Initiated 4over6 Deployment Yuchi Chen http://datatracker.ietf.org/doc/draft-chen-softwire-gw-init-4over6/ Ian Farrer: How does the LCRA tell the difference between a 'regular' LAN interface configuration DHCP request and a request that needs to be relayed Yuchi: The 4over6 client /relay would be configured for this Ted: Is the motivation to give a public v4 address within an isolated network. Is that the sole motivation Yuchi: Yes Ted: That wasn't clear from reading the documet Qi Sun: We don't have to modify the client for this Ted: In the case when you don't want to modify the client. You could give it a private address Yuchi: If the host wants to be a server, then it's better if it has a full address Ted: We can talk about it offline MAP-E MIB Yu Fu https://datatracker.ietf.org/doc/draft-fu-softwire-map-mib Shishio Tsuchiya: Some ISP need this, but it's better to use IPFix or Netflow. MAP traffic counter in the MIB is not needed. Suresh: just the object or the MIB itself? Shishio: Just the tunnel object. Suresh: So you're saying that if you want to do full tunnel monitoring use IPFix. Shishio: MAP-E MIB should add an object for security check status Sheng: Should this security check be a generic translation mechanisms or specific to MAP/ Shishio: MAP-E & MAP-T has the same security mechanism, so we could add the same check Yu: This could be moved into a separate MIB Suresh: How many people have read the doc? (Few hands) Suresh: Who's planning on reading it? (fewer hands) Yong: Can people please read it Woj: Don't we have it our charter to create MIBs? Suresh: We'll ask for adoption on the list. Please read it. MAP-E Radius Bing Liu https://datatracker.ietf.org/doc/draft-jiang-softwire-map-radius Tom: Cathy Zhou and I have created a similar draft. I will provide a comparision to see what we can learn from the differences Woj: Are you always expecting that the MAP attribute, or is it optional? It could be useful to have a case where you only have the DHCP solicit. It wouldn't have to have the MAP attribute Sheng: That's already there. It's not in these slides as they're only an update Suresh: so it does cover the case where the request doesn't have MAP attributes, but the response does. Sheng: Yes RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes Wei Meng https://datatracker.ietf.org/doc/draft-hu-softwire-multicast-radius-ext/ 15 minutes Suresh: Has anybody read this draft? (Nobody) Suresh: We'll discuss this on the mailing list Encapsulating IP in UDP Xiaohu Xu http://datatracker.ietf.org/doc/draft-xu-softwire-ip-in-udp/ 15 minutes Rajiv Asati: We need a stronger motiviation in the draft. Just because we can do it, doesn't mean that we should, Xiaohu: What's the motivation? Rajiv: Use cases? Xiaohu: The motivation is to get load balancing based on the 5 tuple Xiaohu: This is more useful for softwire mesh than hub and spoke Rajiv: That's what I mean, you need to explain this. Suresh: How many people have read the draft. (Very few hands) Suresh: We can't start an adoption call if only this many people have read the draft. Suresh: Try and come up with a better motivation and send out on the list. You can use the old motivation discussions on the mailing list for DSLite etc. BGP Tunnel Encapsulation Attribute for UDP Xiaohu Xu http://datatracker.ietf.org/doc/draft-xu-softwire-encaps-udp/ Yong: Please think about the use cases and post to the mailing list. DS-Lite Failure Detection and Failover Juergen Scheonwalder http://tools.ietf.org/html/draft-tsou-softwire-bfd-ds-lite-04 Ian: For an anycast model, why do you need to have a keepalive for the client? The network needs to identify failure and reroute Juergen: The main reason would be for error reporting rather than error detection. Yong: Please read the draft and discuss on the list.