Softwire WG Agenda @ IETF 90

THURSDAY, July 24, 2014
1300-1500, Thursday Afternoon Session I @ Ontario (C)

Taker: Cong Liu

1. Agenda Bashing, WG & Document Status (Chairs) 10 minutes

Ian: Is there outstanding stuff that need to be done on the MAP-dhcp draft after the last update?
Ole: few comments from dhc wg, will post new version quickly
Ted: Will do AD review on the 4 documents (and map-dhcp) which will take about a week, might be longer if there are substantial issues,IETF last call lasts 2 weeks

   
2. Update of DS-Lite Management Information Base (MIB) - 5 minutes
   http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-06, Sheng Jiang
   
Suresh: talk to mib doctor again


3. Update of Softwire Mesh Management Information Base (MIB) - 5 minutes
   http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-06, Qi Sun
   
Suresh: same comment, go back to mib doctor
   

4. Consideration on Unified CPE - 5 minutes
   http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02, Ian Farrer

Andrew: It's something useful to work on,but it's best to take the running code, see what works best, then document    
Ian: As I understand from the implementation, all of the DHCP options are described, DS-Lite is there as well. 
     If you were to throw configuration for all four, what would it do?
Andrew: I didn't test it so far.
Ian: Maybe a better quesiton is what should it do
Suresh: To get sense of the room, is this something IETF should do? Should we provide guidance on how things should be implemented together, or are the people gonna implement what they want anyways? Should we put more cycles into this?
Andrew: We need experience, by running code and making mistakes
Ian: I'm not sure what experience we are looking for. If you've got these things in your network,
     with clients that support it,the question is one of policy without saying this is what I prefer you to use if you support it.
     Some kind of conveyance mechanism for that policy is what seems to be missing.
Suresh: Another thing I'd like to add is that the goal of this document is to say these are the common building blocks between the solutions,
        don't write duplicate code for them. Who knows it better than us?
        We as a group should be able to see what are the abstractions in this mechanism and put them on somewhere
Andrew: At least MAP-E & lw4o6 did not require new code in the openwrt
Ian: So this is nothing to do with code/implementation. It's about you've got all those things however you manage to do that.
     Which one should you use given the presence of configuration for more than one.
Ole: Do we have to define some use cases, what model do you expect, CPE includes an ORO for all the things it can and then ISP returns the single one it prefers? or does the ISP give back a bag?
Ian: This is the problem at the moment, it would just give back a bag.
Ole: Does it have to? CPE give their preference and ISP also give preference back
     Why give the complete set back, not single mechanism
Ian: That's what dhcp implement. You ask a question, if it's configured, you get an answer. There's very little ability to put conditional logic in there.
Ole: if CPE only include one mechanism in ORO, server would give one answer back
Ian: DHCP client will send ORO that says these are all the stuff I can do because I don't know what you've got
Ole: You can make a static preference table that client implements, only allow one mechanism at a time
     If your requirement is to sunsetting from native v4 to dualstack, need to have both working at the same time
Ian: Could be as simple as saying if you had a preference value for all the ones supplied, the client picks the one with the highest value, then it gives a stateless way of doing this
Ole: If equal, why can't use both, really renumbering situation
Ian: You give this to the client, the client can still choose what to do, or someone can hand configure it if they want.
     All you're saying is this will work for people who don't mess around with it. You can't stop someone from doing that.
Michael: Where do you want the complexity, server side/cpe side?  Should be solved
Andrew: Very specific use case needs to be solved ASAP, the deployments that do have DS-Lite for example, migrating that to somewhere else.
        For startup, worthwhile to narrow the scope to solve that practical problem, then generic
Suresh: ask ISP, is anybody plan to deploy more than one mechanisms in the same network? 
Ian: (DT)Yes.  
Suresh: I don't see the use case, makes easier for CPE
        DHCP server doesn't have to give all options in ORO
Michael: Can skip perference table, CPE starts to ask one thing at a time,traverse through the mechanisms.
Suresh: That's not what I meant. tell operator what I support, operator pick one and give back
Michael: When migrating between different CPEs, how to sunset lw4over6 for the next thing we want to do in five years?
Suresh: A CPE supports both lw4over6 and the new technology, or you have preference on the Server side to use the new technology
Michael: So it's server logic now. Server side logic is bad for small ISP with little people maintaining the DHCP server
Ian: even if the answer is server side logic, is this something we need to work on further?
Suresh: I think so, take to mailing list


5. Mapping of Address and Port (MAP) - Deployment Considerations - 10 minutes
   http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-04, Gang Chen
   
Suresh: Biggest open issue is the scope, do you want one document to cover all softwire solutions?
Yiu Lee: What's the motivation to combine multiple into single document, do you expect operator deploying two solutions look at the same document?
Gang: This was raised by participants from another meeting, personally I think should be seperate documents
Ole: Should take all of them (464xlat and this one) to make deployment consideration and move to v6ops
Qi: Think MAP/lw4over6 focus on different scenarios, it is guidance for operators on how to use the mechanisms for deployment, support seperate documents
Ida: not sure should put all different deployment in one draft
Ian: This is a comfusing space for an outsider,there are a lot of different solutions, so something like this is useful.
Chongfeng: MAP and lw4o6 are different, support seperate
Suresh: I don't think it makes sense to have 2 documents: either have one document covers all things, or have one document per mechanism like map-e deployment, map-t deployment etc.
        Take it up on the list. Probably talk to v6ops chair if they are interested.
