softwire WG IETF 85 Tuesday, November 6, 2012 1300-1500 Afternoon Session I Minute taker: Ted Lemon ...agenda... ...history... ...iesg submissions... ...document status... Ole Troan MAP documents. Gang Chen: If it's possible, better to make more process, the currently the MAP only cover the encapsulate case, is maybe better to change the more process name for this docuemnt. Suresh: Is it just the title of the document, or do you want the draft name changed? Gang Chen: I think both. #23 What do people think we should do? Suresh: why did you pick 4 bits? All you want to do is avoid 0-1024? Ole: If you want to avoid first 1000 ports... Reason to avoid first 4000, having it on a nybble boundary makes it easier, we avoid well known ports by requiring that this field is larger than zero. Should we have width of shift configurable? Mark Townsley: could you take what's on that slide and describe it in one page? I've seen this described so many times, if you start out and say an IPv4 address is 32 bits, but think of CIDR< could be /24, now we're going to extend that into port range, it could be /38, /40, all the way to /48, go read CIDR. Oh but we're going to skip these first bits. Get that into one page, clearly, I think it would go well. Suresh: fine, but on top of it, do we want it to be changeable, or fixed? I'm for setting it and be done with it. Mark: I think there's consensus that we have to be able to move it by some, I have no problem with it being variable, it's no tthat big a deal. Fixing it makes it simpler. Suresh: one less thing for somebody to think about. Ole: one argument we've heard is you want to give the well known ports to someone. So give them a v4 address. Ted: why skip well known ports? Ole: port 25 blocking #13 Suresh: So your solution is to just document the case that it's true. Ole: no, it's not true. If you gave /28, embed full v4 address into IID, which of the /28 addresses shoudl you use? (mumbles) #3/#20/#21: Peter Lothberg: what's an IPv6 fragment? Ole: a tunnel endpoint is a host; if everybody agrees that we can deprecate IPv6 fragmentation... Suresh: wrong wg Mark: all of this should be prefaced with "do your best not to fragment." There's a PWE3 fragment document and probably others that says if you have to okay, but here's how you avoid it. Simon Perrault: You have different VRs using the same source address, presumably anycast address; why don't they use their unicast address to send packets and receive on anycase address? Ole: Provisioning rules anycast address would receive from non-MAP source address and drop it. Simon: Could it be fixed with versioning? Behcet: I think there are issues in having anycast address as source address, so why are we requiring this? Suresh: what are the issues? Behcet: Cisco web site, anycast addresses should not be used as source addresses. Suresh: open a ticket with a URL to that site. Mark: there is a need. When the packets arrive at any CE, there is a reverse map check on the source address that the packet came from. If it came from any other CE in the environment, it's a fine. If it comes from the BR, it's not. There's a single exception: the anycast address. You either use that, or keep a list of all BRs in your infrastructure on all your CEs, and keep that list up to date. Suresh: what you're saying is that ...? Ole: you have to make sure your map domain and view is sufficient to carry packets without fragmentation. Peter Lothberg: I wish I had a picture to describe this, when it comes to MTU we don't want to fragment packet, if building new infrastructure, on our router side do 9kmtu. Then you end up at the last layer on the way to the customer and you ask what MTU do I set. A lot of infrastructure between edge and customer can carry 1500 byte IPv6 packet, but I don't know what the cystomer have done on his side, so may have 100Mbit ethernet between home gateway and transport thing that connects to my layer three, and is limited to 1500 bytes, or may have toy switch. Two options, on last L3 element on way to customer, set MTU to 2000, ignore fact that packets will disappear into black hole if customer can't handle it. Or I can set it to 1500 and be sure that it works, but will always have to fragment my IPv4 traffic. We can build machinery where customer box can figure out what the MTU is, and go back toward OSS system and tell network to set right MTU, but need to store state somewhere. Maybe have bit ... that says what's MTU. Ole: The solution that the issue tracker proposes, RFC2473 says fragemntation has been done on the ... , in v4 over v6 tunneling we can do inter-packet fragmentation. Do we want to override 2473? Peter: My point is .. I don't want the operator to keep track of it, can we put it in the protocol instead? Mark: if you fragment IPv4 packet. Peter: There is a chance that I can send a large packet to the customer that is a 1500 byte IPv4 encapsulated in V6, there's a chance I can send it to the customer, and I want to do it if possible, but if it won't work I need to keep that state somewhere and want machinery to track it. Mark: But you might wind up having to fragment. Ole: Do you think discovery would be enough-ish? Peter: to do PMTU disc in this scenario have to have packets larger than 1500 bytes towards AFTR. We know that we can do it, so we need to register. If the message disappears, you can't do it, you have to remember that. Encode it in the address. Suresh: problem remains, if you get v4 packet larger than MTU, have to fragment. Put it into two v6 packets, or fragment v6 packet? Peter: v6 doesn't have fragmentation Mark: yes it does, hosts do. Peter: I want to do ipv4 fragmentation, to try to limit the pain. Behcet: It's a draft, don't know if becmae RFC, IPv6ng working group draft. Anycast address in source address cannot be put into IPv6 source address, this is because Ipv6 anycast address does not identify a single source node. Ole: so are we leaning toward allowing inner packet fragmentation? Suresh: keep it open, haven't thought it through. Thanks Peter for recommendation. (To Mark) Didn't you have tunnels draft in intarea that expired tow years ago? Mark: Pekka has one that discusses a lot of these issues with inner versus outer, whether you override DF0, fragment anyway, pros and cons, if nothing else refernece that. Both of these would work subject to the limitations as you pointed out. Maybe we configure something on the BRs so that all the BRs use a different frag id space. Focus on ... Some BRs may be able to handle frag and assembly at v6, with v4 you're punting it off to servers to reassemble. Mark: then you have the problems of not having the ports avialable to do the mapping. Fragmentation just stinks. The third point is the best one. Ian: We've butt up against the same problem with lw4over6. In testing and trials, DF=1 is a bloody nightmare, I think the only thing is to look at 2473 and see if ti needs to be updated. Ole: shouldn't do anything specific in this doc Ian: You've got to work with what's there, send some error messages, hope that end nodes are going to fix it for you. Suresh: not sure 2473 has any text prohibiting that. Ian: it explicitly forbids some things that would be very useful, was what I came away with. Very specific about when the frag must be done. Suresh: when is clear, how is not. We can talk about it. Ian: it's a common problem for softwire. Peter: I ask to have some general architecutre comments. We are already limiting ourselves to TCP and UDP (and some ICMP). So basically if you're looking at it this way, v6 packet is delivery mechanism, truck. We are the guy who are moving the house, table doesn't fit with legs screw on, told movers don't take the leg off. You want the table, we are making the service, knowing what's going on, try to do the best thing to help the customer, TCP accelerator tricks, play with window sizes, make the pain minimal for the customer, becomes an area where the guys who makes the devices can evolve. We are trying to deliver the table using IPv4 fixed thing, take the left off the table. I'm relaying for Xiaohong Deng, isn't TCP protocol MSS negotiation the tool for avodiing fragmentation? Suresh: sure, for TCP, what about UDP? Ole: There might be a NAT44 document Peter: open up the toolbox for creative people to solve the problem. Yiu Lee from Comcast, last time we try to say that MSS rewrite got shoot down, cannot recommend in document. Ole: can you come up with text that makes people decide to do that without saying it? Xiaohong said we never ran into it. Yiu Lee: I don't remember why, but we did give the recommendation. Suresh: I think it came up when 6204bis was discussed in v6ops. I remember some pushback, don't remember why. Yiu Lee: will find out why. #19 What to put in lower bits? ??: Do we have some probe IPv4 addresses have for troubleshooting? Ole: for MAP-T there _has_ to be something. Suresh: the question right now is v4 address, if somebody can propose something better we keep it as it is. Is there something else you want to put in that will be more helpfu? ??: no. I'm wondering if the IPv4 address is what we should put here, or just cuz? Suresh: just cuz. Unless we have reason saying it's difficult, or useless, or harmful, or something is much easier. Peter: you want to leave that so the guy who runs the network can put whatever he wants there. I am fearing that if you get the well known thing, the bad guys will attack, if it's random, the bad guys can't win. Ole: it can't be random. Peter: could be region-specific. Don't make it constant, make it something the admin can set. Ole: you already know his v4 address, why not just DOS him on v4? Peter: we want to protect the infrastructure. The application is going to hit the AFTR, the application gateway, not the customer site. Ole: I would be much happier if someone bombed my garbage truck, not my table. Peter: I want to protect Ipv6 endpoint, IPv6 people were a bit asleep at the wheel, somebody starts walking through the address space, there are things I'd like to minimize. Ole: you'd wind up with same ID for all nodes. Peter: right, but there is 20k operators in the world, so 20k different possible numbers, vs. 1. Mark: Implementaiton question. Is the tunnel to be bound to a /128, a /96, or a /64? Ole: 128. Tunnel endpoint address. Mark: In MAP-T it's a /96. Ole: could do, but then we are tunneling a little bit behind this. Mark: the bound of /128 is canonical, the thing is if I'm putting IPv4 address in there, it's more than just troubleshooting. Be very clear that that is what the tunnel is bound to, and you can only receive on that address and not other addresses. Peter: why do you care about first 64 bits, why not look at last 64 bits? Suresh: V6 routing needs to work. Suresh: Ole, keep it open Ian: you've got a lot of space you're not using, put 32-bit IP address, or subnet? You can go all the way with this, put 32-bit IP address, port set and length of bitmask so it all makes sense. Wouldn't just be helpful in taht case. Ole: if we need routing just for the prefix we could put it there. Ian: if you want to be helpful might as well do it completely. Ole: I thin it does have PSID as well. Ian: You need mask length longer than 32 bits to make that make sense. Mark: that's now more and more stuff that you ahve to get right. Sicne it's the tunnel endpoint that you're bound to, if you screw up you're putting packets on the floor. Peter: maybe avoid to put -1 and 0 and -2 in the middle of 16 bits as that's a mac address. Ian: you can't have it both ways, if there's the complexity of I'm going to put this information there for troubleshooting, why is it too complex if you put all the information there, but not complex if you put part of it? Suresh: no consensus on this issue, take it to the list. Peter: When we looked at this in depth, those 8 bits I'm giving to customer, what's the address on the link to the customer HGW which you are using to terminate this tunnel? So we ware doing PD, and PD-X, and if you basically we have to have a convention on whether we are going to use first or last, what's the number in the brown field? Ole: I haven't gotten that yet, that's not part of that space. Peter: either you're going to use the first address or the last address. Ole: If you didn't give me a /56, but a /56-1, Peter: I won't take that -1 out of the middle. Ole: I don't care where you take it. I take the first subnet you have delegated to me. Suresh: Using prefix exclude (RFC6603), you tell what prefix is excluded, you tell them explicitly. Peter: I got that, ut you have to build a network. We have a L3 element facing customer, link between customer and L3 I don't care about. We put a /64 there. Most likely out of the /56. So then use PDX to say, he may or may not ask for more address space, if yes, is on /64, if asks, on /56. That thing has to be on PDX. You protocol designer do not know what subnet I picked. Ole: we've said take the first one available. Peter: separate subnet or one that's on link? Mark: If we're letting him configuring interface ID, let him configure subnet ID as well. Suresh: Prefix exclude already takes out thing you give on link, so just use that. mark: so use the -1 Peter: use what's on the links, don't take another of his precious 256 subnets. Limits home network to only 2^71 home devices. Suresh: Are you are worring about your mother not being able to configure her network? Mark: what do you do w/o prefix exclude? Ole: what if you don't have global address on the link? Peter: if there is a global addres son the link use it, if not ask for one. More and more state we have to keep. You aren't thinking this through completely. Either we make a decision that it's the one on the link, and operator knows what's on the link and configures AFTR to map, or sles it's completely arbitrary and protocol has to track it. Suresh: are you willing to help with the text? Suresh: Ole, are you going to propose some place fo rthis? Ole: on mailing list. An issue that hasn't been covered on issue tracker, how do we provision this thing? Suresh: please, not yet! Ole: 1:1 mode? Ian: If not now then when? Suresh: DHC. Ole: minor point on mesh mode versus H&S versus 1:1, what MAP does is really jsut create an aggregate, and just as I can do a /48 to suresh, can do a /24 that covers many users, that's the only thing mapping will do. In H&S those rules exist on head end, in mesh mode they are distributed everywhere. Not sure draft needs more clarification. ??: ABout 1:1 are you referring to one IPv4 to one IPv6 with or without address sharing? Ole: all of them but w/o embedded address. ??: If we use 1:1 mode, client can get IPv4 address and IPv6 address decoupled, and a client in 1:1 mode doesn't need IPv6 prefix, just IPv4 address; in this case mapping is not optimized bc it gives me IPv6 prefix that I don't need. Ole: there is no special v6 prefix for MAP, it's just the native v6 prefix that you got. ??: You use DHCPv6 option and suboption, contains IPv6 prefix and IPv4 prefix, and now in 1:1 mode you also get the same form option so Ole: not if you're in provisioning ...? Are you talking about hwo you shoudl provision this node? ??: I just want to make sure client doesn't get sometihng it doesn't need. The client gets what he wants and nothing else. Ole: does it matter? Could give only specific information, but not sure I see the issue. Woj: to clarify, the prefix that is passed in the DHCP option is a scoping prefix, here is the domain prefix, that's it. Suresh: procedure: there are other open defects, do you have other solutions, doesn't need discussion? If you can take a look at them, send proposed solution to the list. E.g. ICMP backhaul impossible. Ole: from feedback I tend to lean toward not doing changes to v6 or v4 tunneling that applies generally to v6 or v4 tunnels. Suresh: fine, go through issue tracker. Ole: take all of these to list, update issue tracker, do rev of document. --- Stateless IPv4 over IPv6 repott draft-janog-softwire-report-01 --- Deployment considerations Simon Perrault Question for WG, right now draft talks about encap and translation. We moved translation to same section, not spread all over. So what do we do about this, do we remove it and only talk about encap? Keep it the way it is? Add stuff about 4RDU? Any ideas, preference? Woj: what you've done is fair, keep it that way, both our working group documents, useful to document unless we want to go separate, MAP-E vs MAP-T. Suresh: 2 or 3? Woj: 2 Simon: vast majority of document applies to both. GangChen: Because this is deployment considerations, is the document ... for specific work, I vote for option one, if general, option 2. Either way I am okay. Mark Townsley: the references section doesn't separate into informational and normative. I suspect MAP-T and MAP-E would be normative references. If either die or get held up, you might be stuck as well. Simon: document is informational. Mark: or structure your document to say.. a normative reference comes in when someone has to read that other document to understand your document. Right now your references aren't separated. Heads up. Woj: this is informational, not meant to be an encyclopedia. Simon: oh, it is! Woj: can add all kinds of stuff. Suresh: how much difference? How many lines of tet are we walking about? One to three, what should you do, what kind of diff? Woj: 2 is already there. Suresh: what's diff between 1&3 and 1&2? Simon: order of a page. Suresh: go ahead with all of them, if something dies we'll pull the doc back and get it out. Yuri from comcast: I want to understand objective, as operator I can just take it and look at it? A guideline for me to deploy? So if we want to mention all three, at least from the draft's perspective, do I have to understand all three? How can this be informational? Suresh: no, has to be normative. Do all three, if MAP-T dies, document will get stuck in queue. Woj: I think that it was said that the deltas from MAP-T and MAP-E are minor in the current draft, so the zero option, removing the section and put it in another document. Less documents is better. --- NAT64-related MAP-T text from softwire-map-01 into software-map-t-00 Behcet: I am confused about NAT64, how can you use it in this case? I thought NAT64 does not have BR, is completely different animal. NAT64 makes IPv6 host talk to IPv4 host, your thing makes IPv4 host talk with IPv4 host. Suresh: compatibility. Behcet: are you using DNS64? --- 4RD Sheng Jiang Just a update on what we've done since Vancouver. Woj: Last time we discussed 4rd did tweak things in IPv6, v octet, compatibility with existing hosts? What did 6man say? Ole: You're adding semantics to the frag id field. Sheng: no, there's no rule for header id in any RFCs, we hust made some rules, this is how we get the frag id. Ole: I can see how it works. Might be a little uncomfortable, the v octet is problematic. I don't want to preclude discussions in 6man, perhaps you should raise issues there. Suresh: should I send mail to 6man? Ole: yes, why don't you do that? Is this a wg doc now? Sheng: yes Suresh: should I split out the pieces? Ole: yes Suresh: I'll do that. --- draft-fu-software-map-mib-00 Also radius attribute Yong Cui: ... Suresh: MIB already contains MAP rule, right, what are the prefix lengths and ea bits. Simon: Are you reusing the tunnel mib? Pres: no. Simon: why? Pres: Because tunnel MIB is defined as virtual interfaces attaches on the physical interfaces, and entry is troed in the devices. But in MAP devices there is no entry at all, it's just calculated. So it's not proper to reuse the tunnel mib structure. Simon: okay, fine. Mark: Subtree of MAP-E MIB. mapTunnelEntry: Is this something that's on the BR? Pres: if the BR support MIB, need some actual code to program this kind of information when it calculated the mapping rule. It is not ... Mark: The question is whether there is per-CE state on the BR that you are trying to gather, capture and present through SNMP? Pres: For the MIB... Mark: because that would completely blow the whole point of stateless. If it's just rules, yay! I guess the tunnel CE address is someting that's giving me.. that's on the BR. Pres: maybe the operator wants some statistic information. Mark: So you've deployed this thing, it supports 20mCE, enable the mib, now it has to spawn 20M copies of something, individual counters, state, etc, you can't do that. Pres: will consider your feedback. Suresh: So did you get Mark's point? If you keep one entry per CE, it's not stateless anymore. Sheng: How many CE per BR server? Mark: 4 billion. Sheng: Per BR? Mark: Ab-so-lutely! Tis is stateless. Sheng: okay, we have 4B items on record! Suresh: It is not about the number, about the concept. I have this working, scaling really well, more CEs doesn't add more state, need to instrument, now you have a zillion entries. Mark: if you need that turn on netflow, but not part of MAP MIB. Peter: this is fine if it's in the HGW. All: It's in the BR. Peter: operators want to know how much the customer is using, and we'll look at v6 traffic. Suresh: There is the concern, Sheng, we can discuss on list. Pres: it's different when the state of the traditional tunnel endpoint bc that entry includes the forwarding, but this info is just about providing some mgt information, even the worst information, information crashes but the ... won't be other. But I will consider this comment. Radius attributes for MAP Peter: in some fixed network they have a BNG. It's not ? Suresh: I don't think you can assume BNG is going to initiate the RADIUS. So just call it RADIUS client or something. You want a point where the RADIUS attributes are going to be put on, it's not necessarily the BNG. Pres: that's true in specific level, but in real deployment it's a common practice. Suresh: in cable network there is no BNG. I'm just saying, peter's point is don't say BNG, and I think it's a valid point. ... Suresh: (flees!) Since we've concludes that this is standards track, would like to ask if the working group would like to adopt this document. --- MAP-T use case Roberta Maglione Gang Chen: the same case in our network but our network has a different situation, we use http proxy and to do the same thing is no problem from encapsulation. So the text in the slides is kind of make me think that is very common case and I think that's maybe not sufficent to say there is a need, there is a case of encapsulation to work. Roberta: how would you use http pxy? Gang Chen: decapsulates not only the L4 information, but information L5, app level information would be decapsulated, so for the tunneling, it could be the feasible to configure some of the /// and configure the outer header and inner header into account, could be very simple. Suresh: So what Roberta is talking about is what's her use case. It's her use case, I'm doing this, it's working for me. She's just trying to document her use cases. Is there anything technically wrong with her use case? I agree there's other ways of doing things, she's saying this works best for me. It's just an individual draft. Gan Chen, if the draft goal is to document something, get consensus in the group, I think we have responsibility to take comments, vaery common case. If purpose is just to doc their onw case that's fine. Suresh: this explains how she's using MAP-T, but it's not an explanation of why MAP-T is needed. Woj: It's necessary to clarify, not everybody may have this use case. Peter: If this slide gets out of context and shown elsewhere, it doesn't have anything on it that indicates where this use case applies. Behcet: My comment is I don't understand why you call this a use case. More like analysis, how you would use MAP-E/MAP-T on broadband network. Suresh: How about using the term deployment scenario? Roberta: I'm trying to describe what I have now in v4, trying to describe how I implement in v6. Next one, DPI and cache appliances. Gangchen: I can't share the same expeirence bc for me DPI is a blacks point equipment and there is likely to be the new application or new service and DPI equipment is expect to be blacks box and identify any information here. I think in your slides there is statement, DPI equipment cannot be ... Roberta: as far as I know talking to different vendors, we don't have devices capable of doing these functionalities. Peter: If customer is using MAP-E, AFTR gateway box is on the right, it's going to be tunneled and there's nothing you can do about it. Customer may use tunnel and not ask you. Roberta: yes, but if I don't use tunnel but use translation, I can identify that traffic. Rob Shakir, BT: I guess I can sympathize, any inline functionality that relies on beign able to see the content of the packet is going to have a problem if you tunenl over it. If there's a way to make the bits of v4 that's great, I don't want to go spend the money retrofitting things in v4. Would rather spend it on v6 capability. Suresh: Please send your comments on the list, we can have discussion there. (END OF MEETING) softwire WG IETF 85 WEDNESDAY, November 7, 2012 13:00-14:30 Afternoon Session I Minute taker: Simon Perrault Softwire Mesh MIB Qi Sun http://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib/ - Deployed in 100 universities - There's a mesh MIB being used for management - WGLC? Chairs will do a review and get back to the authors. 6rd MIB Shishio Tsuchiya http://datatracker.ietf.org/doc/draft-cai-softwire-6rd-mib/ - 6rd parameters are accessible over SNMP - Two approaches - New MIB - Extend tunnelIfTable of IP Tunnel MIB Simon: will this provide stateful stats per subscriber? answer: no it won't Lightweight 4over6: An Extension to the DS-Lite Architecture Ian Farrer http://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite/ - Motivation: - Statelessness - Keeping IPv4 and IPv6 arch separated - This is per-subscriber stateful, a tradeoff between per-flow stateful and fully stateless. - No algorithmic IPv4/IPv6 address coupling. - DS-Lite backward compatibility. - Easy/no logging. - Comparison with MAP-E - In an initial deployment, the two solutions are similar. Single rule for MAP, single lw4o6 binding. Clean. - As things change over time, new MAP domains get created. More rules to be provisioned. - Ends up looking like lw4o6 over time. Woj Dec: MAP in 1:1 mode does this. Ian: Yes, 1:1 is what is necessary. Ole Troan: You don't have to change the v6 prefix. Just need to change mapping rules. Woj: It just looks like a more-specific route. No change in IPv6 address of the customer. Peter Lothberg: You have to make v4 and v6 completely ships in the night. Sometimes you want to renumber every morning. Many reasons for changing in different ways. Ian: An address that is provisioned in a MAP rule can only be used once. Woj: It's exactly the same as with 1:1 mode. (erudite discussion about route summarization) Peter L: If you have 6 different classes of customers, then you make 6 MAP domains. If you want to leverage the feature of MAP, you have to create classes of customers. You end up having a large table somewhere. Woj: Deploy 1:1 MAP without summarization. Peter L: So this is exactly what Ian is talking. Yiu Lee: Exactly. We're saying 1:1 MAP does the job and is what's needed. Mark Townsley: Start with DS-Lite and move the NAT to the CPE. There are some customers that want to go one step further. Add MAP rules to aggregate the routes. - LW4o6 is optimized for solving one problem well - No additional operational complexity for unneeded mesh mode - 8 implementations - 4 field trials - Successful interop between several implementations - Terminology change: lwB4, lwAFTR - Now supports inbound ICMP echo requests Satoru M: We currently operate 1:1 mode but plan to move to MAP. The address sharing feature is almost the same. MAP is not complicated. Ian: You still have to have this algorithm implemented. In LW4o6 you don't need to implement it. Nejc Skoberne: Because of the decoupling of v4 and v6 you can have additional signaling to allocate port sets in a more secure way as compared to stateless mode. Have you considered double translation? Ian: You mean without a tunnel? Nejc: Yes. Ian: No. Nejc: Lots of ISPs have MTU problems because of encapsulation. Also supporting translation would be valuable. Yiu Lee: We don't need the algorithm. Mark Townsley: Scalability comes at the cost of flexibility. I want to help all operators build their networks, but I don't want to customize for everyone. Standardizing for CPEs is even more difficult. MAP-E is the broad solution that covers all solutions. Just use 1:1 mode and everybody's happy. Peter L: How many IGPs do you support? Mark: Because of you guys! Peter L: The number is more than 5. Make the solutions very close so that implementation only differs from a few lines of code. We ran simulations on the number of rules we would need to support our customers. The answer is half. Mark: It's a tradeoff between flexibility and scalability. Either give everybody a rule, or aggregate the rules. Peter L: He's saying it aggregates the config in the box. Mark: MAP-E with 1:1 mode works for you. Alain Durand: I have customers who want one thing and customers who want another thing. I'll give them whatever they want. This (LW4o6) works for them so I support it. Woj: What is the unique use case you see for justifying LW4o6? There's no way for an operator to get scalability with a protocol designed for only this use case. Ian: With MAP we get complexity. Woj: Implementation complexity is not an issue. You as an operator you don't need to deal with it. Ian: All the tools that I will use for MAP will be too complex to use. Ole Troan: Two kinds of complexity. One is operational complexity. Claim that operational complexity is exactly the same. I agree that with MAP you can make it super complex if you want to. But in most cases, it isn't. Suresh: It's pretty clear that the MAP people and the LW4o6 people don't agree on complexity. Ole Troan: I agree that MAP is slightly more complex to implement. Mark T: Complexity is a euphemism for cost. Actually, I'm trying to reduce the cost of implementation at a global level because I'm looking at all of you guys and I make something that all can use. You get the economies of scale from both of your RFP machines. Ian: It would be fairly trivial to implement LW4o6 using your underlying MAP engine. That meets your requirements of having one standard. Mark: We're going to have to do two anyway. The question is whether we're going to have to sell two things or one. Ralph Droms: Can we talk about the specification of LW4o6 and MAP-E in such a way that it appears to be one specification and leave the implementation details to the router vendors? MAP-E has the parameters turned one way, LW4o6 has the parameters turned the other way. An implementer could choose which way to turn the knobs and sell the box to the operator. Suresh: Ian, Ole, take your people together in a room. Not drunk. There is a solution possible. Is there something you can do in MAP to make it easier for him? Let's try to explore that space. Finish this today or tomorrow, before we leave. Ralph Droms: Include me in your email exchanges. I'm from the outside and will ask stupid naive questions. Lw4over6 Deterministic Architecture Ian Farrer http://datatracker.ietf.org/doc/draft-farrer-softwire-lw4o6-deterministic-arch/ - Motivation - Scaling lwAFTR to 100k+ users with 100sGbps of 4over6 traffic - Scaling through many isolated lwAFTR implementations has a number of problems - Parallelize infrastructure - lwAFTRs can be added/removed with minimal service impact - Only IGP reconvergence is required - Enabled active/active resilience model Architecture - lwAFTR cluster - Load balancing of tunnels across cluster members via IGP ICMP - Advertise IPv6 anycast address into v6 IGP - Advertise IPv4 public pools into v4 IGP Mark Townsley: You use ECMP to get sticky load balancing. Ian: Right. Hashing algorithm affects distribution of load. Mark: If one goes down... Ian: The hashing algorithm gets re-run, etc. There will be some packet loss, but no session re-establishment. Lightweight 4over6 Interop Test Report Yuchi Chen - Interop testing at Tsinghua U - 6 participants (Tsinghua U, China Telecom,BII, Huawei, Netdominator, Yamaha) - Over 1400 test cases in total (control plane and data plane) - Some issues with FTP active mode - Client opens data port outside assigned range - Lightweight 4over6 is easy to implement. - Interoperation between lwB4s and lwATFRs that come from different providers is performed well. - Lightweight 4over6 supports IPv4 applications well Parameter Provisioning with non-DHCP-PD in Carrier-side Stateless Solution Gang Chen http://datatracker.ietf.org/doc/draft-chen-softwire-ce-non-pd/ - 3GPP