Hi Woj, Many thanks for the comments.
Please see inline. Cheers, Med >-----Message d'origine----- >De : Wojciech Dec (wdec) [mailto:w...@cisco.com] >Envoyé : vendredi 30 novembre 2012 11:42 >À : BOUCADAIR Mohamed OLNC/OLN; >draft-ietf-softwire-...@tools.ietf.org; >draft-ietf-softwire-map-d...@tools.ietf.org; >draft-ietf-softwire-public-4ov...@tools.ietf.org; >draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno >(repenno); softwires@ietf.org >Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe > >Hi, > >While thanking the authors for their attempt, I need to >provide some high >level feedback first on key issues: >The rationale section 1.1 states "co-existance" as the goal - >this appears >to imply some entirely different solutions for which co-existance is >needed", and here are two points: >A) I can agree that DS.-lite is an entirely different solution, but I >firmly believe that it is entirely outside the agreed scope which was a >"unified solution CPE spec" in the context of MAP and Lw4o6. >Thus, I would >recommend that ds.-lite be dropped from this draft as it bears no >influence on "unifying" MAP and Lw4o6, nor does it bear anything on the >already "defined and shipped" ds.-lite solution. Work on such themes of >"multiple solutions coexisting" is what the v6ops CPE draft is covering >and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. > >B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. a >unified functional CPE spec for NAT44-less core relays >accessed via IPv6 >is. As such, describing "modes" as in "solution modes" is not >conductive >to that and a solution term neutral functional breakdown is >essential and >IMO possible (further explained below). This will only make the spec >better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3. > >In Section 3 the draft coin a new term/class of solution >called "Binding >approach". Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. >This effectively refers to configuration state which *all* >solutions need, >and is not helpful in providing anything but more verbiage. >Removing this >classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. > >Further in section 3 the draft lists different functional >elements, and it >is here that major changes are needed. Med: Section 3 is to be seen as a reminder for the solution flavors we have on the table. This section can be moved to an appendix. I would expect we focus our discussion on Section 4. For a unified solution >a functional >breakdown in a solution neutral text is essential. Med: We really tried to adopt a neutral terminology in Section 4. Suggestions are welcome on how to enhance that section. IMO A unified CE has >the following basic functionalities, which I propose to be added to the >text in place of the existing one: Med: Could you please point me which text you are referring to? Thanks. >- IPv4 NAT whose address and port restrictions are configurable >- an IPv6 transport whose source and destination transport address are >deterministically derived/configurable > >- an IPv4 routing capability (also configurable) Med: What does that mean? > >In example terms, consider a CPE configured with IPv4 address, >restricted >Port range X and IPv6 source address Y and transport address Z. >There is no difference in these parameters between Lw4o6 and >MAP, and it >shows the essence of what we need to get at. Med: Isn't that what is captured in "Table 3: Supported Features" ? +--------------+----------------+-----------------+-----------------+ | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | | Element | tunnel | IPv4 | NAT44 | | | endpoint | | | +--------------+----------------+-----------------+-----------------+ | B4 | Yes | N/A | No | +--------------+----------------+-----------------+-----------------+ | lwB4 | Yes | Yes | Optional | +--------------+----------------+-----------------+-----------------+ | MAP-E CE | Yes | Yes | Optional | +--------------+----------------+-----------------+-----------------+ > > >One can comment further on the details of the draft, but >getting the basic >functional breakdown is essential (example above) before we >get into that. > The only thing different between the solutions are not the basic >functionalities but rather how this functionality is configured. Med: I guess you are talking about MAP1:1 and LW4over6. > >Regards, >Woj.. > > > >On 29/11/2012 11:16, "mohamed.boucad...@orange.com" ><mohamed.boucad...@orange.com> wrote: > >>Dear all, >> >>As agreed in Atlanta, we prepared an I-D describing a >proposed approach >>for the unified CPE. >> >>We hope this version is a good starting point to have fruitful >>discussion. >> >>Your comments, suggestions and contributions are more than welcome. >> >>Cheers, >>Med >> >> >>-----Message d'origine----- >>De : i-d-announce-boun...@ietf.org >[mailto:i-d-announce-boun...@ietf.org] >>De la part de internet-dra...@ietf.org >>Envoyé : jeudi 29 novembre 2012 10:57 >>À : i-d-annou...@ietf.org >>Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Unified Softwire CPE >> Author(s) : Mohamed Boucadair >> Ian Farrer >> Suresh Krishnan >> Filename : draft-bfmk-softwire-unified-cpe-00.txt >> Pages : 12 >> Date : 2012-11-29 >> >>Abstract: >> Transporting IPv4 packets over IPv6 is a common solution to the >> problem of IPv4 service continuity over IPv6-only provider >networks. >> A number of differing functional approaches have been developed for >> this, each having their own specific characteristics. As these >> approaches share a similar functional architecture and use the same >> data plane mechanisms, this memo describes a specification >whereby a >> single CPE can interwork with all of the standardized and proposed >> approaches to providing encapsulated IPv4 in IPv6 services. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>i-d-annou...@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