Ian: Only way to avoid repeating discussion, make seperate document for each mechanism
Gang: First 3 mechanisms (MAP-E, MAP-T, 4rd) have similarity, lw4o6 is totally different
Suresh: There might be duplication, but it's one documentation for a person to read. If you've chosen Map-E, you just read Map-E, instead of picking sections through a document. 


6. Deployment Considerations for Lightweight 4over6 - 5 minutes
   http://tools.ietf.org/html/draft-sun-softwire-lightweigh-4over6-deployment-04, Chongfeng Xie
   
Suresh: think the experimental result is valuable.
Yiu: suggest update the draft and post the changes since ietf87 to mailing list. See whether it is more capable to move this work to the v6ops.
Ian: will contribute
   

7. Recommendation for Prefix Binding in the Softwire DS-Lite Context - 10 minutes
   http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix-binding-02, Suresh Vinapamula
   
Ian: Is this based on actual problem ?
Suresh Vinapamula: Yes
   

8. Unified IPv6 Transition Framework With Flow-based Forwarding - 10 minutes
   http://tools.ietf.org/html/draft-cui-softwire-unified-v6-framework-00, Cong Liu
   
ei: doesnĄ¯t specify some new stuff, using exsiting tools to configure a switch. This is like a product thing.
Cong: this is framework
e: not look like a standard
suresh: It's something informational. We are trying to find out if it's useful, what do you think is its use to somebody?
e: I don't know that it's of use to me 
Andrew: I see the added complexity to the existing CPE code. It's some what interesting in itself just for its own purpose, but beyond that...I don't know
Ian: are we sure about this per flow? There are thousands of flows per second being created. Are we really sending every flow to be provisioned by the controller?
Cong: CPE is able to handle per flow. it doesnĄ¯t have to. The controller has the ability to tell CPE what to do.
Suresh: open flow switch doesn't do anything by itself. There's a table it looks up, if there's a miss it sends the packet to the controller.If there are a lot of packets coming in, it doesn't scale, that' Ian's concern.
Cong: Can install default rule to handle all packets, maybe foward them to an interface which would do all the things for all traffic.
Ian: Then the question is what is the open flow controller actually adding? Why not just have the default rule?
Suresh: Ian, send your comments to the list


9. Dynamic IPv4 Provisioning for Lightweight 4over6 - 10 minutes
   http://tools.ietf.org/html/draft-liu-softwire-lw4over6-dhcp-deployment-03, Cong Liu

Ian: diagram. syn between dhcp 4o6 server and lwAFTR, no solution now. define a protocol here? 
cong: It could be used by dhcp 4o6 / netconf, but in this draft we do not want to define new protocol.
Ian: If you don't specify that part, then we've only got a partial solution.
Bernie: One suggestion might be to use the new active lease query stuff
Ian: I didn't say there was no way of solving it, I'm just saying there needs to be a described way. Something definite that can be used for this. 
Ted: do you know about active lease query?
Cong: In this case the DHCP4o6 server is not dhcpv4/dhcpv6 server. If it can connect to Ipv4 network, DHCPv4 lease query could be used. If Ipv6 environment,the protocol may need to be extended.
Ted: Inorder to use active lease query to provide DHCPv4 binding to the AFTR, it would have have to support both v6/v4, which currently it doesn't. Is that what you were saying?
Ted: to dhc wg
Bernie: It's just a tcp connection, does not say ipv4 or ipv6. There could be words to make that clear, but there's nothing that prevents it. 
Ted: Don't have to really change the document, maybe we should say "you should support receiving connections for active lease query on either IPv4 or IPv6".
Suresh: Too little people have read the document, take it to the list again.



10. DHCPv4 over DHCPv6 Source Address Option - 10 minutes
   http://tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt, Qi Sun/Ian Farrer
   
Ian: The previous presentation relies on this one. Another draft being adopted in the dhcp for the allocation of shared addresses. The whole thing is solution with several component parts, without any one part of it, it doesn't work at all
Suresh: going to have a reading contest after the meeting

Suresh: About MAP-T scenario document, will do a call on mailing list

11. IPv6 Multicast in a 6rd Deployment - 10 minutes
   http://tools.ietf.org/html/draft-zhou-softwire-6rdmulticast-01, Behcet Sarikaya
   
No comments

12. Multicast Support for Mapping of Address and Port Protocol - 10 minutes
   http://tools.ietf.org/html/draft-sarikaya-softwire-map-multicast-02, Behcet Sarikaya

Yiu: For encapsulation approach , BR just send unicast to CE, what's new?
     Just tunnel all packets over unicast tunnel, it's nothing new you need to document
Suresh: It specifies the idea of an IGMP proxy; nothing new here
Andrew: Better to push to have native IPv6 muticast 
Suresh: You don't see the value of supporting v4 multicast?
Andrew: it's harmful towards moving the industry to IPv6 multicast
Yiu: already have underlay multicast network, why not just use underlay
Behcet: lw4o6 is similar, plan to have one section in next version
Suresh: Take on list, first figure out what we need