* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Softwire Status Pages

Softwires (Active WG)
Int Area: Brian Haberman, Ted Lemon | 2005-Dec-08 —  
Chairs
 
 


IETF-84 softwire minutes

Slides

These are also available from the materials page:
Chair slides
public 4over6
softwire mesh multicast
Towards a common spec
IPv4 Residual Deployments a Stateless Solu6on (4rd)
4rd implementation report
MAP Simulation Tool
MAP Testing Results
MAP deployment
Lightweight 4over6 and deployment
DS-Lite Failure Detection and Failover
Port set algorithm analysis
IP tunnel MIB extension for softwire
Lightweight 4over6 MIB
Stateless IPv4 over IPv6
Questions for Stateless
Session 2012-08-02 0900-1130: Regency B - Audio stream - softwire chatroom

Minutes

minutes-84-softwire minutes



          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
          
          



Generated from PyHt script /wg/softwire/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -